Have you tried --enable-features=VaapiVideoDecodeLinuxGL? This does get VA-API working on Ozone/Wayland (also Ozone/X11 with Vulkan disabled) with Intel cards, though there is an extra copy which hurts performance that doesn't happen on Vulkan.

As for the lack of Vulkan support under Ozone/Wayland, I think this is already known here: https://issues.chromium.org/issues/40722838 and https://issues.chromium.org/issues/41392107 though I'm not sure when Chromium devs plan to complete it

This can be enabled with a one line patch. It seems the necessary support in ozone and ANGLE are present. I can confirm that --enable-features=VaapiVideoDecodeLinuxGL results in CPU-only video encode and decode on AMD iGPUs.

Please consider enabling this, even if the support is experimental. This allows enhanced touchpad gesture support, accelerated video and WebGPU to be enabled simultaneously on the desktop Linux platform.

I've tested this patch on Chromium stable 125.0.6422.76 and it does allow VaapiVideoDecode to work on "AMD Ryzen 7 7840U w/ Radeon 780M Graphics" (Framework 13) with the following GPU0 in chrome://gpu VENDOR= 0x1002 [Google Inc. (AMD)], DEVICE=0x15bf [ANGLE (AMD, Vulkan 1.3.278 (AMD Radeon Graphics (RADV GFX1103_R1) (0x000015BF)), radv-24.1.0)], DRIVER_VENDOR=AMD, DRIVER_VERSION=24.1.0

I'm using Mesa 24.1.0-rc4 from Fedora Rawhide with VA-API drivers from RPM Fusion. Any release of Mesa with https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26165 merged should work. NVTop shows encode/decode blocks are being used and "VaapiVideoDecoder" shows in the media tab with H264, VP9, and AV1 encoded videos from YouTube and other sources. There are no console errors or warning output with either WebGPU or accelerated video content.

Use the following startup arguments to enable Vulkan and VA-API functionality:

--ozone-platform=wayland
--use-angle=vulkan
--enable-features=Vulkan,VulkanFromANGLE,DefaultANGLEVulkan,VaapiIgnoreDriverChecks,VaapiVideoDecoder,UseMultiPlaneFormatForHardwareVideo,VaapiVideoEncoder

The attached patch is to ui/ozone/platform/wayland/gpu/wayland_surface_factory.cc and adds impls.emplace_back(gl::ANGLEImplementation::kVulkan); below impls.emplace_back(gl::ANGLEImplementation::kSwiftShader);.

I am not currently an individual Chromium contributor. I have provided non-code contributions in the past via the VRP. If there is interest in CL/CQ submission and review, please let me know and I will work through that.

Thanks for the Arch pull request, even if they can't accept it until this is upstream.

I found these flags via the forum post https://bbs.archlinux.org/viewtopic.php?id=244031&p=41 and folks there are keenly interested in seeing this working. I don't currently have an account there so if you want to put the word out on that thread to get more eyes on this please do. It's pretty trivial to use the Arch Build System to test this and indeed that's how I have my build/patchset orchestrated.

I second that graphical performance is much better with this functionality enabled and I believe this brings the desktop Linux platform closer to the ChromeOS Lacros rendering path which, if true, may bring maintenance cost down and ensure there are active maintainers.

I was one of those people with WebGL issues on X11 and now successfully tested the patch with Wayland (with patched mesa 24.0.7) on my AMD 5850U (GPU0: VENDOR= 0x1002 [Google Inc. (AMD)], DEVICE=0x1638 [ANGLE (AMD, Vulkan 1.3.274 (AMD Radeon Graphics (RADV RENOIR) (0x00001638)), radv-24.0.7)], DRIVER_VENDOR=AMD, DRIVER_VERSION=24.0.7).

Since it's an opt-in, non-breaking change I'd suggest to apply the patch.

https://chromium-review.googlesource.com/c/chromium/src/+/5568860

A CL is currently waiting for more specific opinions from Google engineers.

