VA-API implementation for gallium missing

Thank you for taking the time to report this bug and helping to make Ubuntu better. It seems that your bug report is not filed about a specific source package though, rather it is just filed against Ubuntu in general. It is important that bug reports be filed about source packages so that people interested in the package can find the bugs about it. You can find some hints about determining what package your bug might be about at https://wiki.ubuntu.com/Bugs/FindRightPackage. You might also ask for help in the #ubuntu-bugs irc channel on Freenode.

To change the source package that this bug is filed about visit https://bugs.launchpad.net/ubuntu/+bug/1481832/+editstatus and add the package name in the text box next to the word Package.

[This is an automated message. I apologize if it reached you inappropriately; please just reply to this message indicating so.]

Status changed to 'Confirmed' because the bug affects multiple users.

The gallium va driver uses shaders for decoding and the VDPAU one uses native hardware decoding.. It's much worse.

In reaction to Robert Hooker about performance. Did some benchmarks with "mpv" and 1080i h264 transport stream footage trying all three possible acc. backends on [Radeon HD 6320].

*vdpau (native)
*Splitted-Desktop Systems VDPAU backend for VA-API
*mesa gallium vaapi

All of them seem to perform equally maybe some 1-5% difference. Maybe because there isn't real 'vdpau' on AMD so its implementation of vdpau is like the other VAAPI ones using the same optimize tricks (combination of hardwaredecoder/shaders/etc/gpu offload)?

nouveau: add support for vaapi
http://lists.freedesktop.org/archives/mesa-dev/2015-December/103327.html

> In reaction to Robert Hooker about performance.
> Did some benchmarks with "mpv" and 1080i h264 transport stream footage trying all three possible acc.
> backends on [Radeon HD 6320].
>
> *vdpau (native)
> *Splitte d-Desktop Systems VDPAU backend for VA-API
> *mesa gallium vaapi

> All of them seem to perform equally maybe some 1-5% difference.
> Maybe because there isn't real 'vdpau' on AMD so its implementation of vdpau
> is like the other VAAPI ones using the same optimize tricks
> (combination of hardwaredecoder/shaders/etc/gpu offload)?

Does the mesa gallium vaapi also supports the UVD video decoding in hardware as the vdpau driver does?

I just tested the vdpau and vaapi->vdpau against CPU only decoding (AMD64 dualcore) on a Radeon HD 3200 (RS780) playing a 1080i h264 sample.

I got a huge difference of less than 10% cpu load for vdpau to more than 100% load for CPU only decoding (didn't find vaapi option for mpv).

Also the vaapi->vdpau backend helped to reduce the cpu load for vlc 2.1.x using --avcodec-hw=vaapi from 100% to 35%. (only vlc from 2.2.x has native vdpau support).

I guess I will also have a look at the mesa gallium vaapi.

See bug #1441631 . It is required whenever you do HW decoding with "nouveau" driver (no matter the top level API i.e. vdpau, VA-APi, OMX ...)

(Any other solutions will necessarily uses the proprietary NVIDIA driver)

The native gallium vdpau and vaapi drivers accelerate video decode directly using UVD. Shaders are only used for codecs that were not directly supported by older UVD hardware. There is no need to use any sort of vdpau <-> vaapi translation layers; just use the native backend for whichever API you want to use.

So in the Ubuntu standard package gallium_drv_video.so is not package:
http://packages.ubuntu.com/xenial/amd64/mesa-vdpau-drivers/filelist

In oibaf for example it is package in the mesa-vdpau-drivers package.

Next problem is that vainfo does not recognize it by default. However with
export LIBVA_DRIVER_NAME=gallium
I get the following with radeonsi:

$ vainfo
libva info: VA-API version 0.38.1
libva info: va_getDriverName() returns 0
libva info: User requested driver 'gallium'
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/gallium_drv_video.so
libva info: Found init function __vaDriverInit_0_38
libva info: va_openDriver() returns 0
vainfo: VA-API version: 0.38 (libva 1.6.3.pre1)
vainfo: Driver version: mesa gallium vaapi
vainfo: Supported profile and entrypoints
      VAProfileMPEG2Simple : VAEntrypointVLD
      VAProfileMPEG2Main : VAEntrypointVLD
      VAProfileVC1Simple : VAEntrypointVLD
      VAProfileVC1Main : VAEntrypointVLD
      VAProfileVC1Advanced : VAEntrypointVLD
      VAProfileH264Baseline : VAEntrypointVLD
      VAProfileH264Main : VAEntrypointVLD
      VAProfileH264High : VAEntrypointVLD
      VAProfileHEVCMain : VAEntrypointVLD
      VAProfileNone : VAEntrypointVideoProc

enabling this would mean moving libva to main, and it'd also pull in ffmpeg and a plethora of other packages..

Then maybe at least provide PPA with Mesa builds with enabled VA-API support?
Here, for example: https://launchpad.net/~graphics-drivers

> Then maybe at least provide PPA with Mesa builds with enabled VA-API support?

You can get it here: https://launchpad.net/~oibaf/+archive/ubuntu/graphics-drivers/

> enabling this would mean moving libva to main, and it'd also pull in ffmpeg and a plethora of other packages..

This make sense, but expose anyway a limitation of current way of packaging in Ubuntu. Who need it is forced to install it from my PPA (or elsewhere), which is not supported by Ubuntu, and may not be what the user really want.

Oibaf, you mean there is native VA-API implementation via gallium_drv_video.so, not via vdpau-va-driver package?

I'm thinking of adding this to a supported PPA which would be available for 16.04 users. I hope archive re-org would fix issues with main/universe build-deps once and for all, but it's not going to happen for xenial.

This bug was fixed in the package mesa - 11.2.0-1ubuntu1

---------------
mesa (11.2.0-1ubuntu1) xenial; urgency=medium

  * Merge from debian. (LP: #1481832. #1548845)

mesa (11.2.0-1) experimental; urgency=medium

  [ Andreas Boll ]
  * control: Fix vdpau-va-driver Breaks/Replaces for mesa-va-drivers
    (Closes: #819655).
  * control: Bump Standards-Version to 3.9.7 (no changes).
  * watch: Update url to use https instead of ftp.

  [ Timo Aaltonen ]
  * New upstream release.
  * rules: Disable tests for now, most of them weren't run before anyway
    and they cause unnecessary ftbfs on some archs.

mesa (11.2.0~rc4-1) experimental; urgency=medium

  * New upstream release candidate.

mesa (11.2.0~rc3-2) experimental; urgency=medium

  * mesa-va-drivers: Build gallium VA driver, and add symlinks for
    nouveau, r600 and radeonsi.
  * control: Add vdpau-va-driver Breaks/Replaces for mesa-va-drivers.

mesa (11.2.0~rc3-1) experimental; urgency=medium

  * New upstream release candidate.
  * Drop upstreamed patches.
  * libgl1-mesa-glx.symbols: Remove dropped symbols.
  * rules,control: Drop -dbg packages, we have -dbgsym now.
  * rules, *.install.in, not-installed: Drop dri/-build prefix, we build
    everything in one pass nowadays.
  * control: Bump libdrm-dev build-dep to 2.4.67 for freedreno.
  * rules: Migrate to dh.
  * control: Add dh-autoreconf to build-depends.

 -- Timo Aaltonen <email address hidden> Tue, 05 Apr 2016 10:19:51 +0300