"Taylan Ulrich Bayırlı/Kammer" <taylanbayi...@gmail.com> writes:
> 宋文武 <iyzs...@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!
