search

FireBurn / Overlay

Gentoo Overly
GNU General Public License v3.0
21 stars 6 forks source link

Chromium not accelerating video, while it suggest so #68

Closed skinkie closed 4 years ago

skinkie commented 4 years ago

I noticed that Chromium (I have just merged 81.0.4044.113) is not doing any acceleration on (youtube) video content anymore. Using h264ify I notice that blocks 60fps video certainly brings me back to 30fps, and it also shows that it is playing avc1. I have vaapi enabled in the use flags, still Chromium goes well beyond 100% cpu when playing this video. Trying the same in mpv I get 50%-85% average cpuload.

image

[ebuild   R    ] www-client/chromium-81.0.4044.113::FireBurn  USE="closure-compile custom-cflags hangouts (pic) proprietary-codecs suid system-ffmpeg system-icu tcmalloc vaapi widevine -component-build -cups -kerberos -pulseaudio (-selinux) (-system-libvpx)" L10N="nl -am -ar -bg -bn -ca -cs -da -de -el -en-GB -es -es-419 -et -fa -fi -fil -fr -gu -he -hi -hr -hu -id -it -ja -kn -ko -lt -lv -ml -mr -ms -nb -pl -pt-BR -pt-PT -ro -ru -sk -sl -sr -sv -sw -ta -te -th -tr -uk -vi -zh-CN -zh-TW"

Graphics Feature Status Canvas: Hardware accelerated Flash: Hardware accelerated Flash Stage3D: Hardware accelerated Flash Stage3D Baseline profile: Hardware accelerated Compositing: Hardware accelerated Multiple Raster Threads: Enabled Out-of-process Rasterization: Disabled OpenGL: Enabled Hardware Protected Video Decode: Unavailable Rasterization: Software only. Hardware acceleration disabled Skia Renderer: Enabled Video Decode: Hardware accelerated Vulkan: Disabled WebGL: Hardware accelerated WebGL2: Hardware accelerated

image

After a reboot, the CPU time of a single Chromium process drops to ~80%, but magically a second process appears eating the same amount of time. Switching to a different tab (hence audio only) lowers the CPU time.

FireBurn commented 4 years ago

Hmm

Can you go to about:gpu in Chromium and paste the messages at the bottom

Can you also provide the output of vainfo

skinkie commented 4 years ago

Log Messages [86868:86868:0420/095506.316299:ERROR:sandbox_linux.cc(374)] : InitializeSandbox() called with multiple threads in process gpu-process. [86868:86868:0420/095819.795384:WARNING:x11_util.cc(1456)] : X error received: serial 20900, error_code 168 (GLXBadWindow), request_code 151, minor_code 32 (X_GLXDestroyWindow) [86868:86868:0420/095819.795582:WARNING:x11_util.cc(1456)] : X error received: serial 20906, error_code 3 (BadWindow (invalid Window parameter)), request_code 4, minor_code 0 (X_DestroyWindow) [86868:86868:0420/100017.959193:WARNING:gpu_video_decode_accelerator_factory.cc(248)] : Initializing VAAPI VDA. [86868:86868:0420/104438.349384:WARNING:gpu_video_decode_accelerator_factory.cc(248)] : Initializing VAAPI VDA.

FireBurn commented 4 years ago

And in case its not obvious from the output of vainfo, what graphics card do you have?

skinkie commented 4 years ago

And in case its not obvious from the output of vainfo, what graphics card do you have?

05:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Raven Ridge [Radeon Vega Series / Radeon Vega Mobile Series] (rev c4)

One change that I recently did was changing the embedded firmware to raven, while I invalidly(?) had:

CONFIG_EXTRA_FIRMWARE="amd-ucode/microcode_amd_fam17h.bin amd/amd_sev_fam17h_model0xh.sbin amdgpu/vega10_acg_smc.bin amdgpu/vega10_asd.bin amdgpu/vega10_ce.bin amdgpu/vega10_gpu_info.bin amdgpu/vega10_me.bin amdgpu/vega10_mec.bin amdgpu/vega10_mec2.bin amdgpu/vega10_pfp.bin amdgpu/vega10_rlc.bin amdgpu/vega10_sdma.bin amdgpu/vega10_sdma1.bin amdgpu/vega10_smc.bin amdgpu/vega10_sos.bin amdgpu/vega10_uvd.bin amdgpu/vega10_vce.bin"

to:

