chromium: hardware video acceleration with VA-API

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

bsdice wrote:

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
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.

Was the build with old patch working for you previously?
Or, was the last build from Justkdng with the original simplified patch working for you? That one has the kNone code path for GeminiLake+, presumably more power efficient if it works.

Can you do a before-and-after comparison with intel_gpu_top? Why would you not using the more advanced iHD driver?

bsdice · 2019-10-14 18:34:19

liewkj wrote:

Was the build with old patch working for you previously?
Or, was the last build from Justkdng with the original simplified patch working for you? That one has the kNone code path for GeminiLake+, presumably more power efficient if it works.
Can you do a before-and-after comparison with intel_gpu_top? Why would you not using the more advanced iHD driver?

All "releases" by justkdng have been working for me for at least 6 months. That's why I switched, stuff compiles and works.
From my repo some recent builds that are working good for me on Gemini Lake:

Sep 1 02:46 ungoogled-chromium-76.0.3809.132-1-x86_64.pkg.tar.xz
Sep 14 04:12 ungoogled-chromium-77.0.3865.75-1-x86_64.pkg.tar.xz
Sep 22 02:24 ungoogled-chromium-77.0.3865.90-1-x86_64.pkg.tar.xz
Oct 14 16:23 ungoogled-chromium-77.0.3865.120-2-x86_64.pkg.tar.xz

Unfortunately I can't do a comparison, not enough time right now.

I briefly tried iHD the other day with 77.0.3865.90-1 and video decoding crashed after a few seconds. I switched from intel-media-driver 19.2.1-2 back to libva-intel-driver 2.3.0-2 right away.

maximbaz · 2019-10-14 18:36:24

liewkj wrote:

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.

I would also like that, as you might have seen from the first posts in this thread But there are some issues with that, including me not having access to [extra] and thus not being able to help maintaining this.

But since it's a bug, I think you have good argument for this issue being fixed in upstream anyway, regardless of how many people actually use VA-API.

liewkj wrote:

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.

I'm happy to provide some test builds and run some experiments as well if this can fuel further improvement in the area! I guess this is really up to you, do you want to try this out or you already know you would prefer to keep the spec compliance.

If we will run tests, can you confirm which two patches are we comparing (`false && ` vs `return BufferAllocationMode::kWrapVdpau` ?) and how to measure the power difference?

liewkj · 2019-10-14 18:52:04

digitalone wrote:

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).

That was because it was never done correctly to begin with. Unlike Intel and NVIDIA, AMD/ATI are completely dependent on MESA VA drivers. In fact, that it even worked for you in the past was somehow unbelievable. Since you mentioned "amdgpu", your AMD/ATI hardware must be recent and at least supported by MESA radeonsi VA driver, if not, r600. I have tested both on my AMD C-60 (r600) and Ryzen APU (radeonsi) and they works flawlessly.

digitalone wrote:

To be honest, I'm not interested anymore since I'm using minitube and orion which works best with mpv backend

This is exactly the reason I would like to see the faulty old patch gone to have hope for video acceleration in Linux browsers. Otherwise, more would have given up and users from Windows camp would simply laughing out loud with unnecessary tricks like this. The MESA folks were frustrated as they see nothing wrong from their ends and then the war of blame game just going on without anything being accomplished.

liewkj · 2019-10-14 19:14:09

maximbaz wrote:

If we will run tests, can you confirm which two patches are we comparing (`false && ` vs `return BufferAllocationMode::kWrapVdpau` ?) and how to measure the power difference?

Yes, comparing these 2 patches is good. Or, just compare your existing old patch build and the new one, if the later hasn't been available. If you want to go ahead and build one, it is fine, too, to prove that it also works since that is what we will consider if the power numbers turn out to be significant.

I was hoping intel_gpu_top will show the power usage as what @bsdice had reported during the playback of video clips. I believe he used intel_gpu_top.

digitalone · 2019-10-14 20:11:41

justkdng wrote:

Nope, it should be for everyone. And the new url is this btw: https://repo.vin.ovh/arch/x86_64/ungoog … pkg.tar.xz

This is exactly what I installed since the previous one was unavailable.

justkdng wrote:

