No vaapi for AMDGPU with libva-git, mesa-git, mpv-build-git from the AUR

[JulianLai]

mpv version and platform

mpv 0.28.0-44-gd9ca235c68 (C) 2000-2017 mpv/MPlayer/mplayer2 projects
 built on UNKNOWN
ffmpeg library versions:
   libavutil       56.7.100
   libavcodec      58.9.100
   libavformat     58.3.100
   libswscale      5.0.101
   libavfilter     7.8.100
   libswresample   3.0.101
ffmpeg version: N-89646-gbe4dfbf7b7

Reproduction steps

Install libva-git, mesa-git, mpv-build-git from AUR

Expected behavior

VAAPI available for AMDGPU

Actual behavior

no vaapi, only vaapi-copy works.

Log file

LOG.log.zip

[kevmitch]

Does it work with --gpu-context=x11egl? There's #5298. but we might hold off on merging that until this gets into mesa and libva releases.

[Gusar321]

You need to patch both libva-git and mesa-git if you want vaapi-egl interop on AMD

In libva-git, you need to bump the API version, change the minor version here to 1: https://github.com/01org/libva/blob/master/configure.ac#L30
In mesa, you need to apply this patch: https://lists.freedesktop.org/archives/mesa-dev/2017-December/178971.html

[JulianLai]

@kevmitch No
@Gusar321 The VA-API version is 1.1.0 now, how to apply the patch for mesa-git?

libva info: VA-API version 1.1.0
libva info: va_getDriverName() returns 0
libva info: Trying to open /usr/lib/dri/radeonsi_drv_video.so
libva error: /usr/lib/dri/radeonsi_drv_video.so has no function __vaDriverInit_1_1
libva info: va_openDriver() returns -1
vaInitialize failed with error code -1 (unknown libva error),exit

By the way, there is no vaapi-copy either if I bump the VA-API version to 1.1.0

[JulianLai]

When will they release libva2.1? Does anybody know?

[yol]

Is this actually supposed to work at the moment? I have libva from git and patched mesa, ffmpeg, and mpv from git (to remove the VA-API version check, might have been easier to bump the libva version but result is the same), but I only get garbled video display (see below). Hardware decoding does work in principle, but somehow showing the result isn't working out correctly. --hwdec=vaapi-copy instead of --hwdec=vaapi works. Using it with wayland+egl if that matters.

[Traneptora]

If you removed the VA-API version check to force it to work with a version marked as incompatible, you should not be surprised when it doesn't work.

[yol]

@thebombzen With the current state of things there is no VA-API release or branch for which the version check holds true. Still, the code is there in mesa, ffmpeg, and mpv, because everyone expects vaExportSurfaceHandle to land in the next VA-API version to be released and expects that API version number to be 1.1.0 (current is 1.0.0). That said, with VA-API from git master (undefined post-1.0.0 version) you can either bump the version in va_version.h or remove the check on the mpv side. It's the exact same thing with the exact same code running. Since the code to support this is clearly there in mpv, I can at least ask if it should be working and see if someone wants to fix it, right?

[Traneptora]

It sounds like something on your system is broken, because the VA-API check works here just fine.

[yol]

@thebombzen Can you elaborate? What "VA-API check" do you mean?

[Gusar321]

libva-git now has the correct API version, so I tried the new interface. I can only test Intel for now, and what I can report is that it works correctly. @pkerling try again with an unmodified libva-git/ffmpeg-git/mpv-git and this patch for mesa: https://lists.freedesktop.org/archives/mesa-dev/2017-December/178971.html. If it's still the same, it's a radeon driver bug.

[yol]

@Gusar321 I tried but it does not change anything, which is unsurprising since the code that runs is effectively the same. Also the patch for mesa is upstream now.

And yes, it does work on intel, also for me. But it may not be a bug in mesa either, since it works correctly in Kodi.

[Gusar321]

I got my hands on an AMD card. It's an older chipset, uses the r600 mesa driver. And well, it works.
vainfo: http://0x0.st/sTi2.log
mpv log: http://0x0.st/sTi_.log
screenshot:

That means I have Intel working and r600 working. So it's either a radeonsi bug or something specific to your setup. Anyone else here who uses the radeonsi driver that could test?

[yol]

Finally found it - I had mesa compiled without --enable-texture-float. Works for me now.

[valpackett]

Hi everyone!

I upgraded to mpv 0.28.2 and got VAAPI working on Wayland (--vo gpu --gpu-context wayland --hwdec vaapi, AMD Polaris, FreeBSD 12-CURRENT, Mesa 18.1-devel)

But on x11egl or x11 it's not working:

[vaapi] libva: va_getDriverName() failed with unknown libva error,driver_name=(null)
Failed to open VDPAU backend Shared object "libvdpau_nvidia.so" not found, required by "mpv"
[vaapi] libva: va_getDriverName() failed with unknown libva error,driver_name=(null)

It's actually refreshing to see something work on Wayland but not X11, usually it's the other way around :D But why would the driver name not return on X11…

UPDATE: only happens in Xwayland. Acceleration works in native Xorg

[yol]

The problem is that Xwayland does not support DRI2, see intel/libva#79
It should work if you set LIBVA_DRIVER_NAME=radeonsi to skip the misbehaving autodetection.

[laichiaheng]

The VAAPI is still not working for my AMD RX460 in native Xorg (mpv-build-git from AUR, Mesa 18.1.0-devel, libva 2.1.0-1)
Does the --enable-texture-float must to be disabled to enable the vaapi hwdec?

[shmerl]

I can confirm, that using this config works for me with Mesa 18.3.0 release candidates and AMD Vega 56:

vo=gpu
gpu-api=opengl
hwdec=vaapi
gpu-context=x11egl

I tried using gpu-api=vulkan, but Debian still didn't package shaderc, so I might try building it manually first.

What's recommended way to combine Vulkan and vaapi? I suppose EGL isn't relevant for such case?

[valpackett]

Yes, EGL isn't relevant, Vulkan has its own WSI (Window System Interface).

LIBVA_DRIVER_NAME=radeonsi mpv --gpu-context=waylandvk --hwdec=auto works for me (on Wayland)

[kode54]

@pkerling The garbled output you see is due to mismatched color surface formats. AMDGPU apparently enabled RGBA-10-10-10-2 and RGB-10-10-10-0, which some applications don't handle properly when dealing with hardware video decoding.

[yol]

@kode54 Did you read #5305 (comment) ?

[kode54]

Apparently, I was so quick to reply, I didn't read the entire thread. Sorry.