CONFIG_EXTRA_FIRMWARE="amd-ucode/microcode_amd_fam17h.bin amd/amd_sev_fam17h_model0xh.sbin amdgpu/raven_asd.bin amdgpu/raven_ce.bin amdgpu/raven_gpu_info.bin amdgpu/raven_me.bin amdgpu/raven_mec.bin amdgpu/raven_mec2.bin amdgpu/raven_pfp.bin amdgpu/raven_rlc.bin amdgpu/raven_sdma.bin amdgpu/raven_vcn.bin"

But maybe I have an error in this change, and failed to identify my graphicscards correctly.

https://www.amd.com/en/products/apu/amd-ryzen-5-2500u

FireBurn commented 4 years ago

If you have the amdgpu driver compiled in, you'd errors in your dmesg if you weren't using the correct firmware files

Wanna upload your dmesg?

I have a Raven 2400g here, it does VP9 natively so no need for h264ify

FireBurn commented 4 years ago

Also you haven't provided the output of vainfo yet

FireBurn commented 4 years ago

The image you attached above does state that Chromium is using the Mojo video decoder which suggests that everything is working

Do you see more CPU usage if you set video acceleration to off in about:flags?

skinkie commented 4 years ago

If you have the amdgpu driver compiled in, you'd errors in your dmesg if you weren't using the correct firmware files

I haven't seen any errors concerning my wrongly compiled firmware in. So in the current or the past situation I assume it was falling back by loading it dynamically. But what I find interesting is this part

[ 2.583632] [drm] add ip block number 2

I can obviously try ro revert back to the previously buildin configuration.

Wanna upload your dmesg?

dmesg.txt vainfo.txt

The image you attached above does state that Chromium is using the Mojo video decoder which suggests that everything is working

I completely agree that makes this so strange. Still the cpuload does not match this behavior.

I have a Raven 2400g here, it does VP9 natively so no need for h264ify

That is something interesting to try. 70-100% cpu without h264ify.

skinkie commented 4 years ago

Do you see more CPU usage if you set video acceleration to off in about:flags?

