Hw acceleration doesnt work on wayland

[mthw0]

Greetings, Is it normal that when I use chromium in wayland session, when I look into chrome://media-internals, I see that videos are decoded by FFmpeg and not by GPU thus acceleration is not working? Is this caused by wayland or something else? I tested on Ubuntu+Gnome, Arch+Gnome, and Arch+KDE and I have intel graphics.

[saiarcot895]

That's a known/expected issue. Currently, Chromium is compiled with the assumption that it will run on X11. Eventually, I'm hoping I can set the build flag that abstracts the display driver (and that the platform-independent hardware acceleration code gets used).

[Pinqvin]

Are there some upstream changes that need to be made for Wayland support to happen, or would I be able to make a custom Wayland build with the current VA-API patches?

[mthw0]

@Pinqvin TBH I dont even know If VA-API works with Wayland and vice versa.

[saiarcot895]

VA-API does work with Wayland; you just have to use a different function to get it initialized (vaGetDisplayDRM instead of vaGetDisplayX11, I think).

There's upstream changes related to Wayland that still going in. You can try making a Wayland build, but I'm not sure if it would even compile or run as of right now. (My memory is a bit fuzzy, but there's something about ozone or some other component disabled on desktop Linux.)

[mthw0]

@saiarcot895 Is there any progress related to this bug or do you need something to be done in wayland itself?

[saiarcot895]

Let me try something to see if it would even work. The change will be in the dev branch.

[claudiuschan]

Hi @saiarcot895. I tried the latest build 65.0.3322.3, I still seeing the VAAPI initialization is not working. Just wondering if this version patch to work with wayland ?

I am using sway+wayland btw.

[14168:14249:0209/002837.005792:ERROR:bus.cc(394)] Failed to connect to the bus: Could not parse server address: Unknown address typ [14168:14190:0209/002837.006746:ERROR:in_progress_cache_impl.cc(93)] Could not read download entries from file because there was a r libva error: va_getDriverName() failed with unknown libva error,driver_name=(null) [14253:14253:0209/002837.680931:ERROR:vaapi_wrapper.cc(276)] vaInitialize failed: unknown libva error ATTENTION: default value of option force_s3tc_enable overridden by environment. [14168:14201:0209/002837.933242:ERROR:upload_data_presenter.cc(73)] Not implemente

[montvid]

Any updates on wayland support?

[saiarcot895]

For Wayland, the only hardware acceleration that is implemented as of right now appears to be through Video4Linux, not VA-API. From what I know, the two are for different purposes, so Video4Linux would not be a substitute for VA-API.

Additionally, building Chromium for Wayland (and thus using the Ozone abstraction layer) would break hardware video decoding for X11, and that isn't implemented through the Ozone layer. Therefore, I'm holding off on enabling Wayland support.

[mthw0]

Of topic: Did you try to create any vaapi patches for Firefox?

[saiarcot895]

I haven't, and I'm not sure if there's any floating around for Firefox.

[Queuecumber]

Ugly workaround, but what about providing a separate ozone build in the ppa for people who prefer to use wayland?

[mthw0]

@Queuecumber Can chromium already be built to work on wayland and with vaapi? I noticed there is already some work done, but is it working?

[Queuecumber]

@mthw0 I think you're right, I misunderstood the discussion

[saiarcot895]

There is some work being done to get Chromium fully functional on Wayland here, and I think it's at least usable. There is something related to hardware acceleration being done, but it's not VAAPI (note that VAAPI itself does work with Wayland).

I would have already created a separate PPA for the wayland build, but Chromium takes a long time to build (6-8 hours), and I want to see if I can somehow do it in the existing build and reuse the build objects. I may end up making a separate PPA in the end.

[Queuecumber]

note that VAAPI itself does work with Wayland

There are libva-wayland{1,2} packages on Ubuntu and I have them installed, granted I haven't done much testing but I was under the impression they worked. I just tried it out with mpv --hwdec=vaapi and the only thing in the output that looked like an error was

[vo/opengl] retrieving framebuffer depth: OpenGL error INVALID_OPERATION.

otherwise the playback seemed to work fine

I would have already created a separate PPA for the wayland build

I did use your chromium build as-is under wayland and it seemed to work except for the video acceleration. Maybe it was using XWayland though?

[saiarcot895]

With libva, there are two different methods to use to initialize VAAPI: one for an X11 environment, and one for Wayland/DRM environment. Chromium only uses the former one.

Under wayland, Chromium still runs as an X11 application, under XWayland.

[Queuecumber]

And presumably an X11 app running in XWayland and trying to use VAAPI using the X11 mechanism fails

[mthw0]

@Queuecumber Not necessarily, VLC works this way.

[Queuecumber]

Interesting, then I wonder why chromium can't also be made to work like that as a stopgap

[Esokrates]

@saiarcot895 Has the situation changed meanwhile? Would it be possible to provide a separate ppa for wayland with vaapi working?

[alephnull]

@msisov is working on getting chromium to support wayland. See https://github.com/Igalia/chromium/issues/540 for more details.

There is also a version with an old version of chromium that makes no claims of compatibility but does claim VAAPI support at https://github.com/intel/ozone-wayland

Compiling a browser is 2019's version of building the kernel.

[qnixsynapse]

Unfortunately Mesa on my AMDGPU doesn't support EGL_EXT_image_dma_buf_import_modifiers EGL extension and hence cannot use zwp_dmabuf_linux protocol to run a GPU multi process chromium natively on Wayland and it falls back to software rendering by default. Previously chromium with ozone was crashing but upstream fixed it. So we had to use --in-process-gpu at the moment to get hardware acceleration "partially". :( Don't know if it implemented on other newer AMDGPUs.

@capOM Sorry for tagging you here, Is this possible to implement this extension? My GPU has EGL version 1.5(Polaris12). Is there any hope? :(

[msisov]

@akarshanbiswas but you have wl_drm, don’t you?

[qnixsynapse]

@msisov Yes.

[msisov]

1. the zwp Linux dmabuf protocol says that it is based on support of EGL_EXT_image_dma_buf and EGL_EXT_image_dma_buf_import_modifiers. It’s not necessary to have the last one, but the first one.
2. One of my machines also have amd gpu. It is 460 one. On gnome Wayland, there is no zwp Linux dmabuf protocol available, but wl drm instead. However, when I open Weston in the same session as nested compositor, the zwp protocol becomes available. I suppose it’s something compositor settings related.
3. to make the Wayland support to be trouble free, I had an idea to pull wl_drm to chromium’s Wayland protocols and make use of that protocol extension as well.

I haven’t really read about it, but it seems like it also allows to create wl_buffers out of prime fds.

If it is the case, we are in a good position to have more supported devices.

[qnixsynapse]

@msisov I think I have the first one ( EGL_EXT_image_dma_buf_import) but it looks like mutter needs the later extension for the zwp linux dmabuf to work. Your point no. 2 is correct and I think I will ask the mutter developers about it.

to make the Wayland support to be trouble free, I had an idea to pull wl_drm to chromium’s Wayland protocols and make use of that protocol extension as well.

Awesome. BTW, Have you thought of anything for libgtkUI on ozone?

[msisov]

@akarshanbiswas we are working on libgtkui right now. Its initial purpose is to serve ozone/X11 as non-ozone path is going to be removed, but we also consider usage of it for Wayland. For example, for the file dialogs case

[qnixsynapse]

@msisov Thank you for all the info. :)

[msisov]

hey! Mind to test wl_drm support? https://chromium-review.googlesource.com/c/chromium/src/+/1827001