chromium: hardware video acceleration with VA-API

akarshanbiswas · 2020-01-20 04:34:58

Guys!!! It's happening!!!!

https://bugzilla.mozilla.org/show_bug.cgi?id=1610199

liewkj · 2020-01-20 05:34:14

Well, that does not help chromium-vaapi. GStreamer-vaapi already works for Intel GPU on Wayland. GNOME Web/Epiphany supports GStreamer and video playback can be accelerated on Wayland. The only problem with GNOME Web/Epiphany is lacking YouTube plugin to force accelerated video formats that are supported by the hardware.

If someone comes up with YouTube plugin for GNOME Web/Epiphany, then it will become a serious contender to chromium-vaapi.

akarshanbiswas · 2020-01-20 07:26:47

liewkj wrote:

Well, that does not help chromium-vaapi. GStreamer-vaapi already works for Intel GPU on Wayland. GNOME Web/Epiphany supports GStreamer and video playback can be accelerated on Wayland. The only problem with GNOME Web/Epiphany is lacking YouTube plugin to force accelerated video formats that are supported by the hardware.
If someone comes up with YouTube plugin for GNOME Web/Epiphany, then it will become a serious contender to chromium-vaapi.

Well gnome web/epiphany has a problem. Since it is built using gtk there is an excessive surface reconfiguration bug on Wayland which effects the performance drastically. For gst-vaapi, well unless export EGLImage to dmabuf is implemented, it won't work on amdgpus. There are lot of bugs to fix there.

Excessive surface reconfiguration bug on wayland: https://gitlab.gnome.org/GNOME/gtk/issues/2311
EGLImage to dmabuf WIP: https://gitlab.freedesktop.org/gstreame … quests/122

liewkj · 2020-01-20 11:50:58

akarshanbiswas wrote:

Well gnome web/epiphany has a problem. Since it is built using gtk there is an excessive surface reconfiguration bug on Wayland which effects the performance drastically. For gst-vaapi, well unless export EGLImage to dmabuf is implemented, it won't work on amdgpus. There are lot of bugs to fix there.

I don't think those issues affect Intel GPU, but you are right that gstreamer-vaapi does not quite play along with AMDGPU/MESA VA driver.
Well, I just checked out GNOME Web/Epiphany on my Intel laptop with Intel Skylake GPU. I used test H.264 video from http://www.html5videoplayer.net/html5vi … ideo-test/ and intel_gpu_top was showing activities with the video engine. That means GNOME Web/Epiphany is able to leverage video acceleration through gstreamer-vaapi. This is on an up-to-date ArchLinux with GNOME/Wayland.

For those who have Kabylake+ Intel GPUs with VP9 support, GNOME Web/Epiphany should be able to have video acceleration for YouTube.

Last edited by liewkj (2020-01-20 11:53:32)

liewkj · 2020-01-21 02:36:49

Finally, I confirmed it myself that all the Wayland craps can be resolved by downgrading to xorg-server-xwayland 1.19.7, the last stable release from 1.19-branch.

commit 937391523eef6459d1f8b1ae25fe7e1f77b8a12a (HEAD, tag: xorg-server-1.19.7, origin/server-1.19-branch)
Author: Kevin Brace <kevinbrace@gmx.com>
Date:   Sat Mar 2 14:13:20 2019 -0800

    xserver 1.19.7
    
    Signed-off-by: Kevin Brace <kevinbrace@gmx.com>

And only this package, the rest of xorg-server packages can remain upstream. Moreover rubbing salt in the wounds, no matter how frustrated we had reported Wayland issues to Google Chromium team, they seemed to be triaging Wayland issues on Ubuntu 18.04LTS. Guess what? Ubuntu 18.04LTS is keeping xwayland from 1.19-branch while the rest of the Xorg packages at 1.20-branch! So, Google Chromium devs were not able to reproduce the issues!

So I did the same to my ArchLinux and boomed all the Wayland craps were resolved, no more V-Sync issue and chromium-vaapi perfectly plays back videos with acceleration with "--use-gl=egl" on GNOME/Wayland.

It is disappointing that the XWayland V-Sync issue with respect to Chromium is getting nowhere from the upstream. The upstream master-branch solved the V-Sync issue but chromium performance remains poor when flag "--use-gl=egl" is used. And it is not just for VA-API, typical page 2D rendering and WebGL are all affected by poor performance whenever the flag is used.
https://bugs.chromium.org/p/chromium/is … id=1041228

