Re: [PATCH] gnu: mesa: Add libva input.

[宋文武 <iyzsong@gmail.com>]

"Taylan Ulrich Bayırlı/Kammer" <taylanbayirli@gmail.com> writes:

> 宋文武 <iyzsong@gmail.com> writes:
>
>> Look good to me, but how does it work?
>> According to archlinux, it will build 'gallium_drv_video.so',
>> described as VA-API implementation for gallium.
>> IIUC, libva may dlopen this gallium_drv_video.so?
>
> I had to tinker and research for several hours to be able to answer your
> question, but good thing you asked. :-)
>
> Firstly:
>
> I grepped the libva sources for 'dlopen' and found three places it's
> used:
>
> - to open libatiadlxx.so, which AFAIUI is a proprietary ATI driver which
>   we wouldn't support anyway,
>
> - to open libva-x11.so, which it installs in $prefix/lib; I patched the
>   .c file to use the absolute path to this .so, and
>
> - to open drivers found in $LIBVA_DRIVERS_PATH, falling back to the CPP
>   macro VA_DRIVERS_PATH, which should both contain absolute directory
>   names so it's fine.
>
> Secondly:
>
> The default value for VA_DRIVERS_PATH is $prefix/lib/dri (where $prefix
> is that of libva), which contains only some dummy driver installed by
> libva; most drivers are instead in $mesa_prefix/lib/dri.  So it's
> probably best to set VA_DRIVERS_PATH to $mesa_prefix/lib/dri.  So I
> added --with-drivers-path to libva's configure flags (plus added a make
> flag to solve a certain problem; see patch).
OK.
>
> By the way:
>
> If a package wants to use libva with a driver that doesn't come with
> mesa, then they will have to set LIBVA_DRIVERS_PATH.  A user may also
> add ~/.guix-profile/lib/dri to LIBVA_DRIVERS_PATH, and install any
> number of packages installing graphics drivers there.
Yes, it's reasonable.
>
> Thirdly, and I can finally answer your question:
>
> Comes out "gallium_drv_video.so", found in Arch's "libva-mesa" package,
> is actually Mesa's Gallium-based implementation of VA API, alternative
> to stock libva.  (Arch also has a regular libva package, containing the
> real libva.)  The gallium_drv_video.so driver is installed in mesa's
> $prefix/lib/dri when building it is enabled, so all is fine.
So, it's a 'backend' just like libva-intel-driver, get it.
>
> Also, Mesa needs libva's header files for building it, and this actually
> seems to be the sole reason Mesa depends on libva.  I considered making
> a "libva-headers" package (like the mesa-headers package), but Mesa uses
> pkg-config to test libva's presence so I'm not sure if that would work,
> and libva is small anyway so building it twice should be OK.
No problem, and if mesa only use the header, the libva-no-mesa
won't be included as dependencies when user download it from hydra.


Thanks for your detailed explanation!