On 2025-04-14 18:23, Simon McVittie wrote:
> 
> I can see two ways to resolve #980148 without needing to change the
> search path for Vulkan drivers:
> 
> 1. As far as I'm aware, the basename of these files never matters: all
>     that matters is their content. So Mesa's debian/rules could do something
>     like this (assuming file-rename(1p) from the rename package):
> 
>         file-rename 's/(.*)\.([^.]+?)\.json$/$1.$ENV{DEB_HOST_ARCH}.json/' \
>         debian/tmp/usr/share/vulkan/icd.d/*.json
> 
>     to replace the "x86_64" or "armv8l" part of the filename with a string
>     that is definitely distinct for each pair of Debian architectures,
>     resulting in filenames like intel_icd.amd64.json and intel_icd.x32.json.
> 
>     Or it could use $ENV{DEB_HOST_MULTIARCH} for longer-but-maybe-clearer
>     filenames like intel_icd.x86_64-linux-gnu.json, which would be necessary
>     if we want to allow mesa-vulkan-drivers:amd64,
>     mesa-vulkan-drivers:hurd-amd64 and mesa-vulkan-drivers:kfreebsd-amd64
>     to be co-installed.
> 
>     [...]
> 
> 2. Or, Mesa could give its Vulkan drivers the same file layout as its
>     Vulkan layers (which happens to be the same as the Nvidia proprietary
>     driver's Vulkan driver), taking advantage of the fact that on Debian, each
>     of its drivers is installed into ld.so's default load path for shared
>     libraries. So instead of hard-coding the full path of the library, it 
> could
>     set the library_path field to be just the basename, resulting in the same
>     JSON content on every architecture:
> 
>         {
>              "ICD": {
>                  "api_version": "1.2.145",
>                  "library_path": "libvulkan_intel.so"
>              },
>              "file_format_version": "1.0.0"
>         }
> 
>     and then rename the file to a name that is intentionally the same
>     for every architecture (like intel_icd.json), so that they *always*
>     collide, and dpkg's multiarch refcounting resolves this by only keeping
>     one copy.

FWIW, I recommend option 2 for these reasons:

It should result in slightly better Vulkan start-up performance when 
mesa-vulkan-drivers is installed for multiple architectures, because the Vulkan 
loader won't waste cycles trying to load ICDs that can't work.

It also avoids warning messages from the loader (or the dynamic linker?) when 
trying to load ICDs that can't work.


-- 
Earthling Michel Dänzer       \        GNOME / Xwayland / Mesa developer
https://redhat.com             \               Libre software enthusiast

Reply via email to