chromium: hardware video acceleration with VA-API

akarshanbiswas · 2019-10-15 10:43:43

maximbaz wrote:

Gotcha, well if you guys propose the fix to upstream your patch would of course be preferable comparing to `if (false &&`, but for us mere Linux users these approaches are imho identical, we just want to fix VA-API while we are waiting for upstream to fix their code

We need a better implementation than

if (false &&.....)

because it can break stuffs on chromeos before we can propose this upstream. Chromium just landed wl_drm support on chromium-ozone to support complete native hardware acceleration on amdgpu. They are working on libgtkui now.
I was partially successful in making vaapi work on chromium ozone on wayland but it's not stable.

See: https://chromium-review.googlesource.co … /+/1827001

digitalone · 2019-10-15 11:14:11

Declare a variable for Arch Linux and set it to false, then put it in the conditional statement.

justkdng · 2019-10-15 13:51:56

akarshanbiswas wrote:

because it can break stuffs on chromeos before we can propose this upstream.

whoah there mate, calm down. I think upstream in this discussion has meant arch's upstream (as in the chromium package) and not google's upstream. Let's not get ahead of ourselves.

maximbaz · 2019-10-15 14:04:55

Personally my suggestion was to prepare a proper good-looking patch that fixes the issue and submit it to Google's chromium repo (this is when we care about e.g. not breaking VA-API for ChromeOS), so that we can avoid patching chromium package in Arch altogether. But if we are only focusing on preparing patches for chromium-vaapi then I'm okay with small hacky patches that take shortcuts fix problems on Linux (and potentially break other OS).

justkdng · 2019-10-15 14:14:24

And can third parties even contribute to google's upstream? Isn't the source code viewable but only they edit it?
IMO just make a patch for linux and distribute it to other distros, especially the *buntus, then something could happen, after it has gone through extensive testing. More testing than the "It werks on my machine" we have from like 6 people here.

maximbaz · 2019-10-15 14:17:40

I believe it's possible to propose a patch, for example @akarshanbiswas linked above: https://chromium-review.googlesource.co … /+/1827001

akarshanbiswas · 2019-10-15 14:27:36

justkdng wrote:

akarshanbiswas wrote:
because it can break stuffs on chromeos before we can propose this upstream.
whoah there mate, calm down. I think upstream in this discussion has meant arch's upstream (as in the chromium package) and not google's upstream. Let's not get ahead of ourselves.

It's possible actually, no harm. Just need to inform one of the maintainers. For example Julien Isorce actually made easier for us to enable vaapi on Linux by turning on a gn flag(use_vaapi=true). Otherwise we had to patch those gn files as well.

digitalone · 2019-10-15 18:15:17

liewkj wrote:

Oh, Gosh!!! This is so wrong!!! Your vainfo just told me that you have perfectly native VA-API support from MESA VA driver, and that's how I took it that you should have hardware acceleration working.

Uninstalled vdpau and translation layers and vaapi hw decoding is working without issues on both chromium and mpv. Thanks.

liewkj · 2019-10-15 20:48:58

akarshanbiswas wrote:

...because it can break stuffs on chromeos before we can propose this upstream.

I seriously doubt if this actually works for ChromeOS, unless they have a specially crafted, locked-down kernel, Intel VA drivers and libva for meeting a strict power numbers for their OEM customers. Yes, I am convinced that skipping VPP is indeed a power optimization after scanning through upstream Chromium commit history. It sounds more like a test hole from code refactoring or back integration from Chromium/master into release branches. After all, none of the ChromeOS device was shipping with GeminiLake/KabyLake+ until recently. Most of them were ApolloLake on the values and SkyLake on the high-ends.

Of course, we won't be proposing the "if (false &&" patch to upstream, but for a patch this makes perfect sense. I believe Maximbaz got my point It touches the least number lines of code and has no "#if/#else/#endif" that produces chunky code blocks that are hard to trace or changes the original implementation behaviors by reducing {kNormal, kReduced, kSuperReduced, kNone} code path into just {kNormal}. The patch would live longer and have better likelihood to survive upstream code refactoring. As amateur Linux users we are, I don't think we stand to compete with Google for their thoroughness and comprehensiveness of software validation infrastructure, even if they are not perfect.

I think what we can do is to highlight the issue to upstream Chromium and let them decide on their own actions. The patch is so simple for anyone to understand. They could throw out the efforts of supporting NVIDIA blobs through VDPAU backend (in fact, not that I would care much as I simply anticipated stronger acceptance of the new patch if it would work for NVIDIA blobs similar to the old one).

