Is there a way to specify explicit layer paths on Windows without the registry?

[llatta]

We would like to be able to use the validation layer DLLs we manage via version control. Ie if a developer runs a certain branch of the application and sets their configuration to enable Vulkan validation it should load the validation layers that are appropriate for the Vulkan SDK the application was compiled against, without having to install a specific Vulkan SDK.

Right now, it seems like from the documentation the only way to specify the layers path is via the registry on Windows (HKEY_LOCAL_MACHINE\SOFTWARE\Khronos\Vulkan\ExplicitLayers), which is a system wide setting the application should not modify on every launch. On Linux the identical functionality is configured via environment variables, which are per-process and allow easy overriding during process launch.

Is there equivalent functionality available on Windows, or could it be added?

Thanks!

[krOoze]

https://github.com/KhronosGroup/Vulkan-Loader/blob/master/loader/LoaderAndLayerInterface.md#table-of-debug-environment-variables

[charles-lunarg]

I read through the description and was somewhat confused. The only applicable environment variable is VK_LAYER_PATH, of which works on linux and windows. So while it replaces the layer search path (rather than add to it), it should solve the problem listed here.

[llatta]

I can't get that to work. Eg setting VK_LAYER_PATH=D:\Projects\VulkanSDK\1.2.154.1\Bin while my registry has: [HKEY_LOCAL_MACHINE\SOFTWARE\Khronos\Vulkan\ExplicitLayers] "D:\\Projects\\VulkanSDK\\1.2.162.0\\Bin\\VkLayer_api_dump.json"=dword:00000000 "D:\\Projects\\VulkanSDK\\1.2.162.0\\Bin\\VkLayer_device_simulation.json"=dword:00000000 "D:\\Projects\\VulkanSDK\\1.2.162.0\\Bin\\VkLayer_gfxreconstruct.json"=dword:00000000 "D:\\Projects\\VulkanSDK\\1.2.162.0\\Bin\\VkLayer_monitor.json"=dword:00000000 "D:\\Projects\\VulkanSDK\\1.2.162.0\\Bin\\VkLayer_screenshot.json"=dword:00000000 "D:\\Projects\\VulkanSDK\\1.2.162.0\\Bin\\VkLayer_khronos_validation.json"=dword:00000000 will still load the 1.2.162.0 khronos_validation layer for me.

If I remove that entry from the registry it will not find anything for the khronos_validation layer. Can you check this works as intended for you?

[charles-lunarg]

If I remove that entry from the registry it will not find anything for the khronos_validation layer.

This sounds like the VK_LAYER_PATH env-var isn't being picked up, either because the path is wrong or that the process is running with elevated privileges. The latter happens as a security message, since this could be used as an attack vector to load untrusted dll's into the address space.

Can you set the env var VK_LOADER_DEBUG=all, run the application, and copy|paste the resulting log (which will be big...) here? That should give more insight into what the loader is doing.

[llatta]

Yeah, that's it. I see in the message below this line: INFO: Loader is running with elevated permissions. Environment variable VK_LAYER_PATH will be ignored

Not quite sure what is considered elevated here, but I am a machine administrator, and the process in running in the debugger. Any way to override this behavior?

[charles-lunarg]

The logic to determine what is 'elevated' is done here, but the gist is that running an application as an administrator then the check gets tripped. https://github.com/KhronosGroup/Vulkan-Loader/blob/9fb591feb77f71f9716d03f795fb22a581bfbdcb/loader/loader.c#L313

As for mitigation, the only concrete advise is to not run applications in administrator mode. There is desire to add an official way to package layers with an application, but thinking about it, if they were to use any mechanism that used env-vars, then they would be subject to the same limitations.

[llatta]

I'm definitely not married to using environment variables for this. Just asking for an option for our developers, who will typically run with administrator privileges, to have the ability to have validation layers selected without messing with a system-wide configuration like the registry. We'd be fine changing code, eg referencing a specific validation layer with an absolute path when initializing the Vk instance, or like you maybe indicate to have the loader search in the local path of the application executable first. All sound fine to me. Thanks for your help!

[charles-lunarg]

Another thought is to recommend using VkConfig, which while much more manual, should offer more defined control. This has the benefit of not needing env-vars and not messing with the system wide registry.

I do have to ask if there is a specific reason why its desired to use validation layer versions older than the most recent? I mean the specifics of the version control system that was mentioned, since that would dictate the reasons to need more than anything.

[llatta]

This actually became originally an issue when 1.2.162.0 validation had a bug with push constant validation, that was already fixed in a non-released build by the time we discovered the issue. So we updated the validation layer DLL from one of the AppVeyor builds into our checked in vulkan libraries, but then had a hard time getting everyone to use that build without everyone doing manual actions. We punted on this then, and everyone did manual registry hacking. Now a few months have passed and one of the developers stumbled over that issue again, as his registry still pointed to this custom library in a branch he had deleted since and validation was broken.

So overall this workflow was less than ideal, and hence this discussion for a better option to switch to pre-release validation layers, and in a broader scope also to get validation distributed without folks having to install Vulkan SDKs in the first place.

[charles-lunarg]

The ability to more easily use custom built layers or layers shipped outside of the SDK (especially on windows) is a known requested feature as there are occasions where an app might depend on a layer to implement certain functionality. There's a lot of tough design considerations that would go into such a feature, and requiring it work well with privilege escalation only complicates matters. Thus I created an issue for it on the vulkan-loader repo, since this would likely require changes to the loader to support it.

https://github.com/KhronosGroup/Vulkan-Loader/issues/601

[llatta]

Thanks! That's a good description of the problem. Feel free to close out this issue then, if you think the loader issue encompasses all the work needed for this feature.

[charles-lunarg]

While I don't have a strong idea for a possible implementation idea in the linked issue, I think this issue can be safely closed as the original issue was 'solved' (running with elevated privileges).