Vulkan loader doesn't handle extensions provided by layers

[haasn]

Sometimes, Vulkan extensions are provided by layers. These are not included in the glad_vk_get_extensions logic, and therefore fail to get loaded by glad2.

Possible solutions:

1. Extend the glad_vk_get_extensions logic to also enumerate all supported extensions from available instance- and device-level layers.
2. Simply delete the glad_vk_has_extension function and load all extension commands unconditionally.
3. Require the user to provide a list of enabled instance- and device-level extensions when calling into glad2. (i.e. the ppEnabledExtensionNames pointer from VkDeviceCreateInfo which the user already has anyway)

I would actually lean towards the second solution, for simplicity and transparent backwards compatibility. According to the Vulkan specification, calling vkGetDeviceProcAddr on a function name associated with a non-loaded extension is defined behavior, and requires the driver to return NULL here. So unconditionally loading all known function names is kosher.

Calling into non-enabled but supported device-specific extensions is already undefined behavior even if they load successfully, so users must already rely on their own logic to know which device extensions are enabled and which are not, and avoid calling into non-enabled functions. Checking whether the physical device supports an extension before attempting to load it does not afford us any extra safety. At best you are saving a few runtime cycles on device creation.

[Dav1dde]

I think this should be solved with solution 1).

Solution 2) means glad can't provide the (global) booleans anymore whether an extension is available or not. Additionally you mention that drivers should return NULL, I don't expect this to be actually the case in the real world. If not necessary I would like to avoid that.

Solution 3) Requires an API change and I dont think it's a necessarily good API change.

Calling into non-enabled but supported device-specific extensions is already undefined behavior even if they load successfully, so users must already rely on their own logic to know which device extensions are enabled and which are not, and avoid calling into non-enabled functions. Checking whether the physical device supports an extension before attempting to load it does not afford us any extra safety. At best you are saving a few runtime cycles on device creation.

Glad currently exposes information whether an extension is available or not, so the user could rely on this information and doesn't have to implement the check.

Unfortunately my Vulkan is quite rusty so this is something I will have to research for a while and get some free time to look into more closely, I was hoping to get to it in the last 2 weeks but didn't have the time, that's the reason I havent answered yet.

What do you think?

[akioCL]

I agree that solution 1 may be the best one, but unfortunately if the layer that is providing the extension was not loaded during instance creation, then that extension will not really be available. So this means that the global boolean specifying if an extension is available or not is dependent if the layer was loaded during instance creation. And as far as I know, there's no way to know which extensions are loaded (unless provided by the user), so maybe solution 3 may not be so crazy.

About solution 2, I think this is the way the Volk library included with the Vulkan SDK works (https://github.com/zeux/volk), so drivers must be returning NULL when trying to load a function pointer for an extension that is not available.