chromium: hardware video acceleration with VA-API

maximbaz · 2019-10-12 18:29:16

Yes, chromium-vaapi compiled against the current "vaapi-fix.patch" (i.e. as is currently in AUR) is perfectly able to play VP9 videos, using both drivers

UPDATE: And patch is for sure required to fix VP9 support.

Last edited by maximbaz (2019-10-12 18:31:46)

liewkj · 2019-10-12 18:42:00

maximbaz wrote:

Yes, chromium-vaapi compiled against the current "vaapi-fix.patch" (i.e. as is currently in AUR) is perfectly able to play VP9 videos, using both drivers
UPDATE: And patch is for sure required to fix VP9 support.

Thanks for the info. I think I may know the problem and would be able to work out a new non-intrusive patch. Perhaps, it has something to do with the change in VA-API behaviors when the code detected GeminiLake+ which includes KabyLake and onward.

The old patch is really bad, I am sorry to say that. It breaks VA drivers based on MESA and that makes open source looked really bad.

Last edited by liewkj (2019-10-12 18:46:53)

maximbaz · 2019-10-12 18:43:37

Cool! And just to make it clear, I'm very grateful for your help and I am super happy to include a better patch if it properly fixes the issues!

liewkj · 2019-10-12 19:06:42

Very strange... a few posts earlier said his WhiskeyLake did not work with old patch for VP9. And, that's also KabyLake+.
https://bbs.archlinux.org/viewtopic.php … 5#p1860515

Anyone has results for KabyLake R?
https://ark.intel.com/content/www/us/en … ake-r.html

maximbaz · 2019-10-12 19:34:53

That was under Wayland though, it could be a separate issue...

liewkj · 2019-10-12 20:11:41

@maximbaz
I strongly believe that this is the code that breaks VP9 on Intel GPU. When the condition is true, it also bypasses VPP.

In ./chromium-77.0.3865.120/media/gpu//vaapi/vaapi_video_decode_accelerator.cc:1095:

  // On Gemini Lake, Kaby Lake and later we can pass to libva the client's
  // PictureBuffers to decode onto, which skips the use of the Vpp unit and its
  // associated format reconciliation copy, avoiding all internal buffer
  // allocations.  This only works for VP8 and VP9: H264 GetNumReferenceFrames()
  // depends on the bitstream and sometimes it's not enough to cover the amount
  // of frames needed by the client pipeline (see b/133733739).
  // TODO(crbug.com/911754): Enable for VP9 Profile 2.
  if (IsGeminiLakeOrLater() &&
      (profile_ == VP9PROFILE_PROFILE0 || profile_ == VP8PROFILE_ANY)) {
    // Add one to the reference frames for the one being currently egressed, and
    // an extra allocation for both |client_| and |decoder_|, see
    // crrev.com/c/1576560.
    if (profile_ == VP8PROFILE_ANY)
      num_extra_pics_ = 3;
    return BufferAllocationMode::kNone;
  }

Would you be able to produce a build to check out my patch with the addition to disable this code block by changing the line below? This would make my simple patch remain non-intrusive and try out the code path used for H.264 (which proven works well) for VP9 and making use of VPP. Apparently, earlier report https://bbs.archlinux.org/viewtopic.php … 0#p1853040 said this works for Skylake with Intel hybrid driver in X11 session.

