Open randallrvr opened 9 months ago
ziga-lunarg
commented
9 months ago Which version of Vulkan-Headers are you using? It looks to me like your version is older than 1.3.275, which is the current version that Vulkan-Utility-Libraries are using.
The enums in your error messages are only found in the latest Vulkan-Headers.
randallrvr
commented
9 months ago I believe its 1.3.268, whatever was installed with the SDK. Do I have use the headers from the Vulkan-Headers repo in order to get the Vulkan-Utility-Libraries to work?
randallrvr
commented
9 months ago I see that a new SDK was released same day as my question, I've updated, but it doesn't help with my Android builds which are utilizing the headers inside the NDK which are still at 1.3.237 on the latest release. Should I be redirecting my builds to use different headers?
ziga-lunarg
commented
9 months ago I think you will have to use the headers that come with the SDK, the only alternative I see is that you build the repository yourself with the header version you want. The tags on this repository only go down to 1.3.250, as before it didn't exist.
randallrvr
commented
9 months ago That's too bad, I was primarily wanting to use vk_format_utils.h, which has few enough errors I've just made a local copy and #ifdef'd out the troublesome defines.
There's way too many in vk_format_utils.h to do the same there, though I am assuming these files are auto-generated? Perhaps it would be a good idea to auto-generate #ifdef guards, would increase version compatibility at the cost of readability, but I'm not sure how interesting it is to read a giant switch statement.
ziga-lunarg
commented
9 months ago The filed are auto-generated, but I don't know what you mean with the #ifdefs. You can just set the header version you want in scripts/known_good.json and generate the files, and you will have only the extensions for you header version.
randallrvr
commented
9 months ago I just mean, putting #ifdef's around #define's that were not actually defined, e.g.
#ifdef VK_FORMAT_A1B5G5R5_UNORM_PACK16_KHR
case VK_FORMAT_A1B5G5R5_UNORM_PACK16_KHR: {
struct VKU_FORMAT_INFO out = {VKU_FORMAT_COMPATIBILITY_CLASS_16BIT, 2, 1, {1, 1, 1}, 4, {{VKU_FORMAT_COMPONENT_TYPE_A, 1}, {VKU_FORMAT_COMPONENT_TYPE_B, 5}, {VKU_FORMAT_COMPONENT_TYPE_G, 5}, {VKU_FORMAT_COMPONENT_TYPE_R, 5}}};
return out; }
#endifHaving to generate these headers to each version of an SDK is going to severely limit ability to distribute them.
charles-lunarg
commented
9 months ago If you are getting Vulkan-Utility-Libraries from github, then you should also be getting the Vulkan-Headers from github. That way you'll have the latest version and all of these versioning issues go away.
Having to generate these headers to each version of an SDK is going to severely limit ability to distribute them.
This library requires a specific header version (or higher) to function, which is located in the scripts/known_good.json Vulkan-Headers object. While it is possible to add ifdefs to every declaration, I can tell you that its not as simple as that, as there are a number of situations that make the logic complex, or when the API was changed (typically, a major mistake in a new extension gets fixed before people start using it).
randallrvr
commented
9 months ago If you are getting Vulkan-Utility-Libraries from github, then you should also be getting the Vulkan-Headers from github
This goes back to my earlier question, is this still true for Android development? Should I be using the headers from Vulkan-Headers over the headers shipped with latest NDK which are still at 1.3.237?
charles-lunarg
commented
9 months ago Yes, that is my understanding. The headers are just header code and should be backwards compatible (and generally are for applications, its libraries trying to allow using of multiple header versions that get broken).
randallrvr
commented
9 months ago Got it, thanks, I'll have to give a try then.
charles-lunarg
commented
9 months ago For more context, this is the code-gen file I use to generate a dispatch table for vk-bootstrap. https://github.com/charles-lunarg/vk-bootstrap/blob/0af4cb5055a4a3a841d5dd42afa20f294c87ea7c/script/generate_dispatch.py#L106
Since the API added functions to extensions after the extension was released (like, extension version 1 added a new function) I couldn't just use ifdef to guard the function, but had to special case them as I found them. The other case was that a function changed its parameters in a subsequent header update (which is valid, the old parameters were a mistake). Just causes pain for me where there isn't an easy way to detect such a case in vk.xml.
On top of that, there is extensive logic to figure out the exact combinations of ifdef's to use, as some things came come from a vulkan version or an extension (and sometimes both???) which gets very confusing.
randallrvr
commented
9 months ago Is the intention that people use Vulkan-Utility-Libraries instead of the files included with SDKs? My main motivation was to avoid the platform #ifdef that was required because vk_enum_string_helper.h was missing from the Android ndk.
charles-lunarg
commented
8 months ago Is the intention that people use Vulkan-Utility-Libraries instead of the files included with SDKs?
The answer to this question depends on how you are grabbing dependencies. The SDK includes some of the headers in this repo, although not all of them from the looks of it. It is a new repo, only being created around 1.3.250 header timeframe, so there aren't versions older than this.
I'm getting a lot of undeclared identifier errors and duplicate case value errors when I try to use the headers (vk_enum_string_helper.h and utility/vk_format_utils.h) from Vulkan Utilities as opposed the system installed headers. Have I done something wrong here, or is there something else I need to include and/or configure? In this case I am compiling for Android.
vk_enum_string_helper.hvk_format_utils.h