Unfortunately for Intel GPUs, "--use-gl=egl" is the only way to get VA-API in action on Wayland session. I am now leaning towards that this is indeed Google Chromium issue to debug and fix the V-Sync of Chromium EGL surface presentation to match the behavior of xwayland from 1.20-branch, mostly likely due to the new multi-buffering scheme.

Last edited by liewkj (2020-01-21 08:04:36)

liewkj · 2020-01-22 16:12:28

Upstream Chromium acknowledged the bug and is working on the fix.

Issue 1041229: Flag --use-gl=egl unable to select gl::kGLImplementationEGLGLES2 during VADisplayState::InitializeOnce()

As expected, they did not simply take the ugly patch but will be fixing it the right way. Hopefully, next Chromium release will support hardware video acceleration on Wayland for i965 VA driver.

Last edited by liewkj (2020-01-22 16:13:19)

maximbaz · 2020-01-22 19:37:04

liewkj: I am giving Wayland another try I noticed that if I launch chromium using "--use-gl=egl" using either driver, videos become very visibly laggy - is this known? Do you also experience this? If I use iHD driver, I do get MojoVideoDecoder, but as per the bug you referenced, i965 driver throws some errors. But these lags with --use-gl=egl are so visible...

liewkj · 2020-01-23 04:04:14

maximbaz wrote:

liewkj: I am giving Wayland another try I noticed that if I launch chromium using "--use-gl=egl" using either driver, videos become very visibly laggy - is this known? Do you also experience this? If I use iHD driver, I do get MojoVideoDecoder, but as per the bug you referenced, i965 driver throws some errors. But these lags with --use-gl=egl are so visible...

You are definitely not alone , but we will have to wait for this bug to get traction and resolved at Chromium upstream.

Issue 1041228: Poor performance with --use-gl=egl on XWayland (GNOME/Wayland)

I am experiencing the issue on 4 different systems at my disposals, all running up-to-date ArchLinux with GNOME/Wayland.

NVIDIA GT730/nouveau - Desktop
Intel Haswell - Laptop
Intel Skylake GT2 - Laptop
Ryzen APU - Laptop.

Unfortunately since corporate worlds are all about Ubuntu LTS these days, the last 18.04LTS will not have the issue. For quick and dirty workaround today on ArchLinux, I just created custom AUR package for xwayland and keep it at 1.19.7, similar to Ubuntu 18.04LTS.

$ pacman -Qs xorg-server | grep ^[a-z]
local/xorg-server 1.20.7-1 (xorg)
local/xorg-server-common 1.20.7-1 (xorg)
local/xorg-server-devel 1.20.7-1 (xorg)
**local/xorg-server-xwayland0 1.19.7-1 (xorg)**

akarshanbiswas · 2020-01-24 15:11:16

I have build chromium with ozone support to see if it can decode video using vaapi while running in ozone wayland.

Faced this error:

[34369:34369:0124/203225.848300:ERROR:sandbox_linux.cc(372)] InitializeSandbox() called with multiple threads in process gpu-process.
[34369:34369:0124/203412.800498:ERROR:gbm_pixmap_wayland.cc(77)] Cannot create bo with format= YUV_420_BIPLANAR and usage SCANOUT_VDA_WRITE
[34369:34369:0124/203412.800680:ERROR:vaapi_picture_native_pixmap_ozone.cc(104)] Failed allocating a pixmap
[34642:16:0124/203412.801511:ERROR:batching_media_log.cc(26)] MediaEvent: MEDIA_ERROR_LOG_ENTRY {"error":"VDA Error 4"}
[34369:34369:0124/203420.414844:ERROR:gbm_pixmap_wayland.cc(77)] Cannot create bo with format= YUV_420_BIPLANAR and usage SCANOUT_VDA_WRITE
[34369:34369:0124/203420.414894:ERROR:vaapi_picture_native_pixmap_ozone.cc(104)] Failed allocating a pixmap
[34642:16:0124/203420.415527:ERROR:batching_media_log.cc(26)] MediaEvent: MEDIA_ERROR_LOG_ENTRY {"error":"VDA Error 4"}
[34369:34369:0124/203420.629581:ERROR:gbm_pixmap_wayland.cc(77)] Cannot create bo with format= YUV_420_BIPLANAR and usage SCANOUT_VDA_WRITE
[34369:34369:0124/203420.629631:ERROR:vaapi_picture_native_pixmap_ozone.cc(104)] Failed allocating a pixmap
[34642:16:0124/203420.629859:ERROR:batching_media_log.cc(26)] MediaEvent: MEDIA_ERROR_LOG_ENTRY {"error":"VDA Error 4"}
[34369:34369:0124/203422.241528:ERROR:gbm_pixmap_wayland.cc(77)] Cannot create bo with format= YUV_420_BIPLANAR and usage SCANOUT_VDA_WRITE
[34369:34369:0124/203422.241577:ERROR:vaapi_picture_native_pixmap_ozone.cc(104)] Failed allocating a pixmap
[34642:16:0124/203422.242067:ERROR:batching_media_log.cc(26)] MediaEvent: MEDIA_ERROR_LOG_ENTRY {"error":"VDA Error 4"}

