OneVPL dispatcher library path handling is non-standard / surprising to users

[eero-t]

The problem

According to spec, both dispatcher library paths and their order is fixed, and can be changed only with an environment variable (either LD_LIBRARY_PATH, or ONEVPL_SEARCH_PATH) on Linux: https://spec.oneapi.io/versions/latest/elements/oneVPL/source/programming_guide/VPL_prg_session.html

Whereas user expectation is that libraries are automatically found from the paths they are installed.

For example, installing OneVPL media stack under standard /usr/local/ location, fails to work. Everything else installed there (e.g. 3d, compute and lower level media drivers), also work from there, but OneVPL does not. This is both non-standard and unexpected. It's also hard to debug, because OpenVPL dispatcher fails without even trying to load a single driver. See: https://github.com/oneapi-src/oneVPL/issues/56

Potential additional issues

Further issues from this design:

• Intel discrete GPUs should be usable on multiple CPU architectures, for example both Intel and ARM. Is spec going add search paths for new architectures early enough that things keep working for these use-cases?

• Typically driver stacks are all installed to the same location. Where libraries get loaded, is controlled by dynamic loader path order. OneVPL using it's own path search order means that it can load other backend than user intended, or be linked with wrong dependencies, unless same debugging override (=LD_LIBRARY_PATH) is used for both. While semantic versioning should protect from worst issues with that, smaller version differences can e.g. greatly harm bug reproduction and reliability of version info in bug reports

• Environment variables are dropped at some security boundaries (e.g. sudo), which can cause mystery failures in production (things like LD_LIBRARY_PATH are meant for debugging & development, not really for production use)

• (Linux distributions support multi-arch. I.e. there can be libraries for multiple partially compatible architectures, other than the host one, present in the standard system locations (e.g. 64-bit and 32-bit, or AVX512 and non-AVX512 for x86, and VFP and soft-FP for ARM). What if non-native VPL backends are loadable, but not fully working or with best performance, and use newer version numbers than the fully native ones?)

How more mature APIs deal with dispatching

There are more mature APIs with dispatchers than OneVPL, for example OpenGL, OpenCL and Vulkan.

• Build time option for the driver load path

  • See: https://docs.mesa3d.org/faq.html#what-s-the-proper-place-for-the-libraries-and-headers
  • Build configuration phase should output what path it will use, and default to a subdirectory under its install path, matching where driver libraries get installed (when given the same install path)

• Use of JSON-format ICD files to locate the drivers, installed at standard locations. See:

  • https://github.com/KhronosGroup/OpenCL-ICD-Loader#registering-icds
  • https://github.com/KhronosGroup/Vulkan-Loader/blob/master/docs/LoaderDriverInterface.md#driver-discovery-on-linux

Both of the above options fix the issues of:

• Loader missing correct driver path for the host architecture
• Drivers not being found when same install targets are given both to loader and drivers
• Things stopping to work in situations where environment variables get dropped for security reasons

[MordragT]

I was rather surprised by this as well. I am trying to package the oneVPL for Nixos, but setting the rpath to the runtime is not working while LD_LIBRARY_PATH works fine. At least searching for the runtime in the directory where the library sits would be great. As it is now if i wanted to use oneVPL for another application in Nixos i would always need to specify the runtime with LD_LIBRARY_PATH, as nixos isn't using the FHS directories to package software.