Skip to content

pv-runtime: Improve handling of Vulkan layers, especially under Flatpak

Simon McVittie requested to merge wip/srt124 into main

  • graphics-drivers-vulkan: Don't search $XDG_DATA_HOME twice

    In the common case where $XDG_DATA_HOME is the same as ~/.local/share, we don't want to load it twice and get duplicate drivers or layers.

    Helps: #124 (closed)

  • architecture: Add internal function to look up architectures by tuple

  • architecture: Add the size of a pointer to the table

  • tests: Log more clearly which mock Vulkan ICD we are looking at

    If an assertion fails in one of these, we'll want to know which one has the assertion failure.

  • tests: Add logging to clarify which Vulkan layer we're looking at

    If we get an assertion failure here, we'll want to know which layer is the one that was not as expected.

  • graphics: Add some basic test coverage for library_arch

  • graphics: When saving Vulkan layers to a file, export the library_arch

    Fixes: f49f6359 "Add "library_arch" field support for Vulkan ICDs and layer manifests"

  • graphics: Add internal methods to set library_arch

    When we do this, we also need to increase the file format version if older.

  • pv-runtime: Combine multiple resolve_in_sysroot calls

    It seems unnecessary to have three almost identical calls to _srt_file_test_in_sysroot() which each imply a _srt_resolve_in_sysroot() (differing only in their flags), and potentially a fourth later, when we could just combine them.

    This is not 100% equivalent if we combined more than one of IF_EXISTS, IF_DIR and IF_REGULAR, but we never actually do that, so keep things simple by allowing at most one of those flags to be combined. If we find a use-case for combining them in future, we'll have to decide what that means.

  • pv-runtime: Reopen existing fd instead of re-resolving the same path

    Having opened an O_PATH fd for the desired file already, we might as well copy from there instead of repeating _srt_resolve_in_sysroot(). We have to reopen the file via /proc because an O_PATH fd isn't readable on its own.

  • pv-runtime: Use the fully resolved path for JSON manifests in provider

    When the path to a JSON manifest for an EGL/Vulkan driver or a Vulkan layer contains symlinks, the meaning of those symlinks might be different when the provider is mounted on /run/host, /run/gfx or /run/parent. In particular, for Flatpak apps with the freedesktop Platform version 22.08 or newer, /usr/lib/i386-linux-gnu is a symbolic link to ../../../app/lib/i386-linux-gnu (one more ../ than is needed), which means that when we try to dereference it, we "escape" from /run/parent.

    We can avoid this by canonicalizing the path in the provider, and then using the canonicalized path /app/lib/i386-linux-gnu/... to form our symlink /run/parent/app/lib/i386-linux-gnu/... so that it will still be resolvable in our final container.

    Resolves: #124 (closed)

  • pv-runtime: Factor out a local variable

  • pv-runtime: When we split manifests per architecture, set library_arch

    When we create separate JSON manifests for the x86_64 and i386 versions of a manifest, we can avoid them being loaded by the loader for the "other" word size by setting the library_arch field appropriately, even if it was not set in the original manifest.

    For example, if the original manifest said /usr/$LIB/libMangoHud.so, we'll write out two manifests with library_path set to /usr/lib/x86_64-linux-gnu/libMangoHud.so and /usr/lib/i386-linux-gnu/libMangoHud.so. There is no point in trying to load those into the loader of the opposite word size, so set their library_arch to "64" and "32" respectively.

    Helps: https://github.com/ValveSoftware/steam-runtime/issues/618

  • pv-runtime: Skip JSON manifests whose library_arch doesn't match

    If we find two JSON manifests MangoHud.x86_64.json and MangoHud.x86.json, with library_arch set to 64 and 32 respectively, but both with library_path set to /usr/$LIB/libMangoHud.so, then we want to emit two manifests, one for 64-bit and one for 32-bit. Before this commit, we would successfully load /usr/$LIB/libMangoHud.so for both word sizes for each input manifest, and would incorrectly output four manifests in two pairs of duplicates.

As usual with larger branches, best reviewed commit-by-commit.

Only lightly tested, so far - I haven't actually retried this under ordinary pressure-vessel, only Flatpak + pressure-vessel. I'll check it for regressions in a non-Flatpak environment next week.

https://github.com/ValveSoftware/steam-runtime/issues/618 was solved in MangoHud upstream by giving the 32- and 64-bit layers unique names, although I think it might actually have been sufficient to give them each a unique library_arch. However, the commit that mentions that bug is actually enough to avoid it even with an older, unfixed MangoHud (confirmed on an intentionally non-updated Flatpak installation).

We should maybe send MRs to at least MangoHud and Mesa to make them set a library_arch any time they are installing a separate JSON manifest per architecture, so that Vulkan-Loader (and now pressure-vessel as well) will have a bit more information to hint it towards doing the right thing.

/cc @denittis

Edited by Simon McVittie

Merge request reports