If vaapi doesn't work you could try to use vdpau instead.

How?

Anyway, waiting for chromium-vaapi-bin to be update and I'll test on my system.

Last edited by digitalone (2019-10-14 20:15:35)

liewkj · 2019-10-14 20:24:56

digitalone wrote:

Anyway, waiting for chromium-vaapi-bin to be update and I'll test on my system.

You don't have to wait. Maximbaz has shared out his build in earlier post. And, no, don't use VDPAU!

Last edited by liewkj (2019-10-14 20:25:57)

digitalone · 2019-10-14 20:32:56

liewkj wrote:

digitalone wrote:
Anyway, waiting for chromium-vaapi-bin to be update and I'll test on my system.
You don't have to wait. Maximbaz has shared out his build in earlier post. And, no, don't use VDPAU!

I'm already using latest build on his repository (77.0.3865.120-3) and the issue is not gone.

liewkj · 2019-10-14 20:41:34

digitalone wrote:

'm already using latest build on his repository (77.0.3865.120-3) and the issue is not gone.

Your vainfo report, please.

justkdng · 2019-10-14 21:00:16

maximbaz wrote:

By the way, have you considered proposing this patch to upstream?

I think if a Trusted User™ proposed it, it could have more posibilities of being accepted. Also, comment related: https://www.reddit.com/r/archlinux/comm … d/f3o3w0a/

liewkj wrote:

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.

Too lazy to compile chromium again with the old patch tbh.

digitalone · 2019-10-14 21:13:44

liewkj wrote:

digitalone wrote:
'm already using latest build on his repository (77.0.3865.120-3) and the issue is not gone.
Your vainfo report, please.

vainfo: VA-API version: 1.5 (libva 2.5.0)
vainfo: Driver version: Mesa Gallium driver 19.2.1 for AMD KABINI (DRM 2.50.0, 5.2.15-lqx1-1-lqx, LLVM 9.0.0)
vainfo: Supported profile and entrypoints
      VAProfileMPEG2Simple            : VAEntrypointVLD
      VAProfileMPEG2Main              : VAEntrypointVLD
      VAProfileVC1Simple              : VAEntrypointVLD
      VAProfileVC1Main                : VAEntrypointVLD
      VAProfileVC1Advanced            : VAEntrypointVLD
      VAProfileH264ConstrainedBaseline: VAEntrypointVLD
      VAProfileH264ConstrainedBaseline: VAEntrypointEncSlice
      VAProfileH264Main               : VAEntrypointVLD
      VAProfileH264Main               : VAEntrypointEncSlice
      VAProfileH264High               : VAEntrypointVLD
      VAProfileH264High               : VAEntrypointEncSlice
      VAProfileNone                   : VAEntrypointVideoProc

justkdng · 2019-10-14 21:35:49

lmao, didn't notice there was a new page

digitalone wrote:

justkdng wrote:
Nope, it should be for everyone. And the new url is this btw: https://repo.vin.ovh/arch/x86_64/ungoog … pkg.tar.xz
This is exactly what I installed since the previous one was unavailable.
justkdng wrote:
If vaapi doesn't work you could try to use vdpau instead.
How?
Anyway, waiting for chromium-vaapi-bin to be update and I'll test on my system.

Use libva-vdpau-driver and mesa-vdpau. I had to do that with my 750ti using propietary drivers before it broke.
Edit: libva-vdpau-driver-chromium shouldn't be necessary for your amd gpu.

Last edited by justkdng (2019-10-14 21:40:03)

liewkj · 2019-10-14 22:03:57

@digitalone Your vainfo is good and you should get proper video acceleration with Chromium package shared by Maximbaz, and you should observe a reduction in CPU utilization during video playback. The CPU is KABINI, so that is an inherently weak CPU. If the 1080p60 lagging was due to peak CPU utilization, then you may have an issue with video acceleration. Otherwise, it is something else and unrelated to this thread discussion. I don't want to go into lengthy discussion of scrutinizing your Chromium flags and chrome://gpu. I trust that you know what is required.

justkdng wrote:

Use libva-vdpau-driver and mesa-vdpau. I had to do that with my 750ti using propietary drivers before it broke.

