CODEWITHSUNDEEP
linuxshared-librariesvulkan
jesta
jesta

Reputation: 115

Vulkan can't find layer libs on Linux

All my Vulkan SDK paths are sourced in .profile and give the following results when echoed:

enter image description here

I can enumerate all layers and the application compiles without problems. However, when I run it, I get the following error messages from the debug report callback:

enter image description here

I'm on Ubuntu 17.10 with a GTX 1060 with the 387.42.05 drivers, which support Vulkan 1.1.

Running the application with LD_DEBUG=libs shows 2 errors:

/lib/x86_64-linux-gnu/libpthread.so.0: error: symbol lookup error: undefined symbol: pthread_setname_np, version GLIBC_2.2.5 (fatal)

/home/jesta88/Vulkan/VulkanSDK/1.1.70.1/x86_64/lib/libVkLayer_parameter_validation.so: error: symbol lookup error: undefined symbol: vkNegotiateLoaderLayerInterfaceVersion (fatal)

I have no idea what to make of these errors.

Upvotes: 1

Views: 1373

Answers (1)

Karl Schultz
Karl Schultz

Reputation: 1566

I can't completely explain the first error, although I can reproduce it. It is preceded by

calling init: /usr/lib/x86_64-linux-gnu/libGLX_nvidia.so.0

so I suspect that the nvidia driver is probing for a symbol and fails to find it. Although this is marked as "fatal", it isn't really.

For the second error, I can see that too. I reproduced it by running the build_examples.sh script in the SDK. Then:

cd examples/build
LD_DEBUG=libs ./cube --validate -c 300 2> log

The app runs fine.

To convince myself that the validation layers are loaded and working, I created a validation error by commenting out the call to vkDestroyDescriptorPool (line 2252 in cube.c) and got the expected validation errors.

In this case, I think that the Vulkan loader is trying to look up the vkNegotiateLoaderLayerInterfaceVersion symbol in the driver and failing to find it. This is not a fatal condition either since the export of this symbol by a driver is optional. If the loader does not find the symbol, then it assumes a particular protocol between the loader and the driver. If the symbol does exist, the loader calls it to get additional information about the loader<->ICD interface that the driver supports.

Some more detail can be found in this document.

In short, I don't think that these are actual problems.

Edit: The vkNegotiateLoaderLayerInterfaceVersion issue is really happening when the loader attempts to load a layer, and not the ICD (driver), but the same explanation still applies.

I still can't explain the messages you are getting about not finding the layers.

I suggest setting VK_LOADER_DEBUG=all to get some detailed messages about what the Vulkan loader is doing while it is looking for the layers.

Also, try running the cube demo as I outlined above to see if that app runs correctly.

Upvotes: 1

Related Questions