@liewkj do you think it can be fixed?

sapjunior · 2020-02-02 06:35:42

liewkj wrote:

maximbaz wrote:
liewkj: I am giving Wayland another try I noticed that if I launch chromium using "--use-gl=egl" using either driver, videos become very visibly laggy - is this known? Do you also experience this? If I use iHD driver, I do get MojoVideoDecoder, but as per the bug you referenced, i965 driver throws some errors. But these lags with --use-gl=egl are so visible...
You are definitely not alone , but we will have to wait for this bug to get traction and resolved at Chromium upstream.
Issue 1041228: Poor performance with --use-gl=egl on XWayland (GNOME/Wayland)
I am experiencing the issue on 4 different systems at my disposals, all running up-to-date ArchLinux with GNOME/Wayland.
NVIDIA GT730/nouveau - Desktop
Intel Haswell - Laptop
Intel Skylake GT2 - Laptop
Ryzen APU - Laptop.
Unfortunately since corporate worlds are all about Ubuntu LTS these days, the last 18.04LTS will not have the issue. For quick and dirty workaround today on ArchLinux, I just created custom AUR package for xwayland and keep it at 1.19.7, similar to Ubuntu 18.04LTS.
$ pacman -Qs xorg-server | grep ^[a-z]
local/xorg-server 1.20.7-1 (xorg)
local/xorg-server-common 1.20.7-1 (xorg)
local/xorg-server-devel 1.20.7-1 (xorg)
**local/xorg-server-xwayland0 1.19.7-1 (xorg)**

Could you please share your makepkg file? It might be useful for wayland users

Thank you

accron · 2020-02-06 13:15:17

I simply can't seem to get video acceleration to work in Chromium vaapi.

This is the output of vainfo:

vainfo: VA-API version: 1.6 (libva 2.6.0)
vainfo: Driver version: Intel iHD driver - 19.4.0
vainfo: Supported profile and entrypoints
VAProfileNone : VAEntrypointVideoProc
VAProfileNone : VAEntrypointStats
VAProfileMPEG2Simple : VAEntrypointVLD
VAProfileMPEG2Simple : VAEntrypointEncSlice
VAProfileMPEG2Main : VAEntrypointVLD
VAProfileMPEG2Main : VAEntrypointEncSlice
VAProfileH264Main : VAEntrypointVLD
VAProfileH264Main : VAEntrypointEncSlice
VAProfileH264Main : VAEntrypointFEI
VAProfileH264Main : VAEntrypointEncSliceLP
VAProfileH264High : VAEntrypointVLD
VAProfileH264High : VAEntrypointEncSlice
VAProfileH264High : VAEntrypointFEI
VAProfileH264High : VAEntrypointEncSliceLP
VAProfileVC1Simple : VAEntrypointVLD
VAProfileVC1Main : VAEntrypointVLD
VAProfileVC1Advanced : VAEntrypointVLD
VAProfileJPEGBaseline : VAEntrypointVLD
VAProfileJPEGBaseline : VAEntrypointEncPicture
VAProfileH264ConstrainedBaseline: VAEntrypointVLD
VAProfileH264ConstrainedBaseline: VAEntrypointEncSlice
VAProfileH264ConstrainedBaseline: VAEntrypointFEI
VAProfileH264ConstrainedBaseline: VAEntrypointEncSliceLP
VAProfileVP8Version0_3 : VAEntrypointVLD
VAProfileVP8Version0_3 : VAEntrypointEncSlice
VAProfileHEVCMain : VAEntrypointVLD
VAProfileHEVCMain : VAEntrypointEncSlice
VAProfileHEVCMain : VAEntrypointFEI
VAProfileHEVCMain10 : VAEntrypointVLD
VAProfileHEVCMain10 : VAEntrypointEncSlice
VAProfileVP9Profile0 : VAEntrypointVLD
VAProfileVP9Profile2 : VAEntrypointVLD

I have set $LIBVA_DRIVER_NAME to iHD.
Any suggestions are appreciated.

liewkj · 2020-02-06 21:28:55

accron wrote:

I simply can't seem to get video acceleration to work in Chromium vaapi.
Any suggestions are appreciated.

How did you conclude that video acceleration wasn't working for you in chromium-vaapi?
You need to show any errors indication that video acceleration wasn't working. Details from vainfo alone wasn't enough.
Are you on Wayland or Xorg session?

mbrennr · 2020-02-12 08:36:05

I'd like to thank everybody for their work and dedication on chromium-vaapi (and chromium-vaapi-bin).
And, of course libva-vdpau-driver-chromium.
I rolled back to chromium 78, and glibc 2.30.
This still works.

Asem · 2020-02-23 09:25:52

xtknight wrote:

For those interested, I have started an experimental project that modifies vdpau-va-driver (VAAPI wrapper) to include support for VP9 on NVIDIA GPUs. It seems to work for the videos I've tried so far and would appreciate more testers. Although I've tested only on Ubuntu 19.10, I don't think there should be any barriers for this working on ArchLinux.
https://github.com/xtknight/vdpau-va-driver-vp9

Many thanks @xtknight, i compiled your build with the patch mentioned here https://github.com/xtknight/vdpau-va-dr … 9/issues/5 and for the past 2 days VP9 decoding works without an issue.
4K/60 FPS video running smoothly with MojoDecoder and the CPU usage below 100% and fans are quite

The only exception is when trying an 8K60fps video which just crashes immediately , 8K 30FPS is fine

I can see the following error ,
vdp_output_surface_create(1, 0, 7680, 4352, -)
-> 23
vdp_get_error_string(23)
-> 'The system does not have enough resources to complete the requested operation at this time.'

But my GPU (GTX 1070) can handle decoding 8k60fps using nvdec

For me that's OK because I only have a 4K monitor and I only tried the 8K60fps video to test your wrapper

If you want to debug anyway here is the chromium log

http://ix.io/2csv

xuanrui · 2020-03-02 17:32:00

Is it the case that maximbaz has dropped chromium-vaapi from his repo? or is this temporary?

digitalone · 2020-03-02 21:16:24

xuanrui wrote:

Is it the case that maximbaz has dropped chromium-vaapi from his repo? or is this temporary?

Seems temporary, but you can get precompiled builds from archlinuxcn repository.

eschwartz · 2020-03-03 01:03:41

Why do you think it is only a temporary removal? If it was removed at all, presumably it was for a reason?

...

IIRC maximbaz mentioned switching to wayland and therefore firefox, so I'm not sure he's still invested in this.

DAC324 · 2020-03-12 11:45:03

Hello all,

I am using chromium-vaapi in the precompiled version from the Archlinuxcn repository, together with the libva-vdpau-driver-chromium patched according to the information from this thread, available from GitHub here.

vainfo says:

vainfo: VA-API version: 1.6 (libva 2.6.0)
vainfo: Driver version: Splitted-Desktop Systems VDPAU backend for VA-API - 0.7.4
vainfo: Supported profile and entrypoints
VAProfileMPEG2Simple : VAEntrypointVLD
VAProfileMPEG2Main : VAEntrypointVLD
VAProfileMPEG4Simple : VAEntrypointVLD
VAProfileMPEG4AdvancedSimple : VAEntrypointVLD
VAProfileH264ConstrainedBaseline: VAEntrypointVLD
VAProfileH264Main : VAEntrypointVLD
VAProfileH264High : VAEntrypointVLD
VAProfileVC1Simple : VAEntrypointVLD
VAProfileVC1Main : VAEntrypointVLD
VAProfileVC1Advanced : VAEntrypointVLD

However, Chromium spits the following in the log:

[1145:1145:0312/115844.846072:ERROR:vaapi_wrapper.cc(519)] : GetConfigAttributes failed for va_profile VAProfileH264ConstrainedBaseline
[1145:1145:0312/115844.846173:ERROR:vaapi_wrapper.cc(519)] : GetConfigAttributes failed for va_profile VAProfileH264Main
[1145:1145:0312/115844.846189:ERROR:vaapi_wrapper.cc(519)] : GetConfigAttributes failed for va_profile VAProfileH264High
[1145:1145:0312/115958.183142:WARNING:x11_util.cc(1443)] : X error received: serial 3738, error_code 3 (BadWindow), request_code 4, minor_code 0 (Unknown)
[1145:1232:0312/115958.280308:WARNING:x11_util.cc(1443)] : X error received: serial 6159, error_code 3 (BadWindow), request_code 4, minor_code 0 (Unknown)
[1145:1145:0312/120020.620391:WARNING:x11_util.cc(1443)] : X error received: serial 4442, error_code 3 (BadWindow), request_code 4, minor_code 0 (Unknown)
[1145:1232:0312/120020.630784:WARNING:x11_util.cc(1443)] : X error received: serial 7180, error_code 3 (BadWindow), request_code 4, minor_code 0 (Unknown)
[1145:1232:0312/120036.297935:WARNING:x11_util.cc(1443)] : X error received: serial 10753, error_code 3 (BadWindow), request_code 4, minor_code 0 (Unknown)
[1145:1232:0312/120625.794230:WARNING:x11_util.cc(1443)] : X error received: serial 50923, error_code 3 (BadWindow), request_code 4, minor_code 0 (Unknown)
[1145:1232:0312/121653.347866:WARNING:x11_util.cc(1443)] : X error received: serial 123202, error_code 3 (BadWindow), request_code 4, minor_code 0 (Unknown)
[1145:1232:0312/121744.882541:WARNING:x11_util.cc(1443)] : X error received: serial 126632, error_code 3 (BadWindow), request_code 4, minor_code 0 (Unknown)
[1145:1145:0312/122918.857263:WARNING:x11_util.cc(1443)] : X error received: serial 44339, error_code 3 (BadWindow), request_code 4, minor_code 0 (Unknown)
[1145:1232:0312/122918.873460:WARNING:x11_util.cc(1443)] : X error received: serial 142459, error_code 3 (BadWindow), request_code 4, minor_code 0 (Unknown)
[1145:1145:0312/122925.163003:WARNING:x11_util.cc(1443)] : X error received: serial 44615, error_code 3 (BadWindow), request_code 4, minor_code 0 (Unknown)
[1145:1232:0312/122925.173592:WARNING:x11_util.cc(1443)] : X error received: serial 142787, error_code 3 (BadWindow), request_code 4, minor_code 0 (Unknown)
[1145:1145:0312/123219.852643:WARNING:x11_util.cc(1443)] : X error received: serial 48236, error_code 3 (BadWindow), request_code 4, minor_code 0 (Unknown)
[1145:1232:0312/123219.863304:WARNING:x11_util.cc(1443)] : X error received: serial 150144, error_code 3 (BadWindow), request_code 4, minor_code 0 (Unknown)
[1145:1145:0312/123224.754264:WARNING:x11_util.cc(1443)] : X error received: serial 48572, error_code 3 (BadWindow), request_code 4, minor_code 0 (Unknown)
[1145:1232:0312/123224.763437:WARNING:x11_util.cc(1443)] : X error received: serial 151077, error_code 3 (BadWindow), request_code 4, minor_code 0 (Unknown)
[1145:1232:0312/123421.616140:WARNING:x11_util.cc(1443)] : X error received: serial 159358, error_code 3 (BadWindow), request_code 4, minor_code 0 (Unknown)
[1145:1232:0312/123544.034801:WARNING:x11_util.cc(1443)] : X error received: serial 163646, error_code 3 (BadWindow), request_code 4, minor_code 0 (Unknown)
[1145:1145:0312/123650.274278:WARNING:x11_util.cc(1443)] : X error received: serial 57976, error_code 3 (BadWindow), request_code 4, minor_code 0 (Unknown)
[1145:1232:0312/123650.370038:WARNING:x11_util.cc(1443)] : X error received: serial 175491, error_code 3 (BadWindow), request_code 4, minor_code 0 (Unknown)
[1145:1232:0312/123709.437141:WARNING:x11_util.cc(1443)] : X error received: serial 176380, error_code 3 (BadWindow), request_code 4, minor_code 0 (Unknown)
[1145:1145:0312/123753.109794:WARNING:x11_util.cc(1443)] : X error received: serial 60417, error_code 3 (BadWindow), request_code 4, minor_code 0 (Unknown)
[1145:1232:0312/123753.121798:WARNING:x11_util.cc(1443)] : X error received: serial 181614, error_code 3 (BadWindow), request_code 4, minor_code 0 (Unknown)

GPU is a nVidia GTX550 Ti with driver version 390. I am on Xorg, not Wayland.

Is there anything that has to be configured in order to remedy the errors in the log?

Thank you very much and kind regards,

DAC324

justkdng · 2020-03-19 14:26:02

@DAC324

That is a really old GPU, try using Nouveau and vaapi instead of the nvidia drivers and vdpau, it should work better.

liewkj · 2020-03-19 23:05:33