This is wrong information. NVIDIA blobs VDPAU do not require mesa-vdpau at all. Never ever suggest the usage of wrappers (libva-vdpau-driver, libva-vdpau-driver-chromium, libvdpau-va-gl) for systems that support perfectly native drivers.

Last edited by liewkj (2019-10-14 22:05:09)

justkdng · 2019-10-14 22:17:49

liewkj wrote:

This is wrong information.

Yeah, my bad, I meant "that" as in using vdpau with my 750ti and not as in installing mesa-vdpau.
mesa-vdpau and libva-vdpau-driver should be the only ones required.

liewkj wrote:

Never ever suggest the usage of wrappers

Hey, it IS a solution, not the best one I can accept, but it is still one.

liewkj wrote:

If the 1080p60 lagging was due to peak CPU utilization

@digitalone said mpv works for him, so I doubt it is because of his weak cpu.
Edit: mpv uses ffmpeg/libplacebo and chromium uses libvpx, that could also be related.
Edit2: Actually, nevermind my comment

Last edited by justkdng (2019-10-14 22:26:30)

digitalone · 2019-10-14 22:25:02

liewkj wrote:

@digitalone Your vainfo is good and you should get proper video acceleration with Chromium package shared by Maximbaz, and you should observe a reduction in CPU utilization during video playback. The CPU is KABINI, so that is an inherently weak CPU. If the 1080p60 lagging was due to peak CPU utilization, then you may have an issue with video acceleration. Otherwise, it is something else and unrelated to this thread discussion. I don't want to go into lengthy discussion of scrutinizing your Chromium flags and chrome://gpu. I trust that you know what is required.

I used chomium-vaapi from august 2017 and everything worked fine, every format from 360p to h264 1080p60. From the last July I get lagging on 1080p60 and this is very annoying, so I moved to minitube and Orion. I know my cpu is shit, but it worked and it's working through mpv backend. And 1080p60 plays smoothly also through mpv using cpu only. Browsers are the real problem.

liewkj wrote:

This is wrong information. NVIDIA blobs VDPAU do not require mesa-vdpau at all. Never ever suggest the usage of wrappers (libva-vdpau-driver, libva-vdpau-driver-chromium, libvdpau-va-gl) for systems that support perfectly native drivers.

mesa-vdpau is required for me because I tested without it and hardware acceleration was not working. It seems vaapi is not supported natively on my card, but I can get it working thanks to the translation layer. Maybe minitube is using vdpau directly, but kodi and orion supports only vaapi and I can get hardware acceleration as well without issues.

Last edited by digitalone (2019-10-14 22:26:59)

justkdng · 2019-10-14 22:29:13

digitalone wrote:

mesa-vdpau is required for me because I tested without it and hardware acceleration was not working. It seems it's not supported natively on my card, but I can get it working thanks to the translation layer. Maybe minitube is using vdpau directly, but kodi and orion supports only vaapi and I can get hardware acceleration as well without issues.

minitube uses mpv afaik, and mpv supports vaapi and vdpau acceleration, you have to configure it first. Maybe it is just using what it is finding. To have mpv use vaapi you have to edit your mpv.conf with this:

# Hardare Acceleration
vo=gpu
gpu-context=x11egl
gpu-api=opengl
# gpu-api=vulkan
# gpu-hwdec-interop=vaapi-egl
hwdec=vaapi

# Image Quality
profile=gpu-hq
video-sync=display-resample
interpolation=yes

ytdl-format="bestvideo[height<=?1080]+bestaudio/best"

Edit: you should probably comment out the Image Quality part, that is really hard on your cpu.

Last edited by justkdng (2019-10-14 22:29:55)

digitalone · 2019-10-14 22:45:26

justkdng wrote:

minitube uses mpv afaik, and mpv supports vaapi and vdpau acceleration, you have to configure it first. Maybe it is just using what it is finding. To have mpv use vaapi you have to edit your mpv.conf with this:
# Hardare Acceleration
vo=gpu
gpu-context=x11egl
gpu-api=opengl
# gpu-api=vulkan
# gpu-hwdec-interop=vaapi-egl
hwdec=vaapi

