Mesa (master): anv: Suffix the intel_icd file with the host CPU

[Jason Ekstrand]

Module: Mesa
Branch: master
Commit: d96345de989c8f9a0328cdc3588bfe186154c8ea
URL:    http://cgit.freedesktop.org/mesa/mesa/commit/?id=d96345de989c8f9a0328cdc3588bfe186154c8ea

Author: Jason Ekstrand <jason.ekstrand at intel.com>
Date:   Thu Oct 20 15:46:21 2016 -0700

anv: Suffix the intel_icd file with the host CPU

Vulkan has a multi-arch problem... The idea behind the Vulkan loader is
that you have a little json file on your disk that tells the loader where
to find drivers.  The loader looks for these json files in standard
locations, and then goes and loads the my_driver.so's that they specify.
This allows you as a driver implementer to put their driver wherever on the
disk they want so long as the ICD points in the right place.

For a multi-arch system, however, you may have multiple libvulkan_intel.so
files installed that the loader needs to pick depending on architecture.
Since the ICD file format does not specify any architecture information,
you can't tell the loader where to find the 32-bit version vs. the 64-bit
version.  The way that packagers have been dealing with this is to place
libvulkan_intel.so in the top level lib directory and provide just a name
(and no path) to the loader.  It will then use the regular system search
paths and find the correct driver.  While this solution works fine for
distro-installed Vulkan drivers, it doesn't work so well for user-installed
drivers because they may put it in /opt or $HOME/.local or some other more
exotic location.  In this case, you can't use an ICD json file with just a
library name because it doesn't know where to find it; you also have to add
that to your library lookup path via LD_LIBRARY_PATH or similar.

This patch handles both use-cases by taking advantage of the fact that the
loader dlopen()s each of the drivers and, if one dlopen() calls fails, it
silently continues on to open other drivers.  By suffixing the icd file, we
can provide two different json files: intel_icd.x86_64.json and
intel_icd.i686.json with different paths.  Since dlopen() will only succeed
on the libvulkan_intel.so of the right arch, the loader will happily ignore
the others and load that one.  This allows us to properly handle multi-arch
while still providing a full path so user installs will work fine.

I tested this on my Fedora 25 machine with 32 and 64-bit builds of our
Vulkan driver installed and 32 and 64-bit builds of crucible.  It seems to
work just fine.

Signed-off-by: Jason Ekstrand <jason at jlekstrand.net>
Reviewed-by: Emil Velikov <emil.velikov at collabora.com>
Cc: "13.0" <mesa-stable at lists.freedesktop.org>

---

 src/intel/vulkan/.gitignore  | 2 +-
 src/intel/vulkan/Makefile.am | 7 +++----
 2 files changed, 4 insertions(+), 5 deletions(-)

diff --git a/src/intel/vulkan/.gitignore b/src/intel/vulkan/.gitignore
index a099ff6..725a858 100644
--- a/src/intel/vulkan/.gitignore
+++ b/src/intel/vulkan/.gitignore
@@ -3,4 +3,4 @@
 /anv_entrypoints.h
 /anv_timestamp.h
 /dev_icd.json
-/intel_icd.json
+/intel_icd.*.json
diff --git a/src/intel/vulkan/Makefile.am b/src/intel/vulkan/Makefile.am
index 5d2b3a5..ca5bf9f 100644
--- a/src/intel/vulkan/Makefile.am
+++ b/src/intel/vulkan/Makefile.am
@@ -152,8 +152,7 @@ EXTRA_DIST = \
 	$(top_srcdir)/include/vulkan/vk_icd.h \
 	anv_entrypoints_gen.py \
 	dev_icd.json.in \
-	intel_icd.json.in \
-	intel_icd.json
+	intel_icd.json.in
 
 libvulkan_intel_la_LIBADD = $(VULKAN_LIB_DEPS)
 
@@ -168,7 +167,7 @@ libvulkan_intel_la_LDFLAGS = \
 
 
 icdconfdir = @VULKAN_ICD_INSTALL_DIR@
-icdconf_DATA = intel_icd.json
+icdconf_DATA = intel_icd. at host_cpu@.json
 # The following is used for development purposes, by setting VK_ICD_FILENAMES.
 noinst_DATA = dev_icd.json
 
@@ -183,7 +182,7 @@ else
 ICD_DRIVER_PATH="libvulkan_intel.so"
 endif
 
-intel_icd.json : intel_icd.json.in
+intel_icd. at host_cpu@.json : intel_icd.json.in
 	$(AM_V_GEN) $(SED) \
 		-e "s#@ICD_DRIVER_PATH@#${ICD_DRIVER_PATH}#" \
 		< $(srcdir)/intel_icd.json.in > $@