I did a dirty, awful thing. For r600/radeonsi gallium drivers it seems
neccessary to compile Mesa with --enable-va for this to work. That said,
it seems that installing the shared libraries from this build is
enough to make the vainfo utility happy. I haven't seen if this
actualy works with ffmpeg at all.
$ vainfo
libva info: VA-API version 1.6.0
libva info: va_getDriverName() returns 0
libva info: Trying to open /usr/local/lib/dri/r600_drv_video.so
libva info: Found init function __vaDriverInit_1_0
libva info: va_openDriver() returns 0
vainfo: VA-API version: 1.6 (libva 2.6.0.1)
vainfo: Driver version: Mesa Gallium driver 19.0.8 for AMD CAICOS (DRM
2.50.0 / 6.6, LLVM 8.0.1)
vainfo: Supported profile and entrypoints
VAProfileMPEG2Simple : VAEntrypointVLD
VAProfileMPEG2Main : VAEntrypointVLD
VAProfileVC1Simple : VAEntrypointVLD
VAProfileVC1Main : VAEntrypointVLD
VAProfileVC1Advanced : VAEntrypointVLD
VAProfileH264ConstrainedBaseline: VAEntrypointVLD
VAProfileH264Main : VAEntrypointVLD
VAProfileH264High : VAEntrypointVLD
VAProfileNone : VAEntrypointVideoProc
On Linux, {r600,radeonsi,}_drv_video.so are symlinks to
gallium_drv_video.so.
Here's the awful patch that edits the pre-generated configure file,
because the xenocara build system purposefully prevents pkg-config
from searching /usr/local. There's some weirdness as well related
to VA_MAJOR/VA_MINOR, as vainfo complains if they match the installed
library so 0.0. It wants __vaDriverInit_1_0 and not __vaDriverInit_0_0.
$ cvs -qd $CVSROOT checkout -P xenocara/lib/mesa
$ cd xenocara/lib/mesa
$ patch -p0 < patch
$ make -f Makefile.bsd-wrapper -j $(sysctl -n hw.ncpuonline)
$ doas cp ./src/gallium/targets/va/.libs/gallium_drv_video.so
/usr/local/lib/dri/r600_drv_video.so
$ doas cp ./src/gallium/targets/va/.libs/gallium_drv_video.so
/usr/local/lib/dri/radeonsi_drv_video.so
Index: Makefile.bsd-wrapper
===================================================================
RCS file: /cvs/xenocara/lib/mesa/Makefile.bsd-wrapper,v
retrieving revision 1.28
diff -u -r1.28 Makefile.bsd-wrapper
--- xenocara/lib/mesa/Makefile.bsd-wrapper 28 Aug 2019 08:01:48 -0000
1.28
+++ xenocara/lib/mesa/Makefile.bsd-wrapper 15 Dec 2019 04:45:56 -0000
@@ -41,6 +41,7 @@
--enable-gles1 --enable-gles2 \
--enable-shared-glapi \
--enable-osmesa \
+ --enable-va \
--enable-gbm \
--enable-texture-float \
--enable-autotools \
Index: configure
===================================================================
RCS file: /cvs/xenocara/lib/mesa/configure,v
retrieving revision 1.25
diff -u -r1.25 configure
--- xenocara/lib/mesa/configure 7 Dec 2019 03:10:09 -0000 1.25
+++ xenocara/lib/mesa/configure 15 Dec 2019 04:45:58 -0000
@@ -14,6 +14,9 @@
## M4sh Initialization. ##
## -------------------- ##
+export VA_CFLAGS="-I/usr/local/include"
+export VA_LIBS="-L/usr/local/lib -lva"
+
# Be more Bourne compatible
DUALCASE=1; export DUALCASE # for MKS sh
if test -n "${ZSH_VERSION+set}" && (emulate sh) >/dev/null 2>&1; then :
@@ -29815,8 +29818,10 @@
if test "x$enable_va" = xyes; then
- VA_MAJOR=`$PKG_CONFIG --modversion libva | $SED -n
's/\([^\.]*\)\..*$/\1/p'`
- VA_MINOR=`$PKG_CONFIG --modversion libva | $SED -n
's/.*\.\(.*\)\..*$/\1/p'`
+ #VA_MAJOR=`$PKG_CONFIG --modversion libva | $SED -n
's/\([^\.]*\)\..*$/\1/p'`
+ VA_MAJOR=1
+ #VA_MINOR=`$PKG_CONFIG --modversion libva | $SED -n
's/.*\.\(.*\)\..*$/\1/p'`
+ VA_MINOR=0
fi
VA_MAJOR=$VA_MAJOR
On Sat, Dec 14, 2019 at 08:27:41AM -0600, Brad DeMorrow wrote:
> Thank you both again for the explanation. That makes sense now.
> I've updated the libva Makefile to simply use 0.0 as the SHARED_LIBS
> versions
> and I've removed the post-install hook that adds additional symlinks for no
> good reason.
>
> I added patches to remove the explicit shared library versions from the
> dlopen calls in the
> intel-vaapi-driver port and it now works as expected without the symlinks.
> I looked through
> the other ports for hard-coded dlopen calls as well, but found no more.
>
> libva-utils had an extra binary being installed called test_va_api as a
> result of building the test suite.
> I added a post-install hook to remove this binary before it's packaged. I
> hope that's the correct approach.
>
> Please find the updated tarballs attached with all of the changes we've
> discussed thus far.
>
> Thank you again for helping me test this and get it all straightened out.
>
>
> On Sat, Dec 14, 2019 at 1:55 AM Vadim Zhukov <persg...@gmail.com> wrote:
>
> > сб, 14 дек. 2019 г. в 10:27, Brad DeMorrow <b...@demorrow.net>:
> > >
> > > On Sat, Dec 14, 2019 at 1:16 AM Vadim Zhukov <persg...@gmail.com> wrote:
> > >>
> > >> сб, 14 дек. 2019 г. в 08:25, Vadim Zhukov <persg...@gmail.com>:
> > >> >
> > >> > сб, 14 дек. 2019 г. в 06:10, Brad DeMorrow <b...@demorrow.net>:
> > >> > >
> > >> > > Thank you both, this is very helpful for me.
> > >> > > Attached are updated tarballs.
> > >> > > Since the meson module does the right thing, I stuck with using it
> > for all three ports.
> > >> >
> > >> > Then why do you create that symlink mess and complicate SHARED_LIBS?
> > >> >
> > >> > I've just checked, just setting SHARED_LIBS to 0.0 work fine, as it
> > >> > should. You'd simply drop the post-install target all variables
> > >> > created for it.
> > >> >
> > >> > Also, lib/dri/i965_drv_video.so still lacks @so marker. Do you run
> > >> > recent snapshot? Could you post your dmesg, please?
> > >>
> > >> Aha, so I found a problem: in intel driver, in i965_output_dri.c,
> > >> there is the LIBVA_X11_NAME string which hardcodes the library version
> > >> of libva-x11. The driver tries to dlopen this name and, obviously,
> > >> fails. Same thing happens in Wayland-related code, but since we have
> > >> no Wayland yet, we can ignore it for now. :) After removing ".2" from
> > >> the LIBVA_X11_NAME things start to work! Well, vainfo starts to work.
> > >> IIUC, existing stuff that could use VA-API needs to be recompiled...
> > >> How do you actually use VA-API?
> > >
> > > I have a two follow up ports that can use it.
> > > - ffmpeg: I sent a request to the maintainer earlier today about
> > amending the port to include vaapi support.
> > > - moonlight-qt: relies on ffmpeg with vaapi support. Allows game
> > streaming from Windows PCs with Nvidia gamestream technology. I’ve played a
> > couple hours of games with it- it’s nice.
> >
> > Aha, would be nice to test!
> >
> > IIRC, VA-API could be used for encoding as well... I'm building ffmpeg
> > right now, and I will try to run some vaapi-enabled encoder.
> >
> > > As far as the hard coded library name, yeah that’s why I have to use the
> > symlinks.. I could patch it, but it looks like it’s very intentional on
> > their part. The email I sent you a few minutes ago includes a reference to
> > their warning message about changing the .so names.
> >
> > The upstream tries to hardcode major versions to fix the problem you
> > won't have on OpenBSD: libva and intel-vaapi-driver would be kept in
> > sync anyway. And hardcoding major version in dlopen() won't save you
> > from calling a function not present in this minor version of shared
> > library anyway. I don't understand yet why this dlopen() call is ever
> > needed...
> >
> > >> > >> See meson.port.mk and patch-mesonbuild_build_py.
> > >> > >> Using SHARED_LIBS foo 1.0 will make meson.port.mk set a
> > >> > >> LIBfoo_VERSION=1.0 environment variable which meson will use.
> > >> >
> > >> > Whoa, thanks, Jonathan! And Antoine, of course. :) :)
> > >> >
> > >> > >> Using ports meson to build things outside of ports is more painful
> > as
> > >> > >> these environment variables have to be explicitly set and sometimes
> > >> > >> ninja will re-run meson and not have the environment variables set.
> > >> > >>
> > >> > >> https://github.com/mesonbuild/meson/issues/3570 describes related
> > >> > >> problems.
> > >> >
> > >> > --
> > >> > WBR,
> > >> > Vadim Zhukov
> > >>
> > >>
> > >>
> > >> --
> > >> WBR,
> > >> Vadim Zhukov
> > >
> > > --
> > > --Brad DeMorrow
> >
> >
> >
> > --
> > WBR,
> > Vadim Zhukov
> >
>
>
> --
> --Brad DeMorrow