I was able to use nvidia-390xx on NVIDIA GT730 Kepler and VAAPI worked through the wrapper libva-vdpau-driver-chromium for Chromium-vaapi. That was after nvidia-390xx being dropped from official ArchLinux repo and moved to AUR. I had to build the drivers out from AUR for kernel 5.5.8. If you were unaware of the move that nvidia-390xx is now with AUR and what this means to you, then the first thing for you to do is to refresh the nvidia-390xx packages from AUR. That should rebuild the drivers for the upstream kernel.

With the package now in AUR, if you decided to keep on using nvidia-390xx, then you will need to install dkms and have to drivers rebuild on every upstream kernel update. Or search for unofficial repo that will do this for you, or as someone already suggested, start looking into Nouveau driver as a hassle-free alternative.

RainmakerRaw · 2020-04-03 00:13:14

I have Arch installed with the LTS kernel (the regular kernel crashes my Threadripper 3960X). I installed chromium-vaapi from ArchLinuxCN and also ungoogled-chromium (to test, as both have VAAPI enabled), but I've notcied something. On either package when I play h264 YouTube videos or whatever, chrome://media-internals shows MojoVideoDecoder, which is great. However, in chrome://flags the flags to enable hardware video acceleration are greyed out in the 'Not available on your platform' section. So what gives? Is it using VAAPI as per Mojo being listed, or isn't it, as per the flags being unavailable? I do have the flag to override the software rendering list enabled, btw, and chrome://gpu shows hardware acceleration in green.

First world problems and all, as my 3960X has so many threads I show less than 1% CPU usage either way, so that's not diagnostic. The radeontop package doesn't help either, as unlike the intel_gpu_tools package it doesn't have an entry for 'video'. While, as I said, it doesn't really matter either way on this system, it does on the other much feebler systems at home that I may wish to switch to Arch (from Ubuntu, Debian, Fedora, OpenSUSE etc). So I'm curious. Any ideas?

liewkj · 2020-04-03 02:54:46

RainmakerRaw wrote:

On either package when I play h264 YouTube videos or whatever, chrome://media-internals shows MojoVideoDecoder, which is great. However, in chrome://flags the flags to enable hardware video acceleration are greyed out in the 'Not available on your platform' section. So what gives? Is it using VAAPI as per Mojo being listed, or isn't it, as per the flags being unavailable?

You do have video acceleration working when MojoVideoDecoder showed up. The chrome://flags simply reflects an unsupported feature in Linux. Any desktop class multi-core CPU in the last 10 years can do H.264 decode up to 1080p at no sweat.

dimischiavone · 2020-04-08 14:03:27

Hi, i have problems with chromium-vaapi in the last 2 versions(80.0.3987.163 and the one before this). The issue is that on youtube videos higher than 720p or videos higher than 720p and 60 fps lag. I can cofirm that hardware decoding is working by inspecting chrome://media-internals and all is properly setup(since i've been using it for long without issues). When that happens if i insepct nerd statistics on youtube i notice that many frames get simply dropped at those resolutions and the cpu goes skyrocket to 100% on many cores. My laptop is t495s amd ryzen 3700u pro with the 5.6.2 kernel. I also tried reverting the kernel but the issue looks like is the chromium build. Has anyone run into these issues aswell?

justkdng · 2020-04-09 02:08:33

@dimischiavone

probably a mesa problem and not chromium as the mesa packages were recently updated, try downgrading.

justkdng · 2020-04-09 03:10:05

Tried to compile chromium 81.0.4044.92 with the existing vaapi patches and the compilation fails at this step