# Image Quality
profile=gpu-hq
video-sync=display-resample
interpolation=yes

ytdl-format="bestvideo[height<=?1080]+bestaudio/best"
Edit: you should probably comment out the Image Quality part, that is really hard on your cpu.

I know. Tested in the past using both vaapi and vdpau through mpv, both were working without issues, but vaapi was giving some warnings on the command line.

Tried uninstalling vdpau, configured mpv to use vaapi (its not really needed, mpv should detect it by default and use it) and it was falling back on cpu decoding.

Last edited by digitalone (2019-10-14 22:45:48)

maximbaz · 2019-10-14 22:48:13

digitalone wrote:

liewkj wrote:
digitalone wrote:
Anyway, waiting for chromium-vaapi-bin to be update and I'll test on my system.
You don't have to wait. Maximbaz has shared out his build in earlier post. And, no, don't use VDPAU!
I'm already using latest build on his repository (77.0.3865.120-3) and the issue is not gone.

Could you please retry this build below? It's compiled from AUR/chromium-vaapi, while -3 was one of the test ones I built for this thread, I've never added to the actual repo file, I don't even recall which patch it was compiled against... (I've cleaned up pkgbuild.com of these test builds now).

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

liewkj · 2019-10-14 22:54:33

digitalone wrote:

mesa-vdpau is required for me because I tested without it and hardware acceleration was not working. It seems vaapi is not supported natively on my card, but I can get it working thanks to the translation layer. Maybe minitube is using vdpau directly, but kodi and orion supports only vaapi and I can get hardware acceleration as well without issues.

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. ATI/AMD are also dependent on MESA for VDPAU drivers. If you have other video application configured to use VDPAU, then you need that library. There is no translation layer ever between VA-API and VDPAU in MESA context. You could have configured the video application to use VA-API and you absolutely *DO NOT* require mesa-vdpau for VA-API to work.

Comparing mpv and chromium is a moot point, mpv is always leaner than any fat, memory hogging browsers. So long as we have a Linux browser that can support hardware video acceleration, whether it is good enough, I do not have a say.

maximbaz · 2019-10-14 23:16:05

@liewkj as far as I could see, energy consumption is exactly same in the current vs the old patch, was testing in chromium with a single tab open playing local videos in almost full screen. So I guess if you want to propose this patch upstream, feel free to clean that code section up and do it

digitalone · 2019-10-15 08:06:29

Good morning everyone.

I tested today installing the new chromium-vaapi-bin that shipped the last build from maximbaz repository.
Using the usual flags, the issue was still there. Then I wanted to try to switch some of them.
"use-gl" was not declared and I set it to desktop, which it was the default value I was previously using.
Nothing changed, even disabling "disable-gpu-driver-bug-workarounds".
Therefore I reenabled "disable-gpu-driver-bug-workarounds" and set "use-gl" to egl.

Well, surprisingly IT'S WORKING with all formats, even 1080p60 without lagging. 25-35% CPU usage and 0 frame drop on Youtube and Twitch (h264ify extension used).
Before you say I was using a bad configuration, I want to clarify that a couple of months ago when the issue came out I tried all combinations of flags and "use-gl=egl" was disabling the hardware decoding giving no lagging, but 80-90% of cpu usage resulting in some frame drops.

Don't know what happened this time, but it seems that now "use-gl=egl" is required to get optimal hardware acceleration on AMD vga, at least on my system. I'm using radeon driver, I think it's the same on amdgpu.

Finally I want to say BIG, BIG THANKS TO YOU ALL, especially liewkj and maximbaz.

This is my ~/.config/chromium-flags.conf

--use-gl=egl
--ignore-gpu-blacklist
--disable-gpu-driver-bug-workarounds
--enable-gpu-rasterization
--force-gpu-rasterization
--enable-native-gpu-memory-buffers
--enable-oop-rasterization
--enable-zero-copy

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. ATI/AMD are also dependent on MESA for VDPAU drivers. If you have other video application configured to use VDPAU, then you need that library. There is no translation layer ever between VA-API and VDPAU in MESA context. You could have configured the video application to use VA-API and you absolutely *DO NOT* require mesa-vdpau for VA-API to work.

