VK_EXT_layer_settings behaviour seems inconsistent across platforms

[SRSaunders]

Environment:

• OS: Windows, Linux, macOS
• GPU and driver version: issue identified using AMD 6600XT, but may be more general
• SDK or header version if building from repo: SDK 1.3.296.0
• Options enabled (synchronization, best practices, etc.): Using with debugPrintfEXT

Describe the Issue

I would like to report on the seemingly different behaviours of the VK_EXT_layer_settings extension across platforms. For instance, on Windows and Linux it seems this extension is not advertized during enumeration unless vkconfig is running. And in addition, if you try to enable it on Windows (even with vkconfig running), it will bail out with an extension not found error during vkCreateInstance() - which seems unexpected to me. This is in contrast to what happens on macOS where the extension is available at all times (not just when vkconfig is running), and can be enabled during instance creation without bailing out.

Interestingly, if the VK_EXT_layer_settings extension is visible during enumeration (for any platform), it seems you can still use the VkLayerSettingsCreateInfoEXT structure even if you don't enable the VK_EXT_layer_settings extension during vkCreateInstance(). This appears to be a bit unconventional, but perhaps is the intended functionality. I don't know.

Expected behavior

If implemented in the SDK version, I would expect VK_EXT_layer_settings to be visible during enumeration at all times (independent of whether vkconfig is running or not). This should be consistent across all OS and GPU platform combinations.

In addition, if the extension is visible during enumeration, I would expect to be able to include it in the enabled extensions list during instance creation, i.e. vkCreateInstance(), without causing ERROR_EXTENSION_NOT_PRESENT errors.

I thought that VK_EXT_layer_settings was meant to allow setting of layer features under program control during instance creation, and its visibility should not depend on whether vkconfig is running or not. In addition, I believe the docs indicate that if the requested layer setting does not match any known setting, it should be ignored and not generate an error.

Valid Usage ID

Additional context

See issue KhronosGroup/Vulkan-Samples#1187 for background information.

[christophe-lunarg]

Hi !

VK_EXT_layer_settings is implemented by some layers, not by any driver. So, for the extension to be visible, a layer implementing this extension should be enabled.

Are you refering to this documentation I think a lot of these questions will be clarified by readying the Vulkan Layers configuration documentation here:
https://vulkan.lunarg.com/doc/view/latest/windows/layer_configuration.html#:~:text=Vulkan%20layers%20can%20be%20configured,()%20and%20the%20VK_EXT_layer_settings%20extension.&text=Using%20the%20vk_layer_settings.,GUI%20interface%20called%20Vulkan%20Configurator.?

[spencer-lunarg]

it seems you can still use the VkLayerSettingsCreateInfoEXT structure even if you don't enable the VK_EXT_layer_settings extension during vkCreateInstance().

This is something I can add, we have this issue where without the settings, I don't know if you want errors reported to a file, to your callback, etc... basically we can't do "normal validation" before we get the settings

I have special flow for "things that need validation before validation starts" and get a PR up to add this one

---