[ 2028s] [19263/38168] CXX obj/media/gpu/vaapi/vaapi/vaapi_webp_decoder.o
[ 2028s] [19264/38168] CXX obj/media/gpu/vaapi/vaapi/vp8_encoder.o
[ 2028s] [19265/38168] CXX obj/media/gpu/vaapi/vaapi/vp9_encoder.o
[ 2029s] [19266/38168] CXX obj/media/gpu/vaapi/vaapi/vp8_vaapi_video_decoder_delegate.o
[ 2029s] [19267/38168] CXX obj/media/gpu/vaapi/vaapi/vaapi_picture_tfp.o
[ 2029s] FAILED: obj/media/gpu/vaapi/vaapi/vaapi_picture_tfp.o 
[ 2029s] clang++ -MMD -MF obj/media/gpu/vaapi/vaapi/vaapi_picture_tfp.o.d -DMEDIA_GPU_IMPLEMENTATION -DUSE_UDEV -DUSE_AURA=1 -DUSE_GLIB=1 -DUSE_NSS_CERTS=1 -DUSE_X11=1 -DOFFICIAL_BUILD -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -DNO_UNWIND_TABLES -D_GNU_SOURCE -DCR_CLANG_REVISION=\"n340759-eaabaf7e-1\" -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D_FORTIFY_SOURCE=2 -DNDEBUG -DNVALGRIND -DDYNAMIC_ANNOTATIONS_ENABLED=0 -DGLIB_VERSION_MAX_ALLOWED=GLIB_VERSION_2_40 -DGLIB_VERSION_MIN_REQUIRED=GLIB_VERSION_2_40 -DVK_NO_PROTOTYPES -DGL_GLEXT_PROTOTYPES -DUSE_GLX -DUSE_EGL -DSK_HAS_PNG_LIBRARY -DSK_HAS_WEBP_LIBRARY -DSK_USER_CONFIG_HEADER=\"../../skia/config/SkUserConfig.h\" -DSK_GL -DSK_HAS_JPEG_LIBRARY -DSK_USE_LIBGIFCODEC -DSK_VULKAN_HEADER=\"../../skia/config/SkVulkanConfig.h\" -DSK_VULKAN=1 -DSK_SUPPORT_GPU=1 -DSK_GPU_WORKAROUNDS_HEADER=\"gpu/config/gpu_driver_bug_workaround_autogen.h\" -DVK_NO_PROTOTYPES -DGOOGLE_PROTOBUF_NO_RTTI -DGOOGLE_PROTOBUF_NO_STATIC_INITIALIZER -DHAVE_PTHREAD -DLEVELDB_PLATFORM_CHROMIUM=1 -DLEVELDB_PLATFORM_CHROMIUM=1 -DUSING_SYSTEM_ICU=1 -DICU_UTIL_DATA_IMPL=ICU_UTIL_DATA_STATIC -DUCHAR_TYPE=uint16_t -DU_IMPORT=U_EXPORT -I../.. -Igen -I../../third_party/libyuv/include -Igen/shim_headers/zlib_shim -Igen/shim_headers/libwebp_shim -Igen/shim_headers/icuuc_shim -Igen/shim_headers/icui18n_shim -I../../third_party/perfetto/include -Igen/third_party/perfetto/build_config -Igen/third_party/perfetto -I../../third_party/vulkan/include -Igen/shim_headers/re2_shim -Igen/shim_headers/ffmpeg_shim -Igen/shim_headers/libvpx_shim -Igen/shim_headers/snappy_shim -I../../third_party/khronos -I../../gpu -Igen/shim_headers/opus_shim -Igen/third_party/dawn/src/include -I../../third_party/dawn/src/include -I../../third_party/libwebm/source -I../../third_party/boringssl/src/include -I../../third_party/skia -I../../third_party/libgifcodec -I../../third_party/vulkan/include -I../../third_party/skia/third_party/vulkanmemoryallocator -I../../third_party/vulkan/include -I../../third_party/protobuf/src -Igen/protoc_out -I../../third_party/protobuf/src -I../../third_party/leveldatabase -I../../third_party/leveldatabase/src -I../../third_party/leveldatabase/src/include -I../../third_party/crashpad/crashpad -I../../third_party/crashpad/crashpad/compat/non_mac -I../../third_party/crashpad/crashpad/compat/linux -I../../third_party/crashpad/crashpad/compat/non_win -I../../third_party/ced/src -I../../third_party/mesa_headers -fprofile-sample-use=../../chrome/android/profiles/afdo.prof -fno-strict-aliasing --param=ssp-buffer-size=4 -fstack-protector -fno-unwind-tables -fno-asynchronous-unwind-tables -fPIC -pthread -fcolor-diagnostics -fmerge-all-constants -fcrash-diagnostics-dir=../../tools/clang/crashreports -Xclang -mllvm -Xclang -instcombine-lower-dbg-declare=0 -flto=thin -fsplit-lto-unit -fwhole-program-vtables -m64 -march=x86-64 -no-canonical-prefixes -Wall -Wextra -Wimplicit-fallthrough -Wthread-safety -Wextra-semi -Wno-missing-field-initializers -Wno-unused-parameter -Wno-c++11-narrowing -Wno-unneeded-internal-declaration -Wno-undefined-var-template -Wno-ignored-pragma-optimize -Wno-implicit-int-float-conversion -Wno-final-dtor-non-final-class -Wno-bitwise-conditional-parentheses -Wno-builtin-assume-aligned-alignment -Wno-deprecated-copy -Wno-misleading-indentation -Wno-range-loop-analysis -O2 -fno-ident -fdata-sections -ffunction-sections -fno-omit-frame-pointer -g0 -fsanitize=cfi-vcall -fsanitize-blacklist=../../tools/cfi/blacklist.txt -fsanitize=cfi-icall -fvisibility=hidden -Wheader-hygiene -Wstring-conversion -Wtautological-overlap-compare -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/lib/libffi-3.2.1/include -Wno-shorten-64-to-32 -std=c++14 -fno-exceptions -fno-rtti -fvisibility-inlines-hidden -D_FORTIFY_SOURCE=2 -D__DATE__=  -D__TIME__=  -D__TIMESTAMP__= -march=x86-64 -mtune=generic -O2 -pipe -fno-plt -Wno-builtin-macro-redefined -Wno-unknown-warning-option -c ../../media/gpu/vaapi/vaapi_picture_tfp.cc -o obj/media/gpu/vaapi/vaapi/vaapi_picture_tfp.o
[ 2029s] ../../media/gpu/vaapi/vaapi_picture_tfp.cc:60:20: error: no matching constructor for initialization of 'gl::GLImageGLX'
[ 2029s]   glx_image_ = new gl::GLImageGLX(size_, GL_RGB);
[ 2029s]                    ^              ~~~~~~~~~~~~~
[ 2029s] ../../ui/gl/gl_image_glx.h:20:3: note: candidate constructor not viable: no known conversion from 'int' to 'gfx::BufferFormat' for 2nd argument
[ 2029s]   GLImageGLX(const gfx::Size& size, gfx::BufferFormat format);
[ 2029s]   ^
[ 2029s] ../../ui/gl/gl_image_glx.h:57:28: note: candidate constructor not viable: requires 1 argument, but 2 were provided
[ 2029s]   DISALLOW_COPY_AND_ASSIGN(GLImageGLX);
[ 2029s]                            ^
[ 2029s] 1 error generated.
[ 2029s] [19268/38168] CXX obj/media/gpu/vaapi/vaapi/vp9_vaapi_video_decoder_delegate.o
[ 2029s] [19269/38168] CXX obj/media/gpu/vaapi/vaapi/va_surface.o
[ 2029s] [19270/38168] CXX obj/media/gpu/vaapi/vaapi/h264_encoder.o

