You are not logged in.
Is HW accel broken on wayland with intel?
It works until i add the following wayland flags to enable wayland:
--enable-features=VaapiVideoDecodeLinuxGL --enable-features=UseOzonePlatform --ozone-platform=wayland
UPDATE:
They must have fixed something after latest update (2 chromium updates today) now it works with just these flags:
--enable-features=VaapiVideoDecodeLinuxGL --ozone-platform=wayland
Adding this flag seems to break it:
#--enable-features=UseOzonePlatform
There is no problem with Chromium, VA-API, Wayland or any combinations thereof. What you seem to experience is that the --{enable.disable}-features= flags are simply not cumulative. Specify a single --enable-features= flag with all desired features comma-separated.
Last edited by intelfx (2024-05-11 04:34:19)
Offline
Hello and thanks for this thread.
It's been very useful when fighting with chrome/chromium flags.
For anyone struggling with video decode acceleration not working, here are the steps that I needed to take to get it fixed:
- First, according to the previous posts, passing the flag
--enable-features=VaapiVideoDecodeLinuxGL
is supposed to enable it.
- The problem I had was that even though under chrome://flags it was saying that video encode/decode hardware acceleration is on, when playing youtube videos, there was
no gpu video acceleration usage (as reported by intel_gpu_top)
- It turned out that I needed to delete the old chrome config and all of its cache:
rm -r ~/.config/google-chrome ~/.cache/google-chrome
Turns out that some of the old config was interfering with the proper setup of the gpu acceleration.
For reference I'm using intel iris Xe graphics with the following driver versions
vulkan-intel 1:24.0.6-2
intel-media-driver 24.2.2-1
I can't believe video hardware acceleration is in mainland chrome/chromium. Previuously I needed to use the chromium-wayland-vaapi which relied on wayland-chromium custom version of wayland that has recently stopped playing nicely with sway because of the protocol version bump. Now finally it is possible to have video acceleration in native wayland without hacky packages.
Offline
I noticed the patch works just fine on AMD, but it produces a lot of tearing on GeForce Now, making it unfit to game on. Does anyone else here experienced this? Using the latest stable version of Google Chrome. It occurs on all chromium derivatives as well. On X11 and xWayland.
Offline
Should I follow other AMD users and give up for now?
Apparently. It's still entirely disfunctional with the fallback to SW-decoding and it has been like that for pretty much half a year.
This is the year of the Linux desktop
Offline
The patch from hmann has been merged and will be included in the Mesa 24.1.0 release. I'm really looking forward to it and hope it will resolve the issue.
Offline
The patch from hmann has been merged
Ah, for some reason I had assumed that patch was already included in the Arch mesa package. When building 24.0.7 with the patch (mesa-git doesn't build), VaapiVideoDecoder finally works with the flags from that MR, however it introduces the same rendering issues on figma.com (WebGL) as I had previously with Vulkan. With use-angle=gl WebGL works without issues, but VAAPI fails again.
Last edited by CBiX (2024-05-24 14:22:30)
Offline
Offline
timochan wrote:The patch from hmann has been merged
Ah, for some reason I had assumed that patch was already included in the Arch mesa package. When building 24.0.7 with the patch (mesa-git doesn't build), VaapiVideoDecoder finally works with the flags from that MR, however it introduces the same rendering issues on figma.com (WebGL) as I had previously with Vulkan. With use-angle=gl WebGL works without issues, but VAAPI fails again.
You would be happy to know that with this patch your issues on figma.com will be gone and you will also finally be able to use vaapi on ozone wayland with amd cards (just be sure to use mesa 24.1).
Unfortunately Arch Linux developers won't honor my merge request until the patch gets upstreamed, so be sure to vote for this issue and report how the patch works for you: https://issues.chromium.org/issues/334275637
Offline
Just a quick note to append to darkbasic's post, I've submitted a patch upstream to add `--use-angle=vulkan` to the allow list for `GLImplementations` when Ozone platform is Wayland. See https://issues.chromium.org/issues/334275637#comment5 for details and my testing results on a Framework 13.
Use the following startup arguments with an up-to-date Mesa to get VA-API working:
--ozone-platform=wayland
--use-angle=vulkan
--enable-features=Vulkan,VulkanFromANGLE,DefaultANGLEVulkan,VaapiIgnoreDriverChecks,VaapiVideoDecoder,UseMultiPlaneFormatForHardwareVideo,VaapiVideoEncoder
It does unfortunately require a trivial patch to Chromium. Will need to either binary patch Chromium, which is a trivial one-byte change if you have debug symbols to find the method, or rebuild Chromium entirely with the Arch Build System until this makes it upstream. I can submit a CL to Chromium if we can get a Chromium committer assigned to the bug and/or for one to commit to a code review - if they don't want to submit the CL themselves.
Offline
Will need to either binary patch Chromium, which is a trivial one-byte change if you have debug symbols to find the method
That would actually be a VERY smart way to build an AUR package as a temporary solution!
Offline
I tried to find the debug symbols for the Arch chromium package and had no luck. Seems the Debian ones at http://debug.mirrors.debian.org/debian- … /chromium/ are also broken .
I ended up using the symbols for Brave (https://aur.archlinux.org/packages/brave-bin) from https://github.com/brave/brave-browser/releases/latest.
I'll see if I can get something up on the AUR this weekend.
Offline
I have made and tested this AUR package https://aur.archlinux.org/packages/goog … and-vulkan (EDIT: changed link, was asked to move package) and details on how to use it are in the pinned comment. Note that you need Mesa 24.1 or later if you're on AMD and expect VA-API to work. This was released on Arch earlier today and so your local mirror may not have it yet. The package applies the one-byte patch I alluded to above.
The patch is written in as applied as radare2 script:
# find 4889430841c70604000000 which is 'mov qword [rbx + 8], rax; mov dword [r14], 4'
/x 4889430841c70604000000
# seek to the first hit
s hit0_0
# seek to the "04" which is ANGLEImplementation::kOpenGLES
s+7
# Overwrite the "04" with "06" which is ANGLEImplementation::kVulkan
w1+2
This same patch also works against https://github.com/brave/brave-browser/releases/latest since they both use the same vendored compiler toolchain to build. Brave supplied the debug symbols which made this possible.
I haven't yet been able to make this patch against https://archlinux.org/packages/extra/x86_64/chromium/ because it's compiler/linker emits very different code and I haven't been able to find or build debug symbols to use as a map. Since LTO (Link Time Optimization) is enabled, we would need to complete and link an entire build and save them as either a Crashpad or DWARF file. I looked at the emitted code for wayland_surface_factory.cc with LTO turned off and there were no near matches.
I normally use the Google build of Chrome anyways, so I'll maintain the package while I find it useful and keep testing.
Last edited by prydom (2024-05-27 15:47:58)
Offline
theDude1848 wrote:On Chromium 123 HW-Acceleration with Mesa-git and Patch from Hmon is not working anymore on Gnome. Any ideas how to fix it? Did flags changed?
Are you sure you don't have --enable-features=RawDraw ?
It regressed in Chromium 123.
I reported this regression and the fix will be included in chromium v127
Offline
be sure to vote for this issue and report how the patch works for you: https://issues.chromium.org/issues/334275637
Just had my machine build chromium overnight with the patch and am happy to report it now works on Wayland without those WebGL issues, thanks for your work! I'll leave a comment upstream in a bit
Working flags for AMD / Wayland / mesa >= 24.1.0 / chromium with patch:
--ozone-platform-hint=auto
--use-gl=angle
--use-angle=vulkan
--enable-features=VaapiVideoEncoder,Vulkan,VulkanFromANGLE,DefaultANGLEVulkan,UseMultiPlaneFormatForHardwareVideo,VaapiIgnoreDriverChecks
(VaapiVideoDecoder seems on by default; IIUC VaapiVideoEncoder is supposed to use GPU for outgoing camera stream in video calls but it seems to do nothing in my tests with Google Meet and Jitsi)
Last edited by CBiX (2024-05-25 09:46:03)
Offline
thanks for your work!
You have to thank prydom: I've just created the merge request but he's the one who discovered that angle vulkan works well on ozone wayland.
Offline
I have made and tested this AUR package https://aur.archlinux.org/packages/goog … and-vulkan
Thanks!
Offline
Quick note if anyone is using the AUR package I posted. It was requested by another maintainer that I migrate the package to https://aur.archlinux.org/packages/goog … and-vulkan.
Offline
I use the Thorium browser, and when I use version 24.1.0 of Mesa, VA-API is successfully used for video decoding. I am very happy.
Offline
Is hevc decoding broken in google-chrome on amdgpu? It works in chromium (xwayland) with mesa 24.1 but not in google-chrome-wayland-vulkan (either ozone wayland or ozone x11).
Offline
Is hevc decoding broken in google-chrome on amdgpu?
AFAIK hevc is not supported in Chrome.
Offline
Is hevc decoding broken in google-chrome on amdgpu? It works in chromium (xwayland) with mesa 24.1 but not in google-chrome-wayland-vulkan (either ozone wayland or ozone x11).
Can't reproduce on 5850U, but maybe it depends on the hardware. vainfo yields
VAProfileHEVCMain : VAEntrypointVLD
VAProfileHEVCMain : VAEntrypointEncSlice
VAProfileHEVCMain10 : VAEntrypointVLD
VAProfileHEVCMain10 : VAEntrypointEncSlice
and testing with https://test-videos.co.uk/vids/bigbuckb … 0s_1MB.mp4 prints this under chrome://media-internals
kVideoDecoderName "VaapiVideoDecoder"
kIsPlatformVideoDecoder true
info "Selected VaapiVideoDecoder for video decoding, config: codec: hevc, profile: hevc main, level: not available, alpha_mode: is_opaque, coded size: [1920,1080], visible rect: [0,0,1920,1080], natural size: [1920,1080], has extra data: true, encryption scheme: Unencrypted, rotation: 0°, flipped: 0, color space: {primaries:BT709, transfer:BT709, matrix:BT709, range:LIMITED}"
Offline
Bzzz_56 wrote:Is hevc decoding broken in google-chrome on amdgpu? It works in chromium (xwayland) with mesa 24.1 but not in google-chrome-wayland-vulkan (either ozone wayland or ozone x11).
Can't reproduce on 5850U, but maybe it depends on the hardware. vainfo yields
VAProfileHEVCMain : VAEntrypointVLD VAProfileHEVCMain : VAEntrypointEncSlice VAProfileHEVCMain10 : VAEntrypointVLD VAProfileHEVCMain10 : VAEntrypointEncSlice
and testing with https://test-videos.co.uk/vids/bigbuckb … 0s_1MB.mp4 prints this under chrome://media-internals
kVideoDecoderName "VaapiVideoDecoder" kIsPlatformVideoDecoder true info "Selected VaapiVideoDecoder for video decoding, config: codec: hevc, profile: hevc main, level: not available, alpha_mode: is_opaque, coded size: [1920,1080], visible rect: [0,0,1920,1080], natural size: [1920,1080], has extra data: true, encryption scheme: Unencrypted, rotation: 0°, flipped: 0, color space: {primaries:BT709, transfer:BT709, matrix:BT709, range:LIMITED}"
Okay, it works on my radeon 780m too. I am just confused with codecs on bilibili videos (which I saw all fallback to avc format), but now I indeed see hvc codec is in used...
Offline
Hi guys
I'm a little confused by Google's git management
Does anyone know what version of Chromium this patch will be in - https://chromium-review.googlesource.co … /+/5568860 ?
Offline
The process is fully automated on the Chromium side.
Keep an eye on https://chromiumdash.appspot.com/commit … 3985b59178 and it will tell you the current target version(s).
Edit: Also note that https://gitlab.archlinux.org/archlinux/ … requests/6 has been merged so you'll get it much sooner if you use the Arch package.
Last edited by prydom (2024-05-30 17:33:28)
Offline