Alternative suffix names for full featured vs distro vendor version

[kwizart]

With Fedora cutting down potentially patented codecs in mesa, the VAAPI backend version that is provided only support VP9 (or even AV1) hardware acceleration methods.

In the current libva assumption, only one (or two) VAAPI backend name is provided for a given driver. This request is to assume an alternative name to be use for a given vaapi backend so an alternative (full featured) version can be used instead of the distribution vendor version.

For example, Fedora could have patentless version iHD-free -> i965 radeonsi_drv_video.so -> radeonsi

Instead, 3rd party vendor could complement the original distro version with: iHD -> i965 radeonsi_full_drv_video -> radeonsi

The "-free" keyword could be use to be a lower version of the normal vaapi backend while "-full" keyword could be use to be a higher priority driver.

Thanks for your help with this issue.

See also:

• mesa-freeworld review to complement Fedora: https://bugzilla.rpmfusion.org/show_bug.cgi?id=6426
• The Fedora issue about lacking some codec in mesa: https://bugzilla.redhat.com/show_bug.cgi?id=2123998
• The VDPAU counterpart bug request: https://gitlab.freedesktop.org/vdpau/libvdpau/-/issues/3

[evelikov]

Sorry if I'm missing something, but does this need to happen in the frontend library?

Consider the following:

• using names like "free" and "full" can be abiguious depending on the audience and the time-frame - say, as the 264/265 patents expire those will become "free", but older version would be otherwise included in "full" bundles only
• adding additional combination to probe gets inflicted onto everyone

• any such libva change would require retro-fitting

  As an alternative, I see two independent solutions:

• packaging is made mutually exclusive - one can have either the "full" or "free" version installed. Should be a matter of 1-2 lines in the build recipe
• the default distribution bundle is installed in the normal location, while the "other" to a custom one - then one can control the lookup location via LIBVA_DRIVERS_PATH environment variable. Ex. the package providing the other drivers uses /usr/lib/foobar/ and also ships a /etc/profile.d/other-vaapi-driver.sh containing export LIBVA_DRIVERS_PATH=/usr/lib/foobar/ or alike

IMHO either of these two scale much better and can be deployed today. Plus the exact same approach works with VDPAU as well - see VDPAU_DRIVER_PATH

[Conan-Kudo]

I think there are two options that make sense:

• Allowing libva to look in "additional" locations and have a priority system, then it's easy for driver binaries to be overridden without breaking lookup for unaffected ones
• Having the actual VA drivers in question split their drivers themselves (for example: https://github.com/intel/media-driver/issues/1598)

[evelikov]

Hey @Conan-Kudo fancy seeing you here - huge thanks for the invaluable discussions about languages and recovery MVP at Akademy in Barcelona o/

The LIBVA_DRIVERS_PATH approach should already provide the first option. In a bit more context:

By default libva looks into a hard-coded build time location and can be overridden by the environment variable. The latter in itself operates similar to PATH, or namely it takes a list of colon separated paths, which are searched in left to right order for the backend drivers.

Let me know if you spot anything wrong with it's behaviour.

[Conan-Kudo]

The documentation I've read implies it only accepts a single path, so it's good to know that it accepts multiple paths. But the problem with this variable is that we don't have a consistent way to set it. Would it be possible to extend the code so that we can set additional lookup paths at compile time?

[kwizart]

The LIBVA_DRIVERS_PATH approach doesn't hold IMO.

If one replaces/complements mesa and only mesa va drivers are used on a given system with a dedicated path, then others drivers (intel/tegra/nvdec/whatever) that will be installed in the "regular path" will break because they won't be available into the appropriate path.

Basically, moving the problem to the driver directory path complicate things over having an additional mapping using regular driver path.

Alternative to names is probably to use numbers, that are less significant and will better describe a priority (00->99).

[evelikov]

@kwizart I don't quite follow what you're trying to say. Can you provide a concrete example, including:

• assuming we have two packages X and Y
• driver files and location for each one
• how is the above configured - by X, Y, both, what does the config file(s) contain

Thanks o/

[kwizart]

If you narrow the situation with two packages from the same component, you probably cannot understand my point:

• There are more vaapi backend involved. Some comes from mesa others from intel, etc.

• From end-users perspective there is only one relevant vaapi backend for their hardware (or maybe two; because hw coverage on intel or the iGPU/dGPU situation, but let's pass on that).

  But then end-users could install mesa-complementary package that will set an alternate driver path while using intel hardware. This case will break their system because the intel vaapi backends (using standard location) cannot be found on the path set by the mesa complementary package.

Also a common assumption for distribution post-installation is that you can install any additional drivers, it's meant to be automatically detected on purpose. But this situation breaks such expectation.

[evelikov]

Two packages were mentioned for the same of simplicity, providing an example with 3 or more was also possible.

That said, I believe the point you're trying to make boils down to:

• people can install multiple vaapi drivers, some of which not meant for their system - say they're using Nvidia GPU, but have also installed the Intel i965/iHD drivers
• the extra drivers installed (i965/iHD) would set LIBVA_DRIVERS_PATH, hence the (unofficial) Nvidia driver, if installed in the stock location won't be picked

That in itself is trivially fixable - here is an example, feel free to expand that to as many packages as needed.

• Nvidia package, ships driver(s) in default /usr/lib/dri location and a file /etc/profile.d/10-vaapi-nvidia.sh containing append_va_path '/usr/lib/dri/
• Intel i965 (patent-free) package, ships driver(s) in /usr/lib/dri location and a file /etc/profile.d/10-vaapi-intel-i965.sh containing append_va_path '/usr/lib/dri/'

• Intel iHD (full) package, ships driver(s) in /opt/lib/iHD location and a file /etc/profile.d/09-vaapi-intel-iHD.sh containing append_va_path '/opt/lib/iHD/'

  Where append_va_path is a helper just like append_path on Arch or pathmunge on Fedora (I believe) - aka LIBVA_DRIVERS_PATH=${LIBVA_DRIVERS_PATH:+$LIBVA_DRIVERS_PATH:}:$1

Thus libva will use /opt/lib/iHD:/usr/lib/dri - looking the Nvidia driver in /opt would rightfully fail and the find the correct one in /usr will be picked. The distro can control the priority numerically via the filenames to the best way they see fit.

People who thinker manually would need to set the variable or install the driver into the search locations - something they already do.

[kparal]

I tried the approach above on my system with Radeon 580. I created:

/usr/lib64/dri/radeonsi_drv_video.so  <- patent-free codecs
/opt/va/radeonsi_drv_video.so         <- all codecs

When I run

LIBVA_DRIVERS_PATH=/opt/va:/usr/lib64/dri vainfo

I can see that the library with all codecs (in /opt/va) was correctly selected. It can be used without issues in vlc for hardware-accelerating patent-encumbered videos. If I rename/remove /opt/va/radeonsi_drv_video.so, it correctly falls back to /usr/lib64/dri/radeonsi_drv_video.so, but of course doesn't provide patent-encumbered codecs acceleration.

@kwizart I believe this approach satisfies your requirements. The directories are checked in sequence for a given filename and the first one found is used. Which means third-party repos can override default distribution-provided files, and only selected files, without any negative effect on the non-overridden files present in the default distribution-provided location.

I haven't played with /etc/profile.d/ scripts, but it seems it should be possible to do it exactly as @evelikov suggested, using pathmunge on Fedora.

[kwizart]

Using LIBVA_DRIVER_PATH looks "racy" if you also need to implement things in the "reverse order" (full version that will be before the default version). Also if a process want to use some backend for display and another one for encoding. It will be very difficult to implement (not talking about iGPU/dGPU interwork).

LIBVA_DRIVER_PATH and more something that should be better be left to end-users than package mantainer. That's for the same reason we avoided to mess with LD_LIBRARY_PATH to replace one or another libGL.so incarnation.

My understanding is that the best way forward is to use a downstream libva patch with dedicated mappings... (that's what I would call easier path).

[Conan-Kudo]

The other problem with LIBVA_DRIVER_PATH is there's no guarantee it'll be loaded depending on the user's shell and other things. That's why we need a way to set paths at compile time for defaults.

[kwizart]

Maybe another way would be to implement this alternate search path for libraries in libva itslef and to assume this alternate search path is always preferred over the default search path.

It would pick "_libdir/vaapi" so it could be a distro agnostic / generic name to pick alternative/prefered backends.

• This will avoid to mess with user shell.
• Everything will work OOTB
• No custom mapping needed.

[evelikov]

@kwizart have you tried my suggestion - it should just work for both "forward" and "reverse" order?

Overall I agree that setting the variable can be fiddly, but it's a solution Fedora can use today and it's literally 5 lines of packaging to implement.

Would be great if distros having this problem, avoid local patches but instead come forward with a well designed solution/MR. Some things to be mindful of:

• no additional overhead (lookups or otherwise) is brought on users with a simple "full-only" driver-set
• mixing of driver features is an anti-feature - aka using /opt/lib/iHD for encode and /usr/lib/iHD for decode
• extra mappings are questionable wrt backwards and forward compatibility

• drivers installed outside of the hard-coded search path(s) just work - package can include misc config

  HTH

P.S. Having worked on fixing the libGL.so monstrosity, it's a different beast all together

[Conan-Kudo]

Overall I agree that setting the variable can be fiddly, but it's a solution Fedora can use today and it's literally 5 lines of packaging to implement.

It is, but where should the variable go? How can we guarantee it's initialized regardless of the user's shell?

Would be great if distros having this problem, avoid local patches but instead come forward with a well designed solution/MR.

I don't want to do local patching if we can help it. I vastly prefer having a portable, maintained solution.

Insofar of your requirements:

• Extra path is checked to exist by libva. If it doesn't exist, don't bother extending the search path.
• It should be a driver path overwrite. That is, if a driver file exists in the extra path, skip the base path entirely for it. That prevents function splitting and other weird things.

This should reasonably work even with all the other things that exist now (including using the variable to extend the lookup path the classic way).

[evelikov]

It is, but where should the variable go? How can we guarantee it's initialized regardless of the user's shell?

Did you see my earlier comment with examples? Alternatively I can send a MR, if you point me to a git repo.

On the guarantee side - /etc/profile is a POSIX standard, so for anything compliant you're gold.

[Conan-Kudo]

fish (which is my shell and a fairly popular shell) is not a POSIX shell and doesn't read that location.

[kparal]

I don't want to downplay the user's choice of shell, but for example on Fedora, /etc/profile.d/flatpak.sh configures XDG_DATA_DIRS. If you use fish, you probably already need to configure stuff like that manually, and LIBVA_DRIVER_PATH looks to be a similar case.

[Conan-Kudo]

I don't want to downplay the user's choice of shell, but for example on Fedora, /etc/profile.d/flatpak.sh configures XDG_DATA_DIRS. If you use fish, you probably already need to configure stuff like that manually, and LIBVA_DRIVER_PATH looks to be a similar case.

Flatpak XDG_DATA_DIRS is less of an issue than broken drivers.

[gotmax23]

Can it be put in /usr/lib/environment.d?

[Conan-Kudo]

That should work for GNOME and KDE Plasma on Fedora, because both desktops use systemd to initialize the desktop session. I don't know how it would affect other desktops, though.

[rathann]

MATE doesn't support /usr/lib/environment.d as far as I know.

[kwizart]

As mentioned in the libva fedora PR, I've found this can be implemented trivially without using LIBVA_DRIVER_PATH env (but keeping the idea of browsing alternatives directories): https://src.fedoraproject.org/rpms/libva/c/ce2dd11f52f21df134b19d5a3727f08b52756137?branch=rawhide

Basically this patch set the driverdir path from _libdir/dri to: -Ddriverdir="%{_libdir}/dri-nonfree:%{_libdir}/dri-freeworld:%{_libdir}/dri"

Once every part are settled, this will allows libva to browse some alternatives directories without any ENV variable that would have needed to re instantiate the env from end-users shell after post-install of any vaapi backend.

It will also work on multilibs cases (i686 libraries on x86_64 kernel/userspace) by avoiding to mix incompatible libraries.

[kwizart]

Also to note that in the Fedora context: the keyword freeworld and nonfree (as in freedom, not beer) is rather clear. But this could be improved in documentation as needed.

Side note: this should be implemented also for libvdpau, but this one is less critical (was made critical because of the introduction of fedora's libva-intel-media-driver-free implementation competing the rpmfusion-nonfree 's intel-media-driver counterpart)

[kwizart]

Closed with downstream commit https://src.fedoraproject.org/rpms/libva/c/ce2dd11f52f21df134b19d5a3727f08b52756137?branch=rawhide

Will be available with fedora 40+ and libva-2.21