Here's the full log and the sources I'm using: https://build.opensuse.org/package/live … ard/x86_64

Last edited by justkdng (2020-04-09 03:18:42)

Arch Linux

#276 2020-01-20 04:34:58

Re: chromium: hardware video acceleration with VA-API

#277 2020-01-20 05:34:14

Re: chromium: hardware video acceleration with VA-API

#278 2020-01-20 07:26:47

Re: chromium: hardware video acceleration with VA-API

#279 2020-01-20 11:50:58

Re: chromium: hardware video acceleration with VA-API

#280 2020-01-21 02:36:49

Re: chromium: hardware video acceleration with VA-API

#281 2020-01-22 16:12:28

Re: chromium: hardware video acceleration with VA-API

#282 2020-01-22 19:37:04

Re: chromium: hardware video acceleration with VA-API

#283 2020-01-23 04:04:14

Re: chromium: hardware video acceleration with VA-API

#284 2020-01-24 15:11:16

Re: chromium: hardware video acceleration with VA-API

#285 2020-02-02 06:35:42

Re: chromium: hardware video acceleration with VA-API

#286 2020-02-06 13:15:17

Re: chromium: hardware video acceleration with VA-API

#287 2020-02-06 21:28:55

Re: chromium: hardware video acceleration with VA-API

#288 2020-02-12 08:36:05

Re: chromium: hardware video acceleration with VA-API

#289 2020-02-23 09:25:52

Re: chromium: hardware video acceleration with VA-API

#290 2020-03-02 17:32:00

Re: chromium: hardware video acceleration with VA-API

#291 2020-03-02 21:16:24

Re: chromium: hardware video acceleration with VA-API

#292 2020-03-03 01:03:41

Re: chromium: hardware video acceleration with VA-API

#293 2020-03-12 11:45:03

Re: chromium: hardware video acceleration with VA-API

#294 2020-03-19 14:26:02

Re: chromium: hardware video acceleration with VA-API

#295 2020-03-19 23:05:33

Re: chromium: hardware video acceleration with VA-API

#296 2020-04-03 00:13:14

Re: chromium: hardware video acceleration with VA-API

#297 2020-04-03 02:54:46

Re: chromium: hardware video acceleration with VA-API

#298 2020-04-08 14:03:27

Re: chromium: hardware video acceleration with VA-API

#299 2020-04-09 02:08:33

Re: chromium: hardware video acceleration with VA-API

#300 2020-04-09 03:10:05

Re: chromium: hardware video acceleration with VA-API

Board footer