Customizing VK_LAYER_PATH or VK_ADD_LAYER_PATH during app initialization

[Toctave]

Hi,

I'm trying to ensure that an app I'm developing for Windows and Linux loads a specific version of the validation layers shared library, which is stored alongside the app rather than at the system level.

To that end, I set VK_ADD_LAYER_PATH to point to my shared library (with SetEnvironmentVariableA on Windows and setenv on Linux) before initializing Vulkan. This works on Windows, but not on Linux, because on Linux loader_initialize is called in the loader_init_library constructor function as soon as the .so is loaded, i.e. as soon as the executable starts (in my case, the app links with vulkan dynamically). This means that on Linux, I change the environment variable after it's already been read/

What's the canonical way to go around this issue ? Should I :

1. Run my program with some sort of launcher that sets the environment then runs the actual app
2. Have my own ((constructor)) function, and somehow ensure that it runs before vulkan's
3. Load vulkan dynamically at runtime rather than linking with it ?

If I missed a simpler way to programmatically choose which validation layer shared library is loaded, please let me know !

[charles-lunarg]

So the good news is that the solution also happens to be a performance boost!

That solution being: Dynamically load Vulkan. Specifically, call dlopen("libvulkan.so")/`LoadLibrary("vulkan-1.dll") and query the function pointers directly. Sounds tedius and annoying. Because it is. BUT. There are already great libraries to make it a breeze. If you are using the C headers for vulkan, use https://github.com/zeux/volk. If you are using the C++ headers, follow the docs here https://github.com/KhronosGroup/Vulkan-Hpp/blob/main/docs/Usage.md#extensions-and-per-device-function-pointers

The performance boost comes from loading device function pointers directly from the driver. When you call vkDoFoo() while linking to the loader, you call into the loader source code, which takes the first parameter (e.g. VkDevice), dereferences it, grabs the function pointer in the driver from a big struct, then calls it with the parameters passed in. Its not a LOT of code (just a few pointer derefs) but it is entirely avoidable.

[charles-lunarg]

Re-reading the issue, what strikes me as odd is the assumption that setting VK_ADD_LAYER_PATH after the process begins doesn't work. That should work, the loader does NOT cache VK_ADD_LAYER_PATH at all. It re-reads it every time you call vkCreateInstance and vkEnumerateInstanceLayerProperties`.

What I think might be happening is that if the layer you bundles doesn't use a relative path in the manifest's "library_path" field, then the loader is not finding the desired library because the loader relies on dlopen to find non-relative binaries. If you modified "library_path" from something like "foo.so" to "./foo.so" then that could fix your issue right then and there.