On Mon, 14 Apr 2025 at 18:48:02 +0200, Michel Dänzer wrote: > 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. [rename the files to have a longer architecture disambiguator] > > > > 2. Or, Mesa could give its Vulkan drivers the same file layout as its > > Vulkan layers [changing] the library_path field to be just the basename > > and then rename the file to a name that is intentionally the same > > for every architecture (like intel_icd.json) > > 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.
Yes, although that speed-up probably isn't noticeable. > It also avoids warning messages from the loader (or the dynamic > linker?) when trying to load ICDs that can't work. I believe Vulkan-Loader now tries to suppress those messages, although they were a frequent source of noise in support channels in the past. It's worth mentioning that there are some other specifications that are "the same shape" as Vulkan, particularly EGL and OpenXR. It would be great if Mesa's Vulkan driver could do this in a way that makes a good example for others, to make file content conflicts less likely to arise because anyone naively copying what Mesa does for Vulkan will already be "doing the right thing". For EGL, Mesa's driver in the libegl-mesa0 package already uses the equivalent of option 2 above, so there is no conflict. I think that's another point in favour of option 2. For OpenXR, the only "runtime" (~= driver) implementation I'm aware of in Debian (Monado) has a file content conflict bug similar to this one, but with no attempt to distinguish different architectures' files, so it affects amd64/i386 just as much as amd64/x32: <https://bugs.debian.org/1101455>. On that bug, I recommended the equivalent of option 2 above, because the equivalent of option 1 would be more annoying to implement for OpenXR (it is not *precisely* "the same shape" as Vulkan). smcv