For VP9 slightly lower. 60% cpu. For AV1 300% (but I don't have a reference for that one with acceleration, as it was a commercial)

skinkie commented 4 years ago

This is dmesg with vega10 firmwares. I don't see any other loading happing, but the performance is also "unchanged". dmesg-vega10.txt

FireBurn commented 4 years ago

I'm pretty sure vega10 is raven. Your dmesg suggests that amdgpu is a module, so would always be able to read the firmware directly from /lib/firmware

I'd be more concerned about those PCIe Bus Errors

Your vainfo looks good

Your chip can do h264, hevc (h265) and vp9 which covers the majority of codes any website would be using

No desktop parts offer AV1 hardware decoding yet

If I were to hazard a guess, I'd say the hardware acceleration is working, the high CPU is coming from chromium coping the coded image back to the process requiring it

I think when Chromium switches to Aurora for its wayland support (and maybe X11 one day too) they'll be using dmabufs for zero copy

My Raven system is connected to a 4K TV, without acceleration I can't smoothly play 4k VP9 videos, they play just fine with vaapi acceleration enabled though chrome is quite sluggish when switching in and out of full screen mode

skinkie commented 4 years ago

I'm pretty sure vega10 is raven. Your dmesg suggests that amdgpu is a module, so would always be able to read the firmware directly from /lib/firmware

I'd be more concerned about those PCIe Bus Errors

I have seen those from the beginning of Linux on this Thinkpad E485. More recently since 5.6.5 I am not able to reboot (dark screen). But in general suspend has always been an issue.

My Raven system is connected to a 4K TV, without acceleration I can't smoothly play 4k VP9 videos, they play just fine with vaapi acceleration enabled though chrome is quite sluggish when switching in and out of full screen mode

Currently with the Vega 10 firmware reboot I am seeing when playing a windowed YouTube video 108% usage + 57% usage on AVC1. This has been working much better before.

FireBurn commented 4 years ago

Another way to check on an AMD system is to edit:

/usr/share/drirc.d/01-chromium.conf

And change allow_rgb10_configs to true, when playing videos you'll find they look pink & red

skinkie commented 4 years ago

@FireBurn I remember what that LCD experience looks like. Changed the option, restarted chrome, but everything still looks good.

FireBurn commented 4 years ago

Even after a restart?

skinkie commented 4 years ago

Even after a full restart.

skinkie commented 4 years ago

Switching back to 5.5.13 doesn't give me pink colours either.

FireBurn commented 4 years ago

I think I might be seeing the same thing on on my Raven system, I've pushed the patches that Fedora are using and I'm compiling them now to test

I'll let you know how I get on

skinkie commented 4 years ago

Thanks for the follow up!

FireBurn commented 4 years ago

I'm not convinced that these are accelerating everything, so I don't recommend emerging the new patches just yet

skinkie commented 4 years ago

I have updated to n 81.0.4044.122 because the portage version was trying to update. But I do not see any improvement.

FireBurn commented 4 years ago

I'm now getting a message saying VAAPI isn't available with Angle, and forcing desktop GL isn't accelerating:

Messages I see:

[403288:403288:0614/190907.468152:WARNING:vaapi_wrapper.cc(493)] : VAAPI video acceleration not available for angle

OpenGL forced:

[402065:402367:0614/185849.904988:ERROR:vaapi_wrapper.cc(2482)] vaEndPicture failed, VA error: invalid parameter [402065:402367:0614/185849.905165:ERROR:vaapi_video_decoder.cc(257)] Error decoding stream

skinkie commented 4 years ago

@FireBurn with 85 I get:

[67689:67689:0614/205511.453738:ERROR:sandbox_linux.cc(374)] InitializeSandbox() called with multiple threads in process gpu-process.
mesa: for the --simplifycfg-sink-common option: may only occur zero or one times!
mesa: for the --global-isel-abort option: may only occur zero or one times!
mesa: for the --amdgpu-atomic-optimizations option: may only occur zero or one times!
Received signal 11 SEGV_MAPERR 000000000060
#0 0x55950bdc07c9 (/usr/lib64/chromium-browser/chrome+0x4ee47c8)
#1 0x55950bd1f643 (/usr/lib64/chromium-browser/chrome+0x4e43642)
#2 0x55950bdc0382 (/usr/lib64/chromium-browser/chrome+0x4ee4381)
#3 0x7f2b391d1700 (/lib64/libpthread-2.31.so+0x136ff)
#4 0x7f2b2144bfa5 <unknown>
#5 0x7f2b2144e82e <unknown>
#6 0x7f2b2144b714 <unknown>
#7 0x7f2b210ec846 <unknown>
#8 0x7f2b3165444f vaEndPicture
#9 0x559508f71013 (/usr/lib64/chromium-browser/chrome+0x2095012)
#10 0x559508f70d77 (/usr/lib64/chromium-browser/chrome+0x2094d76)
#11 0x559508f66c91 (/usr/lib64/chromium-browser/chrome+0x208ac90)
#12 0x559508f41bb6 (/usr/lib64/chromium-browser/chrome+0x2065bb5)
#13 0x559508f419e5 (/usr/lib64/chromium-browser/chrome+0x20659e4)
#14 0x559508f56545 (/usr/lib64/chromium-browser/chrome+0x207a544)
#15 0x55950bd85d53 (/usr/lib64/chromium-browser/chrome+0x4ea9d52)
#16 0x55950bd9f4c7 (/usr/lib64/chromium-browser/chrome+0x4ec34c6)
#17 0x55950bd9eef8 (/usr/lib64/chromium-browser/chrome+0x4ec2ef7)
#18 0x55950bdd1a5a (/usr/lib64/chromium-browser/chrome+0x4ef5a59)
#19 0x55950bd9e8a9 (/usr/lib64/chromium-browser/chrome+0x4ec28a8)
#20 0x55950be17c19 (/usr/lib64/chromium-browser/chrome+0x4f3bc18)
#21 0x55950be1782d (/usr/lib64/chromium-browser/chrome+0x4f3b82c)
#22 0x55950bdd22be (/usr/lib64/chromium-browser/chrome+0x4ef62bd)
#23 0x7f2b391c5fe7 start_thread
#24 0x7f2b3522e4cf clone
  r8: 00002195c14fbe00  r9: 0000000000000011 r10: 00002195c12b7c00 r11: 00002195c14fbee0
 r12: 00002195c143b000 r13: 00002195c1447078 r14: 00002195c1447078 r15: 0000000000000000
  di: 00000000000002d0  si: 00000000000158e3  bp: 00002195c1447078  bx: 00007f2b1d4c5000
  dx: 0000000000000000  ax: 0000000000000000  cx: 0000000000000500  sp: 00007f2b153051b0
  ip: 00007f2b2144bfa5 efl: 0000000000010206 cgf: 002b000000000033 erf: 0000000000000004
 trp: 000000000000000e msk: 0000000000000000 cr2: 0000000000000060
[end of stack trace]
Calling _exit(1). Core file will not be generated.
[68209:68209:0614/205541.281793:ERROR:sandbox_linux.cc(374)] InitializeSandbox() called with multiple threads in process gpu-process.
mesa: for the --simplifycfg-sink-common option: may only occur zero or one times!
mesa: for the --global-isel-abort option: may only occur zero or one times!
mesa: for the --amdgpu-atomic-optimizations option: may only occur zero or one times!
[68090:7:0614/205618.561188:ERROR:command_buffer_proxy_impl.cc(122)] ContextResult::kTransientFailure: Failed to send GpuChannelMsg_CreateCommandBuffer.

The SEGV_MAPERR happens directly when playing a YouTube video. The CPU load by htop:

 67972 skinkie    20   0 5060M  447M  188M S 165.  2.9  3:19.90 /usr/lib64/chromium-browser/chrome --type=renderer --file-url-path-alias=/gen=/usr/lib64/chromium-browser/gen --field-trial-handle=4917717523979547926,9849566249966559253,13
  69512 skinkie    20   0  590M  153M  122M S 62.8  1.0  0:54.76 /usr/lib64/chromium-browser/chrome --type=gpu-process --field-trial-handle=4917717523979547926,9849566249966559253,131072 --gpu-preferences=MAAAAAAAAAAgAAAAAAAAAAAAAAAAAAAAA
  69556 skinkie    20   0  590M  153M  122M R 60.2  1.0  0:52.03 VizCompositorTh
lferra commented 4 years ago

The SEGV_MAPERR happens directly when playing a YouTube video.

I had the same issue and it turns out (at least in my case), last media-video/ffmpeg update to 4.3 was the culprit. Reverted to 4.2.3 and the crash is gone.

I'm now getting a message saying VAAPI isn't available with Angle, and forcing desktop GL isn't accelerating:

Same issue with 85 going back to 84 for now

[ebuild   R   ~] www-client/chromium-85.0.4173.0::FireBurn  USE="closure-compile cups hangouts kerberos (pic) proprietary-codecs pulseaudi
o suid system-ffmpeg system-icu tcmalloc vaapi widevine (-component-build) -custom-cflags (-selinux) (-system-libvpx)"
FireBurn commented 4 years ago

Hi, the chromium 84 build in my repo is working with video acceleration, I've just tested it with a 4K stream on my Raven machine

The 85 builds are having issues, vaapi doesn't work with angle which now seems to be the default, setting --use-gl=desktop or egl doesn't get it working, neither does using Ozone

I'm hoping the switch to Ozone will be happening soon and dmabuf video acceleration will be worked on next- this is what FireFox is using for their wayland builds

FireBurn commented 4 years ago

So the 84 & 85 builds are both working, the issues I was having turns out to be with dav1d, some videos were automatically using that codec

I've installed h264ify and edited the ~/.config/chromium/Default/Extensions/aleakchihdccplidncghkekgioiakgal/1.1.0_0/src/inject/inject.js so only av1 is blocked which did the trick

My intel laptop doesn't do vp8/9 so I just stick with the standard h264ify

media-internals show Mojo Player and 4k plays smoothly on my Raven system

skinkie commented 4 years ago

@FireBurn what is the acceptable load on a raven system for 1080p? My main point is, why is mpv able to do much better than Chromium.

FireBurn commented 4 years ago

I think it's inefficient use of buffers

Do you see better results if you start chromium with --enable-zero-copy

On Thu, 16 Jul 2020, 18:30 Stefan de Konink, notifications@github.com wrote:

@FireBurn https://github.com/FireBurn what is the acceptable load on a raven system for 1080p? My main point is, why is mpv able to do much better than Chromium.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/FireBurn/Overlay/issues/68#issuecomment-659559573, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAVD47SBDVUIU3S6HHHXDLR342KJANCNFSM4ML7XVQQ .

skinkie commented 4 years ago

I am on 85 at this moment, but with h264ify I am positively surprised it is now (even without the zero copy argument) only two processes of 50% cpu load. In compare not using h264ify I am around 300% cpu.

FireBurn commented 4 years ago

Vaapi enabled chromium is now upstream in ::gentoo