[Mesa-dev] [PATCH 1/3] anv: Suffix the intel_icd file with the host CPU

[Jason Ekstrand]

Dave asked for a different commit message that describes the problem a bit
better:

    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 /usr/local 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.

On Thu, Oct 20, 2016 at 4:04 PM, Jason Ekstrand <jason at jlekstrand.net>
wrote:

> 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.
>
> Unfortunately, this system was not designed with multi-arch in mind.
> Instead of having some way to tell the loader "here's the 32-bit version"
> or "here's the 64-bit version", you give the loader a single .so.  This
> means that if you install globally, your icd file somehow has to magically
> point at both /usr/lib/libvulkan_intel.so and /usr/lib64/libvulkan_intel.so
> on a multi-arch system.  If you use an absolute path, this is a problem
> because the 32 and 64-bit versions of the packages stomp each other.
>
> This patch solves this problem 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.
>
> 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>
> Cc: Matt Turner <mattst88 at gmail.com>
> Cc: Emil Velikov <emil.velikov at collabora.com>
> Cc: Adam Jackson <ajax at redhat.com>
> Cc: Timo Aaltonen <tjaalton at ubuntu.com>
> Cc: Dave Airlie <airlied at redhat.com>
> ---
>  src/intel/vulkan/Makefile.am | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/src/intel/vulkan/Makefile.am b/src/intel/vulkan/Makefile.am
> index 54a51be..1dee84b 100644
> --- a/src/intel/vulkan/Makefile.am
> +++ b/src/intel/vulkan/Makefile.am
> @@ -166,7 +166,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
>
> @@ -181,7 +181,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 > $@
> --
> 2.5.0.400.gff86faf
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20161020/4c1c2e0e/attachment-0001.html>