Arch Linux User Repository

[Nvidia users PLEASE READ]

To get hardware acceleration working, you also have to install https://aur.archlinux.org/packages/libva-vdpau-driver-chromium

Disclaimer : VP8/9 video decoding will not work!

GeForce GTX 750 SE and after support HEVC and VP9 video decoding but VDPAU,the only VAAPI backend available for Nvidia users with libva-vdpau-driver, doesn't support VP8/9.

4 ways to solve this:

• Add VP9 support to VDPAU but it hasn't been actively maintained since at least 3 years
• Force the use of an other codec with an extension like h264ify
• Stream the video to mpv using https://aur.archlinux.org/packages/play-with-mpv-git/ and configure it to use the new NVDEC engine which does support VP9
• Make NVDEC able to be used by VA-API but it seems a dead-end (see https://devtalk.nvidia.com/default/topic/1033137/linux/whats-the-situation-with-vdpau-vaapi-nvdec- )

A couple of notes:

• it builds with llvm8-svn again after last 2 releases failing as mentioned before
• I had system crashes with jumbo build and ryzen hyperthreading enabled. It tried to use too much RAM and hangs. Doesn't happen if I disable SMT or jumbo build. I thought it was an unstable overclock at first but ended up consistently reproducing it @stock and underclocked.

Huh, interesting, you are right! Updated my post :P

@maximbaz: Only base-devel, not base. They are no assumption of any kind regarding base anywhere in Arch Linux. ;)

andrej: bison is part of base-devel group, and it is always assumed that base-devel group is installed when building AUR packages, check out this wiki page for more info.

I think that this package needs bison in its makedepends. Otherwise it tries to invokem bison and then fails quite early in the build process.

@axfelix Actually, there used to be VaapiDrmPicture class only. This year they broke the class into several sub classes which look like:

  +-----------------+
  |   VaapiPicture  |
  +-----------------+
  ^                 ^
  | =vaapi-drm=     +----+ =xorg(vaapi-glx)=
  +--------------+       +------------------+
  | VaapiPicture |       | VaapiPictureTFP  |
  | NativePixmap |       | (This is default)|
  +--------------+       +------------------+
   ^   
   +-------------------------+
   |                         |
 +-------+               +-------+
 | VPNP  |               | VPNP  |
 | Ozone |               | Egl   |
 +-------+               +-------+

*VPNP is Vaapi Picture Native Pixmap. I believe somewhere these sub classes(esp. VPNP ozone) are not being included during building and this is what causes the error during linking. I may be wrong because when I see the source I can't find anything unusual. That's why I'm trying to build it with use_ozone=true ozone_platform_gbm=true use_intel_minigbm=true and use_egl=true to include the whole set of those drm classes. I am not confident with this anyway tbh.

@ForeignCon

So I guess there's one Google employee trying to get the chromeOS GPU raster paths working on Linux, but they conflict with the out of tree Linux chromium GPU video decoding patches maintained by a different Google employee :) Thanks for trying!

@axfelix I have tried this, Build fails with this error:

./../media/gpu/vaapi/vaapi_picture_factory.cc:74: error: undefined reference to 'media::VaapiPictureNativePixmapOzone::VaapiPictureNativePixmapOzone(scoped_refptr<media::VaapiWrapper> const&, base::RepeatingCallback<bool ()> const&, base::RepeatingCallback<bool (unsigned int, unsigned int, scoped_refptr<gl::GLImage> const&, bool)> const&, int, gfx::Size const&, unsigned int, unsigned int, unsigned int)'
collect2: error: ld returned 1 exit status

axfelix: don't think so, am I right to understand that such build would only work on Intel GPUs? If you want to try, send me a patch to PKGBUILD and I can build it for you, in exchange you test the build and compare with current chromium and report back the results ;)

Have we tried building with "--args=use_ozone=true ozone_platform_gbm=true use_intel_minigbm=true" lately per https://01.org/blogs/joone/2018/using-chrome-os-graphics-stack-intel-based-linux-desktops? I understand that all of the relevant libminigbm stuff has been merged into Arch Mesa so there shouldn't be any weird dependencies to support at this point...