As I previously said, I tested in the past using vaapi after uninstalling vdpau and I get issues. I will retest now.

akarshanbiswas · 2019-10-15 08:16:25

@maximbaz Wow, a lot more conversation happened the last time I visited.

   // of frames needed by the client pipeline (see b/133733739).
   // TODO(crbug.com/911754): Enable for VP9 Profile 2.
-  if (IsGeminiLakeOrLater() &&
+  if (false && 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

What kind of black magic is this?

maximbaz · 2019-10-15 08:36:50

akarshanbiswas wrote:

@maximbaz Wow, a lot more conversation happened the last time I visited.

   // of frames needed by the client pipeline (see b/133733739).
   // TODO(crbug.com/911754): Enable for VP9 Profile 2.
-  if (IsGeminiLakeOrLater() &&
+  if (false && 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

What kind of black magic is this?

@liewkj can explain a lot better, TL;DR as far as I understand is that the entire code block is causing troubles, it is not clear why it was added and better be removed entirely in upstream; however to have a simple patch in the meantime we just disable it using this logic

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

maximbaz wrote:

akarshanbiswas wrote:
@maximbaz Wow, a lot more conversation happened the last time I visited.
   // of frames needed by the client pipeline (see b/133733739).
   // TODO(crbug.com/911754): Enable for VP9 Profile 2.
-  if (IsGeminiLakeOrLater() &&
+  if (false && 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
What kind of black magic is this?
@liewkj can explain a lot better, TL;DR as far as I understand is that the entire code block is causing troubles, it is not clear why it was added and better be removed entirely in upstream; however to have a simple patch in the meantime we just disable it using this logic

I know, that's why I did put the entire block to chromeos only.

maximbaz · 2019-10-15 09:36:03

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

Arch Linux

#176 2019-10-14 18:16:34

Re: chromium: hardware video acceleration with VA-API

#177 2019-10-14 18:34:19

Re: chromium: hardware video acceleration with VA-API

#178 2019-10-14 18:36:24

Re: chromium: hardware video acceleration with VA-API

#179 2019-10-14 18:52:04

Re: chromium: hardware video acceleration with VA-API

#180 2019-10-14 19:14:09

Re: chromium: hardware video acceleration with VA-API

#181 2019-10-14 20:11:41

Re: chromium: hardware video acceleration with VA-API

#182 2019-10-14 20:24:56

Re: chromium: hardware video acceleration with VA-API

#183 2019-10-14 20:32:56

Re: chromium: hardware video acceleration with VA-API

#184 2019-10-14 20:41:34

Re: chromium: hardware video acceleration with VA-API

#185 2019-10-14 21:00:16

Re: chromium: hardware video acceleration with VA-API

#186 2019-10-14 21:13:44

Re: chromium: hardware video acceleration with VA-API

#187 2019-10-14 21:35:49

Re: chromium: hardware video acceleration with VA-API

#188 2019-10-14 22:03:57

Re: chromium: hardware video acceleration with VA-API

#189 2019-10-14 22:17:49

Re: chromium: hardware video acceleration with VA-API

#190 2019-10-14 22:25:02

Re: chromium: hardware video acceleration with VA-API

#191 2019-10-14 22:29:13

Re: chromium: hardware video acceleration with VA-API

#192 2019-10-14 22:45:26

Re: chromium: hardware video acceleration with VA-API

#193 2019-10-14 22:48:13

Re: chromium: hardware video acceleration with VA-API

#194 2019-10-14 22:54:33

Re: chromium: hardware video acceleration with VA-API

#195 2019-10-14 23:16:05

Re: chromium: hardware video acceleration with VA-API

#196 2019-10-15 08:06:29

Re: chromium: hardware video acceleration with VA-API

#197 2019-10-15 08:16:25

Re: chromium: hardware video acceleration with VA-API

#198 2019-10-15 08:36:50

Re: chromium: hardware video acceleration with VA-API

#199 2019-10-15 09:15:43

Re: chromium: hardware video acceleration with VA-API

#200 2019-10-15 09:36:03

Re: chromium: hardware video acceleration with VA-API

Board footer