vaInitialize fails under Gnome Shell Wayland about libva HOT 19 CLOSED

Unofficial packages of Chromium with VAAPI enabled exist for at least Ubuntu and Arch, and the patch may be made official, but that still doesn't work with Wayland. Linux desperately needs a decent browser with hardware-accelerated video, and this issue could block that for many users.

from libva.

Wanted to report back that there has been some progress made regarding the vsync issues with chromium-vaapi under Xwayland. The patches from this bug, including the callback patchset now have hardware acceleration mostly working for me. https://gitlab.freedesktop.org/xorg/xserver/issues/631

I have rebased this patchset and the one for the intel-vaapi driver on the latest branches and everything is working. If the original submitter isn't going to rebase and submit I will send a new pull request since it is now a mostly functioning option, once the rest of this works makes it into Xwayland.

from libva.

@intelfx well Chromium doesn't work directly under Wayland, yet, although Igalia is making a lot of progress. This is Chromium running under XWayland and specifically, I am running it with gnome-shell wayland as my compositor. The initial work that @xhaihao did allow Xwayland based apps to use libva for hardware acceleration. However Chromium because of how it is architected exposed other limitations in the Present infrastructure that needed to be addressed before it was usable. Direct rendering would work, but Chromium couldn't display it properly because the XWayland Vsync timings were off. Now we are closer to having those issues closed due to the work done in the Xserver bug I posted above and things are pretty usable now.

I have run into a couple of crashers that I need to debug, but in general, it is stable enough that I now want to get these patches cleaned up and merged so we can clean up the rest of the pieces. I think this is even more relevant since more distributions are now providing Chromium with the vaapi patches built. Fedora 29 now has chromium-vaapi in their repos, Aarch has had it for a while, and I believe there is an Ubuntu PPA that provides it.

I will try and get pull requests for my rebased work submitted this week, I will also include documentation on what I needed to do in order to get Chromium-Vaapi running decently under XWayland. There has been some discussion on the closed Xserver bug and another bug will be opened to work on this further.

from libva.

Did you compile libva and intel-vaapi-driver with Wayland support?

from libva.

@chivakker I'm seeing what looks like this issue with the stock libva shipped with fedora 26 (libva-1.8.3-1.fc26.x86_64), and the corresponding libva-intel-driver from rpmfusion (libva-intel-driver-1.8.3-2.fc26.x86_64).

I raised https://bugzilla.redhat.com/show_bug.cgi?id=1491186 for fedora, and we have done some investigation there, there is also a simplified reproducer.

Regards
Stuart

from libva.

I did not compile libva. Just using the standard Ubuntu installation. We have it working now, including Wayland.

The problem and the solution are both detailed in the first comment already, so you might want to read that...

For Ubuntu what we did to work around the issue was to prioritize Wayland over X11 in both mpv and gstreamer-opengl (to aid gstreamer-vaapi). So that way video players don't attempt to use X11 with Xwayland and then give up. They use native Wayland instead.

from libva.

The proper solution for libva would be to support DRI3, so that libva doesn't fail when talking to Xwayland.

from libva.

I filed https://github.com/01org/libva/issues/122 to track the support for DRI3.

from libva.

While strictly accurate, it might be harsh and unnecessary for me to suggest libva needs DRI3 support.

Ubuntu doesn't need that any more. What I said does not scale is in fact what we have now done as a workaround. And really even in a world where libva supported DRI3, I still think these "workarounds" for mpv and gstreamer-vaapi are in fact along the lines of what player apps should be doing. They don't have to prioritize Wayland over X11, but they should be flexible enough to at least try libva with Wayland if X11 has already failed to init. The assumption that there's only one windowing system present is the real mistake because in the world of Xwayland (always present for Gnome Shell) it's no longer true.

from libva.

I have been testing these patches on my Intel based laptop. Chromium running under XWayland sees significant stuttering when using DRI3 and Present. I assume this is happening because XWayland 1.20 now supports double buffering. I will follow up with some logs when I dig into this deeper.

from libva.

@jnettlet That could be because of https://bugs.freedesktop.org/show_bug.cgi?id=106841.

from libva.

@realh thanks for the heads up. I have been tracking most the open bugs on these various issues. Tested that patch earlier today and that fixes the drawing corruption I was seeing but not the frame jumping and repeating. I attempted to run Chrome with vertical sync disabled and also patched the intel-vaapi-driver to pass the XCB_PRESENT_OPTION_ASYNC option into present to try and completely bypass flipping, however the behaviour did not change.

from libva.

@jnettlet I applied the libva + intel driver DRI3 patches to Arch's packages (at version 2.2.0) and that caused stuttering in Chromium, almost certainly the same problem you described. Did you ever get to the bottom of it?

I have to launch Chromium with --use-gl=egl when using dri3, otherwise the video stays black, and I think it's EGL Chromium has the problem with. With the EGL flag I get the stuttering both with and without the dri3 patches, and in both Wayland (with dri3) and X11. gstreamer/totem and mpv (--vo=gpu --hwdec=vaapi) work fine with the dri3 patches, although totem had the black screen problem in one environment or the other, X11 IIRC.

from libva.

This apparently also affects AMDGPU+radeonsi under Wayland, as I can't get VA-API to enable there in Chromium, either. Or in VLC. VLC manages to initialize VDPAU, though.

from libva.

@jnettlet I was under impression that currently existing VA-API patches for Chromium never work under (X)Wayland?

from libva.

Just a quick follow up. With the default patchset I was still seeing some misrendering under XWayland in Chromium. I have fixed most of it so the playback looks solid, but I am still dropping frames occasionally. This is not choppy video but hitches every 10 seconds or so. I am assuming this is because the XWayland patches aren't still quite perfect yet. I also probably need to switch this to use triple buffering in the backend to help matchup video framerate vs vsync.

I will push my branches this weekend and then ask for more testing because I send an actual pull request.

from libva.

The patches from this bug, including the callback patchset now have hardware acceleration mostly
working for me. https://gitlab.freedesktop.org/xorg/xserver/issues/631

I see a closed issue there, but no patchset?!? I might be too stupid in order to use the gitlab page though. Mabye you can help me to find this patchset?

from libva.

from libva.

DRI3 support got added to libva in #614. Please, give it a try and open new issue(s) if needed.

from libva.