vulkaninfo yields VK_ERROR_INCOMPATIBLE_DRIVER unless VK_ICD_FILENAMES is passed (on 1.1.73)

[aktau]

This seems similar to KhronosGroup/Vulkan-LoaderAndValidationLayers#1978, except that the LD_BIND=1 trick doesn't work for me and the program doesn't crash for me, it just seems to pick the wrong icd.

This doesn't work:

$ LD_BIND=1 vulkaninfo
===========
VULKAN INFO
===========

Vulkan Instance Version: 1.1.73

Cannot create Vulkan instance.
/build/vulkan-r6qT7O/vulkan-1.1.73+dfsg/demos/vulkaninfo.c:812: failed with VK_ERROR_INCOMPATIBLE_DRIVER

This works:

$ VK_ICD_FILENAMES=/usr/share/vulkan/icd.d/intel_icd.x86_64.json vulkaninfo |& head -20
INTEL-MESA: warning: Bay Trail Vulkan support is incomplete
INTEL-MESA: warning: ../../../src/intel/vulkan/anv_device.c:1150: FINISHME: Implement pop-free point clipping
===========
VULKAN INFO
===========

Vulkan Instance Version: 1.1.73



Instance Extensions:
====================
Instance Extensions	count = 16
...

My system:

OS: Debian Testing (Linux kernel 4.18)
Mesa (mesa-vulkan-drivers et cetera.): 18.2.5
Hardware: Intel Bay Trail

[aktau]

While attempting to figure this out, I strace'd vulkaninfo(1):

$ strace -e trace=file vulkaninfo 2>&1 >/dev/null | grep icd.d
openat(AT_FDCWD, "/etc/xdg/vulkan/icd.d", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/etc/vulkan/icd.d", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/home/aktau/.linuxbrew/share/vulkan/icd.d", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/home/aktau/.local/share/vulkan/icd.d", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/etc/xdg/vulkan/icd.d", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = -1 ENOENT (No such file or directory)

It appears that some library is not scanning all the folders mentioned in https://vulkan.lunarg.com/doc/view/1.0.65.0/windows/LoaderAndLayerInterface.html. I quote:

ICD Discovery on Linux
In order to find installed ICDs, the Vulkan loader will scan the files in the following Linux directories:

/usr/local/etc/vulkan/icd.d
/usr/local/share/vulkan/icd.d
/etc/vulkan/icd.d
/usr/share/vulkan/icd.d
$HOME/.local/share/vulkan/icd.d

What could influence this?

[lenny-lunarg]

It looks to me like we didn't update that documentation when we made the latest changes to the search paths. In particular, I don't see any mention of the XDG paths.

What are the values of your XDG environment variables? Specifically, what are the values of XDG_DATA_HOME, XDG_DATA_DIRS, and XDG_CONFIG_DIRS? I would suspect that the loader is searching these directories instead of the the one where your driver is located.

This is how I believe the search logic currently works. If you verify that this is correct, I'll at the very least update the documentation, but we can try to figure out if this is good behavior or should be changed.

1. Search $XDG_CONFIG_DIRS. If this is not present, search /etc/xdg instead.
2. Search $XDG_DATA_DIRS. If this is not present, search /usr/local/share and /usr/share instead.
3. Search $XDG_DATA_HOME. If this is not present, search $HOME/.local/share instead.
4. Search the path from the CMake variable CMAKE_INSTALL_FULL_SYSCONFDIR
5. Search /etc if it hasn't been searched already.

Based on this, I think you have an XDG_DATA_DIRS variable set, that does not include /usr/share and that is why the loader isn't finding your driver. But you should check your XDG variables to be sure.

As far as fixing the problem, the obvious way is to either add /usr/share to XDG_DATA_PATHS or to unset the variable. I'd also ask how you're getting your ICD? It may be that the ICD installation should be smart enough to only install the ICD to XDG paths.

There's one more thing I'll mention, which is that it's actually possible to override most of the fallback paths at build time through CMake. As a result, if you or a package maintainer is doing something strange at build time, it's always possible that is the source of your problem.

[aktau]

Hi, thanks for investigating. I'll only be able to reach that host to follow-up on the weekend.

It's strange though that setting or unsetting XDG_DATA_DIRS would be able to affect the loading of system-drivers if no other drivers are installed. My theory:

1. The Debian packagers of mesa-vulkan-drivers chose /usr/share/vulkan/icd.d as the place to put the json files for standard mesa drivers because it was listed in https://vulkan.lunarg.com/doc/view/1.0.65.0/windows/LoaderAndLayerInterface.html. Or (even more likely), the default path used by the mesa package is /usr/share/vulkan/icd.d. The uploader in question is @andreasboll if I didn't incorrectly map from https://tracker.debian.org/pkg/mesa.
2. Vulkan-Loader does not have /usr/share/vulkan/icd.d configured as a standard path. This seems obvious from the observed behaviour on my systems.

Either mesa or Vulkan-Loader should be fixed, I guess. I don't know which one.

The documentation should certainly be updated though, as you state.

[smcv]

It's strange though that setting or unsetting XDG_DATA_DIRS would be able to affect the loading of system-drivers if no other drivers are installed.

In most implementations of the XDG base directory specification, XDG_DATA_DIRS is read instead of /usr/local/share:/usr/share, not in addition to that default. If you want to look for .desktop files or icon themes or anything else XDG-ish in /usr/share, you have to use something like XDG_DATA_DIRS=/opt/myapp/share:/usr/local/share:/usr/share, so it seems reasonable that Vulkan ICDs are the same.

[lenny-lunarg]

I'm closing this because it's old and the issues around this are now documented in #245 and #246, which cover this a little better. So I'm closing this issue in favor of the others.