-if (IsGeminiLakeOrLater() &&
+if (false && IsGeminiLakeOrLater() &&

I would suggest that we test with only "--ignore-gpu-blacklist" and nothing else to begin with.

Last edited by liewkj (2019-10-12 21:57:07)

liewkj · 2019-10-12 20:25:53

@bsdice Sorry, I may have misread your post if you were using the existing build in AUR already published by maximbaz which has the old patch or one compiled with my simplified patch. You should try out build with my simplified patch as that is pristine for GeminiLake support if you were indeed having the old patch. If you wish to have fully working VA-API for GeminiLake (which I think it is important for the class of such CPU), please participate in this discussion and help us out as much as you can. Thanks!
This report said even a true GeminiLake failed to work. So it is very suspicious that the code block has ever been verified even for native ChromeOS, or if the code was remnant of buggy VPP support in the nearly libva 2.0.0 branch.
https://bbs.archlinux.org/viewtopic.php … 3#p1868013

bsdice wrote:

Pentium N5000 aka Geminilake UHD 605 user here.

@bsdice Are you still using the same system and be able to help to provide test results?

Last edited by liewkj (2019-10-12 22:17:10)

liewkj · 2019-10-12 21:03:49

@maximbaz Another option is to force IsGeminiLakeOrLater() use the same VDPAU code path for NVIDIA blobs and only for VP9, if the 1st proposed fix also failed.

if (IsGeminiLakeOrLater() &&
      (profile_ == VP9PROFILE_PROFILE0 || profile_ == VP8PROFILE_ANY)) {
......
- return BufferAllocationMode::kNone;
+ return BufferAllocationMode::kWrapVdpau;
}

In fact, this addition to my simple patch makes it somewhat similar behavior with the old patch but it feels strange that Intel screwed up on their own VA-API specification that VPP was provided for nothing, especially when this was for the shining new VP9 video decoder HW block.

Last edited by liewkj (2019-10-12 23:05:47)

maximbaz · 2019-10-12 22:19:35

The first build succeeded (with the patch below), and I confirm VP9 is playing as expected on both drivers! Do you still want me to run the test against the patch you shared last?

-if (IsGeminiLakeOrLater() &&
+if (false && IsGeminiLakeOrLater() &&

UPDATE: just in case I've scheduled the build now with your alternative patch; will go to sleep now, and will report the results tomorrow

Last edited by maximbaz (2019-10-12 22:35:36)

justkdng · 2019-10-12 23:23:43

liewkj wrote:

@maximbaz @justkdng
Thanks for the feedback. Did you guys check out Intel GPU on Wayland or X11 session? How about H.264 video playback? This is an extremely important detail for looking into VA-API.
libva-intel-driver works for me for Sandybridge and Haswell generations of HD Graphics for H.264 video playback on X11 session. My patch has been working very well for all MESA based VA drivers (r600, nouveau, radeonsi). VP9 works on my Ryzen 2500U.
I will see if I can get my hands on Skylake generation HD Graphics to check it out.

I tested it under X11, and yes, h.264 works as expected. VP9 just won't play.

liewkj wrote:

Are we sure that the old patch worked out well for Intel GPU? Someone had already reported earlier that it didn't on his Intel GPU, even for H.264, and I think he is using Skylake generation.

It worked for my i5 7200U when the error was first introduced, I even thanked @akarshanbiswas for his original patch. https://github.com/intel/intel-vaapi-dr … -513035936 and then proceeded to add the patch to my ungoogled-chromium repo. Will test out the addition you made to the patch, hopefully it works the same for ungoogled chromium,

Oh, and thanks for all the support @liewkj

liewkj · 2019-10-12 23:24:31

maximbaz wrote:

The first build succeeded (with the patch below), and I confirm VP9 is playing as expected on both drivers!

Awesome, it is good to know that VPP code path works for both H.264 and VP9 on KabyLake+.
Did you check out with pause/resume/fast-forward and video position drag? This will stress out the buffer management and sometimes they failed, but normal playback from start til end is fine.
How about Wayland? I was under the impression that iHD driver should supports DRI3/Present.
https://www.intel.com/content/dam/www/p … sset=14129
All MESA based VA drivers (r600, nouveau, radeonsi) support both X11 and Wayland.

maximbaz wrote:

Do you still want me to run the test against the patch you shared last?

The 2nd proposed patch is less ideal because it does not seem to be in-lined with VA-API specification, so No.

Can you share the build? I was hoping to see if @bsdice can check with his true GeminiLake. If the build failed for him, then we still need to keep the code block for that CPU and only that.

In ./chromium-77.0.3865.120/media/gpu//vaapi/vaapi_video_decode_accelerator.cc:69

// Returns true if the CPU is an Intel Gemini Lake or later (including Kaby
// Lake) Cpu platform id's are referenced from the following file in kernel
// source arch/x86/include/asm/intel-family.h
bool IsGeminiLakeOrLater() {
  constexpr int kPentiumAndLaterFamily = 0x06;
  constexpr int kGeminiLakeModelId = 0x7A;
  static base::CPU cpuid;
  static bool is_geminilake_or_later =
      cpuid.family() == kPentiumAndLaterFamily &&
-      cpuid.model() >= kGeminiLakeModelId;
+      cpuid.model() == kGeminiLakeModelId;
  return is_geminilake_or_later;
}

Last edited by liewkj (2019-10-13 05:40:39)

liewkj · 2019-10-13 02:00:18

justkdng wrote:

Edit: It works on my 3400G, haven't tested with nvidia.

Works fine for nvidia-390xx and nouveau on my GK208B on fully updated upstream ArchLinux. Only H.264 supported by hardware though.

01:00.0 VGA compatible controller: NVIDIA Corporation GK208B [GeForce GT 730] (rev a1)
linux 5.3.5.arch1-1
mesa 19.2.1-1

justkdng · 2019-10-13 04:33:01

Ok, finally finished compiling and for some reason the binary increased it size by 0.37 mb. But hey, at least it works in my 7200U now. I'd like to get some testing if possible before I release it. https://repo.vin.ovh/arch/x86_64/ungoog … pkg.tar.xz

liewkj wrote:

Works fine for nvidia-390xx and nouveau on my GK208B on fully updated upstream ArchLinux. Only H.264 supported by hardware though.

I have a 750ti but it is buggy af and is only stable under windows, so can't really test nvidia on my end. Oh, and the new patch works on my 3400G

justkdng · 2019-10-13 04:37:39

@maximbaz
not really related to the topic but everytime I see pkgbuild.com I'm reminded that I don't have the privilege of having access to a xeon server exclusive for compiling.
sad

maximbaz · 2019-10-13 07:56:28

liewkj wrote:

Did you check out with pause/resume/fast-forward and video position drag? This will stress out the buffer management and sometimes they failed, but normal playback from start til end is fine.

I remember this was an issue in the past; but with your patch `false &&` everything works well for me.

liewkj wrote:

How about Wayland? I was under the impression that iHD driver should supports DRI3/Present.
https://www.intel.com/content/dam/www/p … sset=14129
All MESA based VA drivers (r600, nouveau, radeonsi) support both X11 and Wayland.

I didn't manage to get HW acceleration enabled under Wayland, but maybe I don't know something (maybe chromium needs to be compiled in a special way?). Arch Wiki also mentions that Wayland support is currently broken in iHD driver and links to this issue: https://github.com/intel/libva/issues/79

liewkj wrote:

Can you share the build? I was hoping to see if @bsdice can check with his true GeminiLake. If the build failed for him, then we still need to keep the code block for that CPU and only that.

Here it is: https://pkgbuild.com/~maximbaz/repo/chr … pkg.tar.xz

justkdng wrote:

not really related to the topic but everytime I see pkgbuild.com I'm reminded that I don't have the privilege of having access to a xeon server exclusive for compiling.

Hahaha yes sorry about that!

CarbonChauvinist · 2019-10-13 14:35:07

Thanks to everyone involved for the movement on this.

Using the build @maximbaz shared I'm able to get HW acceleration working again under Plasma Wayland session using the intel-media iHD driver on a Skylake i5-6440HQ with HD Graphics 530 [8086:191b] (rev 06) igp. I still have to use the --use-gl=egl flag though, otherwise it won't work. (I don't know the implications of using egl flag -- is this counterproductive?) Anyway, here's what I pass:

--enable-gpu-rasterization
--ignore-gpu-blacklist
--disable-gpu-driver-workarounds
--use-gl=egl

I have to use the h264ify extension as well as I don't have a VP9 decode on my card so can't confirm anything related to that. Here's my vainfo if useful:

vainfo
vainfo: VA-API version: 1.5 (libva 2.5.0)
vainfo: Driver version: Intel iHD driver - 1.0.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
      VAProfileHEVCMain               : VAEntrypointVLD
      VAProfileHEVCMain               : VAEntrypointEncSlice
      VAProfileHEVCMain               : VAEntrypointFEI

maximbaz · 2019-10-13 15:11:01

Interesting, I've just tried to launch "chromium --use-gl=egl --ignore-gpu-blacklist", and I was able to get "MojoVideoDecoder" on a VP9 youtube video; although the performance was quite terrible (video is lagging), but it could be just on my box, I don't use sway so maybe I didn't configure it properly.

liewkj · 2019-10-13 18:13:51

CarbonChauvinist wrote:

Using the build @maximbaz shared I'm able to get HW acceleration working again under Plasma Wayland session using the Intel-Media iHD driver on a Skylake i5-6440HQ with HD Graphics 530 [8086:191b] (rev 06) igp. I still have to use the --use-gl=egl flag though, otherwise it won't work.

@CarbonChauvinist Hey, thanks for your feedback. That matches my expectaion well. I seem to vaguely recall past readings that Intel VA-API on Wayland works with EGL interop. So the Chromium additional code path of vaGetDisplayDRM() using the DRM backend (for "--use-gl=egl") was somehow tailored for them. But that only works for Intel iHD driver as the old i965 driver DRM render node implementation is render-less.

CarbonChauvinist wrote:

I have to use the h264ify extension as well as I don't have a VP9 decode on my card so can't confirm anything related to that. Here's my vainfo if useful:

You could use Intel-Hybrid driver to get VP9_profile0, but that driver is based on i965, and you will lose support for Wayland.

Apparently, MESA VA drivers work best regardless of GLX or DRM backends, if not because of the earlier faulty patch. That truly demonstrates the collaborative advantage of true open source software development.

Perhaps extra/chromium would reconsider the new patch and "use_vaapi=true" for future version to spearhead the right future for Linux video acceleration in browsers. I think they made the 1st shot too early when Chromium VA-API wasn't quite mature yet and patch was ugly. Now, the new patch is simple and non-intrusive, keeps the Chromium code base almost as pristine as upstream (if we keep the questionable code block only for GeminiLake CPU) and best it works universally across open-sourced MESA VA drivers, Intel and NVIDIA blobs. However, I must say though that the fact NVIDIA blobs still work is by *pure luck*. If there was any major revamp in VA-API specification, things could just break for them. That's the sad story of being dependent on wrappers.

Last edited by liewkj (2019-10-13 21:44:36)

digitalone · 2019-10-14 07:39:18

justkdng wrote:

Ok, finally finished compiling and for some reason the binary increased it size by 0.37 mb. But hey, at least it works in my 7200U now. I'd like to get some testing if possible before I release it. https://repo.vin.ovh/arch/x86_64/ungoog … pkg.tar.xz

Is this build specific for your system? I get a core dump executing it on mine.

Anyway, since a couple of months chromium playback through vaapi is not optimal on my system with an ATI card (tried both radeon and amdgpu drivers). I get lag issues on 1080p60 h264 videos, tested on Youtube (h264fied) and Twitch. That was not occurring before, everything played fine till June, but then it started to lag only on 1080p60 videos, no issue on other formats. Maybe it was a change in mesa package.

To be honest, I'm not interested anymore since I'm using minitube and orion which works best with mpv backend, but if the new patch resolves the issue inside Chromium, it's very appreciated. Thanks.

justkdng · 2019-10-14 12:23:46

digitalone wrote:

Is this build specific for your system?

Nope, it should be for everyone. And the new url is this btw: https://repo.vin.ovh/arch/x86_64/ungoog … pkg.tar.xz
If vaapi doesn't work you could try to use vdpau instead.

bsdice · 2019-10-14 15:14:08

Sorry to keep you waiting, life... I compiled this https://github.com/jstkdng/ungoogled-ch … b91088157a

and installed it on the laptop Acer Swift 1, SF114-32, 8 GB RAM, Intel Pentium Silver N5000 CPU @ 1.10GHz aka Gemini Lake aka Goldmont Plus aka the CPU which has the evil Chromium crash bug Google and Intel haven't found yet (https://bugs.chromium.org/p/chromium/is … ?id=968683)

Using X11 pretty much with defaults i.e. using KMS, i3 WM, compton, libva-intel-driver 2.3.0, dri2+3 enabled

i915.fastboot=1, intel_iommu=on
kernel.unprivileged_userns_clone=1
kernel.sched_autogroup_enabled=1

The only special setting in chromium is ignore-gpu-blacklist

1) VP9 acceleration works, Youtube 1080p full screen video makes the GPU draw around 3.2 watts according to intel_gpu_top
2) H264 acceleration works, same video, 1.5 to 3 watts oscillating

No frame drops.

CPU usage with sound is ~55% while CPU frequency is not going over 1200 MHz (it can use turbo up to 2700 MHz)
So playing 1080p fullscreen on a full HD panel will eat half a Goldmont Plus core at base clock.

For me ungoogled-chromium 77.0.3865.120-2 is a keeper.

Last edited by bsdice (2019-10-14 15:15:39)

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

@liewkj, given the confirmation from @bsdice, what's the latest and cleanest patch you would recommend me to put in chromium-vaapi?

liewkj · 2019-10-14 16:18:00

This one, of course in addition to the simplified, non-intrusive patch. And, thanks everyone!

-if (IsGeminiLakeOrLater() &&
+if (false && IsGeminiLakeOrLater() &&

Ungoogled-chromium already made the release.
https://raw.githubusercontent.com/jstkd … aapi.patch

maximbaz · 2019-10-14 16:19:30

Cool thanks for your help, will update chromium-vaapi now! By the way, have you considered proposing this patch to upstream? (or not this exactly, but removing the entire condition).

liewkj · 2019-10-14 17:02:43

maximbaz wrote:

have you considered proposing this patch to upstream? (or not this exactly, but removing the entire condition).

I can try, but I would love to see official extra/chromium endorsing VA-API build first hand to provide a stronger ground for argument . And, followed by other more conservative Linux distros such as Fedora and Ubuntu/Debian. Anyway, for what upstream has done, endorsing VA-API build does not enable VA-API by default.

The more I looked at that questionable code block, the more I think that it was a remnant of failed power optimization as Intel VA drivers & libva move on. I was trying to track the original intent of the code block, but I still missed the 1st part (see b/133733739). It sounds like the kNone code path, skipping the use of VPP, would reduce power consumption of video decoding as VPP introduces format reconciliation and buffer copy.

Are you guys interested in doing more experiments of power consumption by comparing the old and the new patch? If we have the data, then we can decide if the less ideal 2nd proposed patch would make sense for saving power at the expense of VA-API spec compliance. Personally, I prefer spec compliance over optimization in general, with the exception if the optimization really has a huge impact.

Arch Linux

#151 2019-10-12 18:29:16

Re: chromium: hardware video acceleration with VA-API

#152 2019-10-12 18:42:00

Re: chromium: hardware video acceleration with VA-API

#153 2019-10-12 18:43:37

Re: chromium: hardware video acceleration with VA-API

#154 2019-10-12 19:06:42

Re: chromium: hardware video acceleration with VA-API

#155 2019-10-12 19:34:53

Re: chromium: hardware video acceleration with VA-API

#156 2019-10-12 20:11:41

Re: chromium: hardware video acceleration with VA-API

#157 2019-10-12 20:25:53

Re: chromium: hardware video acceleration with VA-API

#158 2019-10-12 21:03:49

Re: chromium: hardware video acceleration with VA-API

#159 2019-10-12 22:19:35

Re: chromium: hardware video acceleration with VA-API

#160 2019-10-12 23:23:43

Re: chromium: hardware video acceleration with VA-API

#161 2019-10-12 23:24:31

Re: chromium: hardware video acceleration with VA-API

#162 2019-10-13 02:00:18

Re: chromium: hardware video acceleration with VA-API

#163 2019-10-13 04:33:01

Re: chromium: hardware video acceleration with VA-API

#164 2019-10-13 04:37:39

Re: chromium: hardware video acceleration with VA-API

#165 2019-10-13 07:56:28

Re: chromium: hardware video acceleration with VA-API

#166 2019-10-13 14:35:07

Re: chromium: hardware video acceleration with VA-API

#167 2019-10-13 15:11:01

Re: chromium: hardware video acceleration with VA-API

#168 2019-10-13 18:13:51

Re: chromium: hardware video acceleration with VA-API

#169 2019-10-14 07:39:18

Re: chromium: hardware video acceleration with VA-API

#170 2019-10-14 12:23:46

Re: chromium: hardware video acceleration with VA-API

#171 2019-10-14 15:14:08

Re: chromium: hardware video acceleration with VA-API

#172 2019-10-14 15:55:55

Re: chromium: hardware video acceleration with VA-API

#173 2019-10-14 16:18:00

Re: chromium: hardware video acceleration with VA-API

#174 2019-10-14 16:19:30

Re: chromium: hardware video acceleration with VA-API

#175 2019-10-14 17:02:43

Re: chromium: hardware video acceleration with VA-API

Board footer