liewkj · 2019-10-15 21:00:11

akarshanbiswas wrote:

For example Julien Isorce actually made easier for us to enable vaapi on Linux by turning on a gn flag(use_vaapi=true). Otherwise we had to patch those gn files as well.

Because they want to be able to launch vaapi unit tests on standard Linux boxes from their developers without having the constraints of "ChromeOS device only" test vehicles. This makes absolute perfect sense for develop & test efficiency. If I were ChromeOS release manager, I would have done the same. It's a no-brainer.

yabk · 2019-10-15 22:17:35

Hey guys, big thanks to you all for your work on this!

Here's my report on wayland (sway) with the current "chromium-vaapi-bin 77.0.3865.120-1" from aur:
Once I enable the --use-gl=egl flag, hardware acceleration works.
However, everything is laggy. Pages load really slow and even opening a new tab sometimes takes a second or 2 before it becomes usable. Using higher video quality on youtube (720p and up) causes massive frame drops.

When playing a video I get a bunch of these in the terminal output:

[83611:83611:1016/001304.080118:ERROR:sync_control_vsync_provider.cc(140)] Calculated bogus refresh interval=1.00016 s, last_timebase_=93179083446 bogo-microseconds, timebase=93180083604 bogo-microseconds, last_media_stream_counter_=504, media_stream_counter=505

As well as bunch of these in chrome://media-internals:

00:01:19.386	video_buffering_state	BUFFERING_HAVE_NOTHING (DECODER_UNDERFLOW)
00:01:19.390	video_buffering_state	BUFFERING_HAVE_ENOUGH

Please let me know if I can provide any additional information.

maximbaz · 2019-10-15 22:20:07

@yabk: to clarify, has it ever been better under sway, or this is the first time you were able to get VA-API working?

yabk · 2019-10-15 22:32:11

This is the first time hw is working for me on sway.

liewkj · 2019-10-15 23:04:54

@yabk And you vainfo, please.
Nevermind, I got it from your previous post if it remains the same. You may want to try X11 session instead of Wayland.
At the moment, the only success Wayland story for Intel GPU is from @CarbonChauvinist with SkyLake generation.
https://bbs.archlinux.org/viewtopic.php … 2#p1868252

OR, check out the new MESA Gallium3D based iris OpenGL driver for Intel, instead of exising DRI-based OpenGL drivers.
Please note, this is highly experimental, but reports have shown much improved GL performance for Intel latest and greatest, , which you have one , if you are lucky that the bugs aren't of your concerns.

Last edited by liewkj (2019-10-15 23:20:21)

yabk · 2019-10-15 23:29:43

@liewkj yes, my vainfo is the same.
Here it is, if others might be looking for it: https://bbs.archlinux.org/viewtopic.php … 5#p1860515

Thanks! I will look into the new driver.

akarshanbiswas · 2019-10-16 09:43:58

liewkj wrote:

@yabk And you vainfo, please.
Nevermind, I got it from your previous post if it remains the same. You may want to try X11 session instead of Wayland.
At the moment, the only success Wayland story for Intel GPU is from @CarbonChauvinist with SkyLake generation.
https://bbs.archlinux.org/viewtopic.php … 2#p1868252
OR, check out the new MESA Gallium3D based iris OpenGL driver for Intel, instead of exising DRI-based OpenGL drivers.
Please note, this is highly experimental, but reports have shown much improved GL performance for Intel latest and greatest, , which you have one , if you are lucky that the bugs aren't of your concerns.

It's not the chromium's fault that it cannot initialize vaapi on wayland through Xwayland on an intel GPU. Intel drivers lacks dri3 support. Someone should host an AUR repo for something like intel-vaapi-driver-chromium-vaapi with these patches:
1: https://github.com/intel/intel-vaapi-dr … da022773bb
2: https://github.com/intel/intel-vaapi-dr … a23c3eec81

liewkj · 2019-10-16 10:13:24

akarshanbiswas wrote:

It's not the chromium's fault that it cannot initialize vaapi on wayland through Xwayland on an intel GPU. Intel drivers lacks dri3 support. Someone should host an AUR repo for something like intel-vaapi-driver-chromium-vaapi with these patches:
1: https://github.com/intel/intel-vaapi-dr … da022773bb
2: https://github.com/intel/intel-vaapi-dr … a23c3eec81

Those 2 patches are useless. The owner just vanished and they never got merged.

akarshanbiswas · 2019-10-16 12:32:14

liewkj wrote:

akarshanbiswas wrote:
It's not the chromium's fault that it cannot initialize vaapi on wayland through Xwayland on an intel GPU. Intel drivers lacks dri3 support. Someone should host an AUR repo for something like intel-vaapi-driver-chromium-vaapi with these patches:
1: https://github.com/intel/intel-vaapi-dr … da022773bb
2: https://github.com/intel/intel-vaapi-dr … a23c3eec81
Those 2 patches are useless. The owner just vanished and they never got merged.

How do you know they are useless? Have you tried them?

Refer: https://github.com/intel/intel-vaapi-dr … -462149944

Last edited by akarshanbiswas (2019-10-16 12:32:28)

liewkj · 2019-10-16 18:15:40

akarshanbiswas wrote:

How do you know they are useless? Have you tried them?
Refer: https://github.com/intel/intel-vaapi-dr … -462149944

Yes, I did, but on Sandybridge and Haswell. I can't afford Intel's latest and greatest.... I read through completely the long list of conversation of those 2 patches, I have done my research. You should have done yours before suggesting those patches. They were abandoned and closed out of no activity and response from the original submitter.

liewkj wrote:

I did specially build i965 driver and libva with DRI3 patch, and that made VA-API work for gstreamer-vaapi and mpv-vaapi under Wayland session. However, Chromium-vaapi simply rendered video into total black screen. This was exactly the same issue the maintainer of i965 driver/libva was getting before the DRI3 patch submitter disappeared and abandoned his patchset. Someone pointed out that there were other issues on Wayland compositor with respect to refresh rate and buffers synchronization, but I could not track them down.

Those aren't making any difference to Chromium, but MojoVideoDecoder did show up and Chromium thought it had acceleration but video playback was all black with sound.

Intel's priority and focus have since moved on to iHD driver. The old i965 VA drivers was left as the open source playing ground, and up to the community for making miracles.

Last edited by liewkj (2019-10-16 20:17:37)

akarshanbiswas · 2019-10-17 20:34:38

liewkj wrote:

akarshanbiswas wrote:
How do you know they are useless? Have you tried them?
Refer: https://github.com/intel/intel-vaapi-dr … -462149944
Yes, I did, but on Sandybridge and Haswell. I can't afford Intel's latest and greatest.... I read through completely the long list of conversation of those 2 patches, I have done my research. You should have done yours before suggesting those patches. They were abandoned and closed out of no activity and response from the original submitter.
liewkj wrote:
I did specially build i965 driver and libva with DRI3 patch, and that made VA-API work for gstreamer-vaapi and mpv-vaapi under Wayland session. However, Chromium-vaapi simply rendered video into total black screen. This was exactly the same issue the maintainer of i965 driver/libva was getting before the DRI3 patch submitter disappeared and abandoned his patchset. Someone pointed out that there were other issues on Wayland compositor with respect to refresh rate and buffers synchronization, but I could not track them down.
Those aren't making any difference to Chromium, but MojoVideoDecoder did show up and Chromium thought it had acceleration but video playback was all black with sound.
Intel's priority and focus have since moved on to iHD driver. The old i965 VA drivers was left as the open source playing ground, and up to the community for making miracles.

Pardon me. I don't use intel. So I can't test those patches.

Sad indeed. I hope the new iHD driver gets dri3 support soon.

liewkj · 2019-10-17 23:54:45

It's a bad day for poor NVIDIA folks, who can't afford to upgrade and keep on with pre-Fermi GPUs. Chromium video acceleration is totally busted and no solution for them!
The NVIDIA blobs nvidia-340xx is no good with the VDPAU backend wrapper.

vdpau_video: VdpOutputSurfaceCreate(): status 25: A catch-all error, used when no other error code applies.
[1922:1922:1017/162505.171168:ERROR:vaapi_wrapper.cc(1591)] Failed putting surface to pixmap VA error: operation failed
[1:14:1017/162505.172041:ERROR:render_media_log.cc(27)] MediaEvent: MEDIA_ERROR_LOG_ENTRY {"error":"VDA Error 4"}

And MESA/Nouveau native VA-API support is prone to total DE crash for the same class of NVIDIA GPUs that are stuck with 340xx. It is a dead end to force their customers to upgrade.
Good job, NVIDIA!

Last edited by liewkj (2019-10-17 23:54:58)

justkdng · 2019-10-18 03:17:25

@liewkj
I wanted to test my 750ti but since it is barely usable if I connect my screen directly to it, I had to setup PRIME offload, the good thing is that I can use the propietary driver instead of nouveau, thanks NVIDIA, but when trying to use chromium with the NVIDIA gpu I get a weird error.
https://download.nvidia.com/XFree86/Lin … fload.html