Edit: So this is an Instance extension and this is just missing a VU like VUID-VkInstanceCreateInfo-pNext-04925 ... adding to VVL and the Spec (https://gitlab.khronos.org/vulkan/vulkan/-/merge_requests/6979)!

[SRSaunders]

Thank you @christophe-lunarg for you answer. I had already read the doc you are referring to so my question is a bit deeper. The context here is that I wish to do everything under program control, without use of environment variables or vkconfig.

The two issues I am seeing are as follows:

1. I am enabling VK_LAYER_KHRONOS_validation during vkCreateInstance() without any environment variables set or vkconfig running. On macOS the VK_EXT_layer_settings extension is available during enumeration since I believe MoltenVK itself is considered a layer. This means you can detect support in the SDK and use VkLayerSettingsCreateInfoEXT to configure layers (e.g. VK_LAYER_KHRONOS_validation, MoltenVK itself, etc) during vkCreateInstance().

However, on Windows and Linux, no layer is enabled prior to instance creation if there are no env variables set and vkconfig is not running. This causes a Catch-22 situation: On Windows and Linux it seems that you cannot enumerate VK_EXT_layer_settings to determine if the SDK supports it, but you need VkLayerSettingsCreateInfoEXT to configure a layer (in my case the validation layer) during vkCreateInstance(). So I am left wondering how to detect VK_EXT_layer_settings support in the SDK and how to do this entirely under program control, without reliance on env variables or vkconfig?

2. With Windows + AMD GPU, I am seeing another problem: Even if I run vkconfig to make VK_EXT_layer_settings visible during enumeration, I can use VkLayerSettingsCreateInfoEXT but cannot enable the extension during vkCreateInstance(), If I do this I get the error below. This does not happen with Windows + nVidia GPU or on macOS. I still have to test Linux.

As an aside, I have noticed that if you can enumerate VK_EXT_layer_settings, you can still use VkLayerSettingsCreateInfoEXT to configure layers even without VK_EXT_layer_settings being enabled during vkCreateInstance(). Depending on your answers to the above questions, this may be desirable and perhaps should remain. Please advise.

[SRSaunders]

Thanks @spencer-lunarg.

This is something I can add, we have this issue where without the settings, I don't know if you want errors reported to a file, to your callback, etc... basically we can't do "normal validation" before we get the settings

Before taking any action here, I would like to first hear back from @christophe-lunarg regarding how to properly detect support for VK_EXT_layer_settings in the SDK, and about the error I am seeing on Windows/AMD when trying to enable VK_EXT_layer_settings. Depending on his answer, we may need the existing behaviour to remain, i.e. support VkLayerSettingsCreateInfoEXT even if VK_EXT_layer_settings is not enabled during vkCreateInstance().

[charles-lunarg]

on Windows and Linux it seems this extension is not advertized during enumeration unless vkconfig is running.

This is due to the fact that the MoltenVK driver advertises support for it directly. If you query the instance extensions supported by VK_LAYER_KHRONOS_validation directly, you'll find that it supports VK_EXT_layer_settings. Alternatively, look at the output of vulkaninfo - the layer settings extension appears in the supported instance extension list of various layers. Running it on my local system, I see it directly in the validation layer as well as others layers.

The reason for the extension list from vkEnumerateInstanceExtensionProperties(NULL, ...) not returning the layer settings ext (ie, the instance extensions supported by drivers) is because the list of active explicit layers hasn't been decided yet. Implicit layers do add their instance extensions to that list specifically because they are implicitly enabled.

FYI - this is not a unique problem to VK_EXT_layer_settings. VK_EXT_debug_utils has the same behavior on android. On desktop, debug_utils is supported by the loader as well as layers, so its always available. But on android neither the driver nor loader support it, so it appears unavailable. When the validation layer is available, the application can query the extensions it supports, which includes debug_utils.

On macOS the VK_EXT_layer_settings extension is available during enumeration since I believe MoltenVK itself is considered a layer.

No, MoltenVK is a driver. It is not considered a layer by the Vulkan-Loader.

[charles-lunarg]

To answer a different question - the reason vkconfig makes VK_EXT_layer_settings appear as 'available' is because of the way vkconfig makes VK_LAYER_KHRONOS_validation be force-enabled. The mechanism vkconfig uses is to create an "override" implicit layer that tells the loader to enable the validation layer. But because the override needs to be implicit in order to be active by default, the validation layer inherits that 'implicit' layer nature and so adds the extension to the instance layer list. Or that is my going theory. It might be a different mechanism but I am fairly confident that is the reason why.

[spencer-lunarg]

@SRSaunders (sorry to create a new thread)

without causing ERROR_EXTENSION_NOT_PRESENT errors.

This part is what I am want to understand, I am not sure who is returning this, can you make a branch of Vulkan Samples where I could reproduce this behavior?

[SRSaunders]

If you query the instance extensions supported by VK_LAYER_KHRONOS_validation directly, you'll find that it supports VK_EXT_layer_settings.

The reason for the extension list from vkEnumerateInstanceExtensionProperties(NULL, ...) not returning the layer settings ext (ie, the instance extensions supported by drivers) is because the list of active explicit layers hasn't been decided yet. Implicit layers do add their instance extensions to that list specifically because they are implicitly enabled.

@charles-lunarg thank you very much for these explanations - it helps me a lot. The details around vkconfig's inner workings seem a little more sophisticated, but ultimately I don't need to know this to achieve what I am looking for. I will follow your advice and query VK_LAYER_KHRONOS_validation directly.

[SRSaunders]

@spencer-lunarg you can use the branch for my currently open PR KhronosGroup/Vulkan-Samples#1187.

To reproduce the problem do the following:

1. add the following line after set_api_version() in shader_debugprintf.cpp:

		set_api_version(debugprintf_api_version);
--->		add_instance_extension(VK_EXT_LAYER_SETTINGS_EXTENSION_NAME);

2. run vkconfig to force usage of the layer settings path in the code (at least for now, until I make the correction above)
3. run the shader_debugprintf sample on a Windows + AMD GPU machine.
4. you should see the extension not present error

I am not sure how important it is to fix this for my purposes. I plan to not include the add_instance_extension() line in my pull request. However, you may want to look at this to understand what is happening.

[christophe-lunarg]

I believe everything what answered by @charles-lunarg and @spencer-lunarg.

Detecting the availability of VK_EXT_layer_settings is programmatically tricky for the reasons explained. You can assume it's available for all Vulkan SDK layers except gfxrecon since Vulkan SDK 275:
https://www.lunarg.com/lunarg-releases-new-vulkan-1-3-275-0-sdks-for-windows-linux-macos/

[SRSaunders]

@christophe-lunarg I have two final questions:

1. Currently you can use VkLayerSettingsCreateInfoEXT in the vkCreateInstance() pNext chain even without VK_EXT_layer_settings being enabled in the extensions list. Is this stable, supported functionality or more of an "accident"? Before I finalize my PR in Vulkan-Samples, I would like to know whether I can depend on this behaviour.
2. In the official Khronos documentation for VK_EXT_layer_settings should it be made more clear this is a layer extension and not a driver extension? And perhaps give an example showing extension enumeration for a layer?

[christophe-lunarg]

@christophe-lunarg I have two final questions:

1. Currently you can use VkLayerSettingsCreateInfoEXT in the vkCreateInstance() pNext chain even without VK_EXT_layer_settings being enabled in the extensions list. Is this stable, supported functionality or more of an "accident"? Before I finalize my PR in Vulkan-Samples, I would like to know whether I can depend on this behaviour.
2. In the official Khronos documentation for VK_EXT_layer_settings should it be made more clear this is a layer extension and not a driver extension? And perhaps give an example showing extension enumeration for a layer?

1. I think @spencer-lunarg would provide a better answer than me for 1. But yes currently that's how it works. Should layers fail for that @spencer-lunarg even without the validation layer chained?

2. I don't think it should because drivers could choose to implement it. Actually, this is done by MoltenVK which we can considered as a driver. Well, this said if you mean https://docs.vulkan.org/spec/latest/index.html, yes I think we should definitly get more involved with this and add more exhautive layer documentation. As for the layer settings documentation, yes I'll update the documentation to mention the caveat that this is an instance extension which has some issues.

[spencer-lunarg]

Currently you can use VkLayerSettingsCreateInfoEXT in the vkCreateInstance() pNext chain even without VK_EXT_layer_settings being enabled in the extensions list. Is this stable, supported functionality or more of an "accident"?

I just got the new VUs added in https://gitlab.khronos.org/vulkan/vulkan/-/merge_requests/6979 (will be in 1.3.301 header under VUID-VkInstanceCreateInfo-pNext-09400)

This is for formality, in reality, I would be surprised if a layer would go "they didn't use the extension, we are going to ignore their VkLayerSettingsCreateInfoEXT now" .... but they "could"... VVL will just consume VkLayerSettingsCreateInfoEXT regardless 😄

[christophe-lunarg]

Currently you can use VkLayerSettingsCreateInfoEXT in the vkCreateInstance() pNext chain even without VK_EXT_layer_settings being enabled in the extensions list. Is this stable, supported functionality or more of an "accident"?

I just got the new VUs added in https://gitlab.khronos.org/vulkan/vulkan/-/merge_requests/6979 (will be in 1.3.301 header under VUID-VkInstanceCreateInfo-pNext-09400)

This is for formality, in reality, I would be surprised if a layer would go "they didn't use the extension, we are going to ignore their VkLayerSettingsCreateInfoEXT now" .... but they "could"... VVL will just consume VkLayerSettingsCreateInfoEXT regardless 😄

Yes, all the layers I implemented VkLayerSettingsCreateInfoEXT just consume the structure too...

[spencer-lunarg]

should it be made more clear this is a layer extension and not a driver extension?

Let me raise an internal Working Group issue on this... I agree it is VERY confusing to not realize which extensions are layer vs driver ... you are not the first person to hit this 😆

[charles-lunarg]

I would like to add a note to the spec indicating that "layer supported extensions can be queried by calling vkEnumerateInstanceExtensions with the name of the layer as the first parameter" so that the solution to the problem in this issue has a little more visibility.

[SRSaunders]

Thanks to all for your extensive explanations and background. I have modified my PR in Vulkan-Samples to take into account the information here. And it would be great if you could add the doc items mentioned above. If you wish, I can leave this issue open until you close on the doc enhancements. Thanks again.