Skip to content

Draft: Guess Vulkan drivers' library_arch from whether they were found in an arch-specific directory

Simon McVittie requested to merge wip/smcv/guessed-library-arch into main

/cc @denittis

For !588 (merged), I wanted to guess whether Vulkan drivers are actually amd64-only or i386-only from whether they were found in one of the Flatpak-specific, architecture-specific locations, and if they are architecture-specific, don't make them available for "the other architecture".

However, that doesn't actually work, because the Steam Flatpak app adds its Vulkan extensions to XDG_CONFIG_DIRS, which means they're actually searched by libvulkan of both word sizes. My implementation was clever enough to recognise that anything found in the XDG_CONFIG_DIRS is searched by both loaders, and not mark it as architecture-specific.

This is sort of our fault, because we backport libvulkan in scout, and that copy from scout can be (and in practice sometimes is) newer than the one in the fdo SDK. Because the copy in scout is basically upstream libvulkan, it doesn't know the Flatpak-specific search directories, resulting in it not finding Vulkan layers and drivers from the architecture-specific paths in the extensions. The maintainers of the Steam Flatpak app worked around this by copying those search paths into XDG_CONFIG_DIRS (see https://github.com/flathub/com.valvesoftware.Steam/issues/541). Ideally they would have set up an architecture-specific search path instead, but libvulkan has no such thing, so...

The last commit here is also unfinished: it's not quite right, and I realised it wasn't actually going to be practically useful as a result of the above, so I didn't bother to finish it.

I think this branch is probably a dead end, but I wanted to put it up as a possible source of future inspiration before closing it.

  • !588 (merged)

  • graphics: Track whether files were found in an arch-specific directory

    The standard search paths used for EGL and Vulkan JSON manifests are architecture-independent (/etc, /usr/share), but Flatpak runtimes have some non-standard search paths which are architecture-specific. When we find a Vulkan layer in one of those architecture-independent paths, we'll want to record it as potentially architecture-specific.

    Note that this doesn't actually work at the time of writing, because the Steam Flatpak app adds its Vulkan extensions to XDG_CONFIG_DIRS, which means they're actually searched by libvulkan of both word sizes. This is because the Steam Runtime's relatively upstream-like libvulkan is (or can be) newer than the fdo SDK's patched libvulkan, resulting in it not finding Vulkan layers and drivers from the architecture-specific paths in the extensions (see https://github.com/flathub/com.valvesoftware.Steam/issues/541). However, it can be tested by setting XDG_CONFIG_DIRS=/etc/xdg explicitly.

  • graphics: Expose library architecture guessed from location as a property

    As with the previous commit, this doesn't actually work in the Steam Flatpak app at the time of writing, but it can be tested by setting XDG_CONFIG_DIRS=/etc/xdg explicitly.

  • graphics: Add an issue flag for unexpected architectures

    If we find a JSON manifest in an x86_64-linux-gnu directory that says "library_arch": "32", or vice versa, then something is not right.

  • Unfinished commit:

    • Skip copying JSON manifests for libraries found in the other architecture's arch-specific location

    • The beginnings of some work to edit library_arch into SONAME-based manifests if they were found in the arch-specific location

Merge request reports