Thanks @hocheung for the CL.

With regards to the comments in the review now, this feature is already pretty well guarded because the default is the first item added to the list in GetAllowedGLImplementations() and as far as I could find, other than --use-angle= there are no other places where ANGLE's backend is configured. I think you covered that pretty well in your commit message.

The current behavior, when an unsupported ANGLE backend is selected, is to disable all hardware acceleration features. This indicates that no downstream distributor should be setting that flag with the Vulkan option on Linux today and it shouldn't be accidentally enabled for anyone when this lands.

I have tested this on integrated Intel and AMD GPUs (with Mesa drivers, versions 24.0 and 24.1) but not yet NVIDIA. If someone could test NVIDIA's drivers that would be helpful. I've tested VA-API, WebGL, and WebGPU through demos and daily use for over a week.

This has been fixed, if there are any regressions related to it, feel free to revert the CL

It required --enable-features=Vulkan, --enable-features=DefaultANGLEVulkan, or --use-angle=vulkan to be set on both the Intel and AMD GPUs I tested with for the ANGLE backend to be set to Vulkan. The code which seems to trigger enabling ANGLE Vulkan when those flags are set is in gl_display_initializer.cc

Do we know if any other flags or features influence the ANGLE backend? Is the testing unknowingly relying on the gpu blacklist? Have there been other changes in Chrome 126-127 which could influence the selected backend?

Given the Vulkan ANGLE backend, when combined with Wayland, does really resolve some outstanding issues it would be ideal to have a way for those willing to risk regressions to use it.

If there is another ANGLE init then it should be file searchable on source code... And also interesting problem is that in some time Vulkan+Wayland could be supported better than egl on new hardware... but when untested and undeveloped, not so great idea to be default renderer and user could set his own choice if has such idea to opt-in or opt-out by driver policy...

Commenter #18, have you applied the patch https://chromium-review.googlesource.com/5568860?

If not, the flags for ANGLE's Vulkan backend don't work on Wayland. Arch's fork has the patch, https://gitlab.archlinux.org/archlinux/packaging/packages/chromium/-/blob/main/PKGBUILD?ref_type=heads#L30 if you don't want to compile. There also exists a binary patch on the AUR if you need to use Chrome. I won't link it here as it's very unofficial.

Here's the flags which work on my Framework 13: --ozone-platform=wayland --use-angle=vulkan --enable-features=TouchpadOverscrollHistoryNavigation,Vulkan,VulkanFromANGLE,DefaultANGLEVulkan,VaapiIgnoreDriverChecks,VaapiVideoDecoder,UseMultiPlaneFormatForHardwareVideo,VaapiVideoEncoder Been using them for weeks now with no issues noticed - multiple tools (e.g. nvtop), chrome://gpu, and Chromium dev tools all confirm that VAAPI is functional. I'm on Mesa 24.1.2.

Glad you got it working.

The main thing you loose out on sticking with the Ozone X11 backend is the improved touchpad gesture support and on some Wayland desktop environments you may have high DPI scaling issues. On the Framework I do find the touchpad zoom support indispensable.

I will investigate and re-communicate with the engineers about this issue, but please note: hardware acceleration on Linux distributions (except ChromeOS and Android) has always been unsatisfactory. This is limited by various factors, including infrastructure, distribution packages, etc. Please do not have too high expectations.

I'm attempting to remove the vulkan field trial again so we can land the vulkan impl patch if that stabilizes.

On Version 127.0.6533.57 (Official Build) beta (64-bit):

Tested --ozone-platform=wayland --use-angle=vulkan --enable-features=Vulkan,VulkanFromANGLE,DefaultANGLEVulkan,VaapiIgnoreDriverChecks,VaapiVideoDecoder,UseMultiPlaneFormatForHardwareVideo,VaapiVideoEncoder

Hardware acceleration is still not available on ozone wayland

Hello #28, as mentioned multiple times the only place the fix detailed in this bug report has landed is the Arch Linux Chromium build. Otherwise, it is expected to not work regardless of the flags you set.