$ export __NV_PRIME_RENDER_OFFLOAD_PROVIDER=NVIDIA-G0
$ export __GLX_VENDOR_LIBRARY_NAME=nvidia
$ chromium
[3742:3742:1017/221425.297946:ERROR:child_process_security_policy_impl.cc(1438)] Invalid isolated origin:
[3768:3768:1017/221425.482493:ERROR:gl_surface_glx.cc(78)] XGetWindowAttributes failed for window 46137348.
[3768:3768:1017/221425.482565:ERROR:gl_surface_glx.cc(839)] Failed to get GLXConfig
[3768:3768:1017/221425.482578:ERROR:gpu_info_collector.cc(60)] gl::GLContext::CreateOffscreenGLSurface failed
[3768:3768:1017/221425.482583:ERROR:gpu_info_collector.cc(199)] Could not create surface for info collection.
[3768:3768:1017/221425.482592:ERROR:gpu_init.cc(66)] gpu::CollectGraphicsInfo failed.
[3768:3768:1017/221425.484609:ERROR:viz_main_impl.cc(167)] Exiting GPU process due to errors during initialization
[3941:3941:1017/221425.642227:ERROR:gpu_channel_manager.cc(397)] ContextResult::kFatalFailure: Failed to create shared context for virtualization.

Basically hardware acceleration also doesn't work with the new PRIME offload as well, including mpv, dunno why.
Edit: Acceleration does work with mpv but only under vulkan, opengl is broken.

Last edited by justkdng (2019-10-18 06:20:37)

V1del · 2019-10-18 08:39:46

chromium actively filters the environment for a very select few variables it considers "safe" so this isn't really surprising

maximbaz · 2019-10-23 13:42:53

Seems like there's a new decoder in Chromium 78, I see Dav1dVideoDecoder instead of MojoVideoDecoder when playing a youtube video, please post here if you experience any issues.

yabk · 2019-10-23 13:57:25

@maximbaz I just tried the lastest 78 build from your repository; everything is still the same for me.
It is using MojoVideoDecoder and it's still laggy.

Last edited by yabk (2019-10-23 13:57:39)

Arch Linux

#201 2019-10-15 10:43:43

Re: chromium: hardware video acceleration with VA-API

#202 2019-10-15 11:14:11

Re: chromium: hardware video acceleration with VA-API

#203 2019-10-15 13:51:56

Re: chromium: hardware video acceleration with VA-API

#204 2019-10-15 14:04:55

Re: chromium: hardware video acceleration with VA-API

#205 2019-10-15 14:14:24

Re: chromium: hardware video acceleration with VA-API

#206 2019-10-15 14:17:40

Re: chromium: hardware video acceleration with VA-API

#207 2019-10-15 14:27:36

Re: chromium: hardware video acceleration with VA-API

#208 2019-10-15 18:15:17

Re: chromium: hardware video acceleration with VA-API

#209 2019-10-15 20:48:58

Re: chromium: hardware video acceleration with VA-API

#210 2019-10-15 21:00:11

Re: chromium: hardware video acceleration with VA-API

#211 2019-10-15 22:17:35

Re: chromium: hardware video acceleration with VA-API

#212 2019-10-15 22:20:07

Re: chromium: hardware video acceleration with VA-API

#213 2019-10-15 22:32:11

Re: chromium: hardware video acceleration with VA-API

#214 2019-10-15 23:04:54

Re: chromium: hardware video acceleration with VA-API

#215 2019-10-15 23:29:43

Re: chromium: hardware video acceleration with VA-API

#216 2019-10-16 09:43:58

Re: chromium: hardware video acceleration with VA-API

#217 2019-10-16 10:13:24

Re: chromium: hardware video acceleration with VA-API

#218 2019-10-16 12:32:14

Re: chromium: hardware video acceleration with VA-API

#219 2019-10-16 18:15:40

Re: chromium: hardware video acceleration with VA-API

#220 2019-10-17 20:34:38

Re: chromium: hardware video acceleration with VA-API

#221 2019-10-17 23:54:45

Re: chromium: hardware video acceleration with VA-API

#222 2019-10-18 03:17:25

Re: chromium: hardware video acceleration with VA-API

#223 2019-10-18 08:39:46

Re: chromium: hardware video acceleration with VA-API

#224 2019-10-23 13:42:53

Re: chromium: hardware video acceleration with VA-API

#225 2019-10-23 13:57:25

Re: chromium: hardware video acceleration with VA-API

Board footer