If you are on a different distro you can build chromium with the patch https://chromium-review.googlesource.com/c/chromium/src/+/5568860 yourself or find (and audit if you're inclined) the one-byte binary patch I maintain on the AUR and apply that to Google Chrome. I actually use the patch on Fedora and know based on feedback from myself and others that it works fine across distros. I will bump that patch to 126.0.6478.182 later today.

Please test the code patch if you can and report back if you encounter issues. The binary patch is not supported here; comment on the AUR thread if you find issues with it.

Re comment#29

I was asked by someone else to test it on my Fedora system

I also don't know how nor plan to compile chromium myself

I am willing to wait and test for a latter release in other package repositories

Are there any ETA for Fedora ?

Hello #28/#30,

This is a volunteer effort. I looked into doing a Copr package (similar to Ubuntu PPAs) for Fedora but it seemed like a full build of Chromium would be high effort and compute cost to maintain on their build infra. Very wasteful for what is nearly a one line patch. Similar deal for OpenSUSE's Build Service.

If you are willing to do maintainer outreach to raise visibility and get this patched downstream at places already building Chromium, please do! Fedora and Debian would be good places to start. Ubuntu distributes Chromium as a Snap nowadays so that's likely a dead end. But you might also consider getting this patch applied to the Flatpak as that would be cross distro.

Arch's requirement was that we land the patch somewhere in the upstream tree, which it was briefly, so that they could benefit from Google's CL/CQ process. I expect most distros to follow a similar process or require a trusted resource/maintainer to vet the patch.

I ask that if you do work on this issue with downstream distributions that you please link any mailing list threads or bug reports you open so that folks watching here can engage and vouch, if necessary.

Re comment#31

This is a volunteer effort

Cannot it be a patch in the official chromium source-code directly, distributed everywhere?
Would a volunteer third-part effort always be required to release and maintain this patch?

But you might also consider getting this patch applied to the Flatpak as that would be cross distro

Indeed, but the Flatpak chromium distribution suffer from issues with screen-sharing screen dimensions and unavailable PWA dock icon

Reply #32(alixbrunetcontact):

Kramer is trying to remove Vulkan's field trial(1). After the obstacles including Vulkan's field trial are eliminated, the CL mentioned in this issue(2) will have a chance to be merged back into the Chromium code base.

At that time, only the startup parameters need to be passed.

(1)Disable vulkan in fieldtrial_testing_config.json

(2)[ozone+wayland] Allow ANGLEImplementation::kVulkan when ozone platform is Wayland

alixbrunetcontact:

You were asking for a Fedora specific ETA and I was responding to that. Thank you Ho for continuing to move this forward with Chromium and Google!

Also with regards to the Flatpak suggestion, I hear you about it being insufficient. I can't use it myself due to incompatibilities with 1Password's Native Messaging due to 1P's hardening. It is also interesting to hear that you're having issues with accessing the xdg-portals for screen sharing - that may be worth reporting to the Flatpak packaging folks as they are common contributors to the portals. The way those portals work, the dimensions come right from the passed Pipewire buffer and/or from the accompanying dbus messages so I'm unsure why it wouldn't make it though to the Flatpak environment.

Please note though that based on comment#24 and comment#33 we still can't assume it's a given that the ozone patch will land and stick. If it does, the change making it to stable is still sometime away. You can use https://chromiumdash.appspot.com/schedule and https://chromiumdash.appspot.com/commits?platform=Linux to estimate when it will be available in the official Google Chrome builds.

#26 #29 I am using the Arch Linux build while facing the issue I mentioned in #25.

$ chromium --version
Chromium 127.0.6533.57 Arch Linux

Hardware decode works as shown by various tools like nvtop. However, the video is not displayed, it is transparent and shows the last frame of what was in its place. The logs keep repeating these two lines:

[9893:9951:0723/180316.312355:ERROR:skia_output_surface_impl.cc(674)] : Failed to create the promise sk image
[9893:9951:0723/180316.312442:ERROR:skia_renderer.cc(699)] : Failed to create the promise sk image or get paint ops.

Hello #35 Could you provide additional details about your configuration as per the list below. I've only tested the patch on stable 126 and earlier. 127.0.6533.57 may have bumped Skia and caused some regressions and it would be interesting to explore that.

• chrome://gpu graphics status (the first header on the page)
• graphics hardware details (the patch is needed due to an AMD hardware and Mesa driver issue resulting in hardware decode only working when requested from Vulkan -- on Intel and Nvidia, you shouldn't need this and can follow the conventional advice)
• Mesa version (Your on Arch and so should have a new enough version but it's good to know anyways)
• Chromium startup flags (these go in ~/.config/chromium-flags.conf on Arch)
• Wayland compositor (e.g. KDE/kwin, Gnome/Mutter, Sway/Wlroots)

As a quick datapoint, I just installed "Version 127.0.6533.57 (Official Build) Arch Linux (64-bit)" in an Arch distrobox container and an AV1 Youtube video and https://test-videos.co.uk/vids/bigbuckbunny/mp4/h264/1080/Big_Buck_Bunny_1080_10s_10MB.mp4 are displaying fine. No relevant console output.

Dev tools media tab's "Decoder name" is VaapiVideoDecoder as expected. I use KDE/kwin as my compositor. This is a Framework 13 AMD running a Fedora 40 kernel but the userland binaries are from Arch (running in a Distrobox container).

My startup flags (Arch) are as below. This is a fresh profile, so there are no chrome://flags set.

$ cat ~/.config/chromium-flags.conf 
--ozone-platform=wayland
--use-angle=vulkan
--enable-features=TouchpadOverscrollHistoryNavigation,Vulkan,VulkanFromANGLE,DefaultANGLEVulkan,VaapiIgnoreDriverChecks,VaapiVideoDecoder,UseMultiPlaneFormatForHardwareVideo,VaapiVideoEncoder

Chrome://gpu shows a feature status:

Graphics Feature Status
=======================
*   Canvas: Hardware accelerated
*   Canvas out-of-process rasterization: Enabled
*   Direct Rendering Display Compositor: Disabled
*   Compositing: Hardware accelerated
*   Multiple Raster Threads: Enabled
*   OpenGL: Enabled
*   Rasterization: Hardware accelerated
*   Raw Draw: Disabled
*   Skia Graphite: Disabled
*   Video Decode: Hardware accelerated
*   Video Encode: Hardware accelerated
*   Vulkan: Enabled
*   WebGL: Hardware accelerated
*   WebGL2: Hardware accelerated
*   WebGPU: Disabled
*   WebNN: Disabled

glxinfo extended renderer info is:

Extended renderer info (GLX_MESA_query_renderer):
    Vendor: AMD (0x1002)
    Device: AMD Radeon 780M (radeonsi, gfx1103_r1, LLVM 18.1.8, DRM 3.57, 6.9.8-200.fc40.x86_64) (0x15bf)
    Version: 24.1.4
    Accelerated: yes
    Video memory: 512MB
    Unified memory: no
    Preferred profile: core (0x1)
    Max core profile version: 4.6
    Max compat profile version: 4.6
    Max GLES1 profile version: 1.1
    Max GLES[23] profile version: 3.2

#36 Here are the details of my system:

• chrome://gpu

Graphics Feature Status
=======================
*   Canvas: Hardware accelerated
*   Canvas out-of-process rasterization: Enabled
*   Direct Rendering Display Compositor: Disabled
*   Compositing: Hardware accelerated
*   Multiple Raster Threads: Enabled
*   OpenGL: Enabled
*   Rasterization: Hardware accelerated
*   Raw Draw: Disabled
*   Skia Graphite: Disabled
*   Video Decode: Hardware accelerated
*   Video Encode: Hardware accelerated
*   Vulkan: Enabled
*   WebGL: Hardware accelerated
*   WebGL2: Hardware accelerated
*   WebGPU: Disabled
*   WebNN: Disabled

• graphics hardware and mesa version from lspci and glxinfo:

04:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Rembrandt [Radeon 680M] (rev 02)

Extended renderer info (GLX_MESA_query_renderer):
    Vendor: AMD (0x1002)
    Device: AMD Radeon Graphics (radeonsi, rembrandt, LLVM 18.1.8, DRM 3.57, 6.10.0-arch1-2) (0x1681)
    Version: 24.1.4
    Accelerated: yes
    Video memory: 512MB
    Unified memory: no
    Preferred profile: core (0x1)
    Max core profile version: 4.6
    Max compat profile version: 4.6
    Max GLES1 profile version: 1.1
    Max GLES[23] profile version: 3.2

• Chrome startup flags (I copied yours). I don't have any custom flags set in chrome://flags:

$ cat /etc/chromium-flags.conf
--ozone-platform=wayland
--use-angle=vulkan
--enable-features=TouchpadOverscrollHistoryNavigation,Vulkan,VulkanFromANGLE,DefaultANGLEVulkan,VaapiIgnoreDriverChecks,VaapiVideoDecoder,UseMultiPlaneFormatForHardwareVideo,VaapiVideoEncoder

• Wayland compositor: KDE/Kwin

Version
=======
KWin version: 6.1.3
Qt Version: 6.7.2
Qt compile version: 6.7.2
XCB compile version: 1.17.0

Could this be a bug affecting only Rembrandt 680M and not Phoenix 780M? Hardware decoding works perfectly fine in mpv. I do not know if this is related or not, but some 3D graphics are completely broken when using these flags (more precisely, when using vulkan). For example, on NASA's 3D viewer here: https://solarsystem.nasa.gov/gltf_embed/2340/

If I instead use these flags

--ozone-platform=wayland
--use-angle=gl

everything renders perfectly (but I don't have hardware video decoding). I attached two screenshots of this behavior.

#36, are you able or willing to run the ANGLE and Skia test suites and WebGL conformance tests, report back, and potentially file bugs (with ANGLE, Skia, or Mesa depending on what breaks)? You would likely need to compile (or at least configure) the Chromium source tree to get the correct configs for ANGLE and Skia.

ANGLE's tests are listed on https://github.com/google/angle/blob/main/doc/ContributingCode.md and Skia's are documented at https://skia.org/docs/dev/testing/testing/.

The root cause of the issues you're experiencing are unlikely to be in scope for this ticket. It would be up to Ho if this behavior is enough to block having this patch land.

Kramer has gone to great lengths to successfully disable Vulkan in field tests (1), but disabling Vulkan seems to break the CI workflow, called Linux Tests (dbg), which has 84 failure reports as of the time of my comment (2) (3).

Now, Kramer has decided to suppress these failed tests, but no one seems to be working on it yet.

In addition, it seems that we have recently received some reports from users about video playback anomalies after applying this patch #35 #39.

To sum up, I think we still need to wait for a while and make different things as stable as possible during this period of time and not cause more abnormalities before we have a chance to merge the patch again.

(1) https://chromium-review.googlesource.com/c/chromium/src/+/5714073

(2) https://chromium-review.googlesource.com/c/chromium/src/+/5736137

(3) https://ci.chromium.org/ui/p/chromium/builders/ci/Linux%20Tests%20%28dbg%29%281%29

+thomasanderson@ fyi.

Thank you ho #42 and sorry for the late reply. Sadly I am not knowledgeable enough to run these test suites, and WebGL conformance test crashed my chromium tab after a few hours of running. However, I did find that I was using amdvlk instead of mesa's RADV for a reason I do not know. Using RADV solved all the issues I had both with video not rendering and 3D models glitching. I am sorry for these unnecessary troubleshooting steps I caused.

I have re-landed the patch into the Chromium codebase and hopefully it won't cause any more issues, but if it does, feel free to revert.

Thank you Ho!