Firefox – we’re finally getting HW acceleration on Linux

Posted byMartin StranskyPosted inFedoraTags:, , , ,
A first image from original WebRender article. Published three years ago.

Firefox 84.0 is a big milestone for Firefox Linux development as it comes with HW acceleration by default for some Linux users. Stock Mozilla Firefox 84.0 enables WebRender (HW accelerated backend) for Gnome/X.org and Gnome/Wayland will be supported in Firefox 85.0. Fedora is bit ahead and enables WebRender for Gnome/Wayland in Firefox 84.0 too.

WebRender by default is restricted to AMD/Intel graphics cards as NVIDIA is known for various issues – both proprietary and Noveau drivers.

And why it’s enabled in Gnome only for now? For instance KDE is also a popular desktop environment. I think it’s because Gnome utilizes HW acceleration so when Gnome works on your box there’s assumption that Firefox will work too. KDE provides choices how to disable/restrict HW acceleration setup (for instance it supports disabled screen compositing) and it’s more difficult to cover various scenarios.

Another excluded group are XWayland users. It means you have Wayland as a desktop compositor but for some reasons you use X11 emulation layer and run Firefox as X11 application. It’s a valid scenario, Firefox with Wayland backend still suffers from some annoying bug, mostly related to popup windows.

But don’t worry, Mozilla folks are going to bring WebRender to the most Linux users on various desktops and graphics. Jan created a brief Linux WebRender state overview. And you can help with it! Please check if you have WebRender enabled and eventually try to enable it. Test various web pages, video playback, WebGL and report your experience. You can use comments below or drop me a mail at stransky@redhat.com.

33 thoughts on “Firefox – we’re finally getting HW acceleration on Linux”

    1. Yes, green means enabled. I see Intel is disabled for 4K screens, that’s because integrated Intel HW may have issues with it and usually runs 30fps on it. We should consider to enable it for HD 630 which works with 4K screens well.

      Like

      Reply

    1. Just to clarify, the purpose of disabling compositing is to boost performance in applications such as video games. It doesn’t imply that you should stop using hardware-accelerated rendering.

      Like

      Reply

      2. The main reason why you might want to disable compositing or unredirect a window is to ensure that the frame rate of your app is not capped by the window manager. This also means less work being done by the compositor, which is good in terms of power consumption and also latencies.

        Like

      3. FTR: AFAIK we’re only talking about the case when compositing is disabled altogether. Automatic fullscreen unredirect is disabled in FF because of tearing issues (`_NET_WM_BYPASS_COMPOSITOR` -> `FALSE`).

        Our main issue with completely non-composited desktops is that we’d have to reimplement our XShape logic for Webrender, i.e. in Rust code IIUC. We currently fall back to the legacy software renderer for menus in that case, but that code will go away eventually.

        X11 without compositing is thus a big exception – no other supported platform makes use of such tricks (XShape). So from the FF perspective it’s a quite annoying edge case 😦

        Like

      2. So yes, I tested Firefox 84.0.2, KDE and MATE on X.org/Intel and screen < 4K. WebRender is enabled by default on Gnome/X.org only, MATE and KDE use Basic compositor. So let's work to enable it there too.

        Like

  3. Thanks, Martin.

    I’m on KDE, Fedora 33. In the past, I tried to manually enable WebRender in the config, but had issues and reverted it.
    Now, I’m no longer sure which config options should be enabled/disabled. Is there a guide that could be followed?

    Like

    Reply

  4. I’ve tested it a couple of weeks ago and it uses tons of memory. I’ve seen others complaining as well.
    Without WebRenderer I have about 10 GBs of available memory at start up, as indicated by the free command.
    With WebRenderer enabled I had almost nothing and if I’m not mistaking the swap was also used a bit. Other than this, it wasn’t that bad.

    I’m using XFCE on Fedora 33, the GPU is Intel HD 4000 (i7-3770) and I have 32 GBs of RAM. If I remember correctly I set gfx.webrender.all=true in about:config to force it on video card.

    Like

    Reply

  6. Yeah, right, and, again, absolutely not work on supporting proprietary Nvidia.
    Instead of that Mozilla got us “Software Webrender” as replacement, which is honestly should be called “Shitware Shitrender”/
    I sorry for being harsh, but idea of replacing of somewhat accelerated OpenGL (which works for those who enabled it for years without any gamebreaking bugs) with completely unaccelerated, slow, sluggish Sotware Webrender is just insane.

    Like

    Reply

    1. I tested the SW WebRender on browser speed benchmark (https://browserbench.org/Speedometer2.0/) and it’s even faster than HW WebRender on my box. I think it depends on actual scenario, OTOH WebGL will be slower of course.

      As for NVIDIA, it’s difficult to support it. I spend three days figuring why it doesn’t work with EGL/transparent popups (https://bugzilla.mozilla.org/show_bug.cgi?id=1650583). And there are other issues line EGLStreams (missing dmabuf) and lack of documentation (I mean it’s difficult to find why it’s something broken with NVIDIA drivers) which leads to developers frustration and leaving NVIDIA behind or creating a minimal working scenario.

      Like

      Reply

  7. I’m puzzled as to why the firefox developers concern themselves with the context so much.
    OpenGL was invented so that applications don’t have to care what video card is being used.

    I know of the response “in theory, yes, but in practice…” and I’ll also reply to that in advance: for example, the KDE/plasma compositor has a menu that allows to choose OpenGL ES 2.0, OpenGL 3.1, OpenGL 3.3, OpenGL 4.5, etc.
    If there is a problem with the video card driver, let it be fixed there. The application is not the place to fix issues that do not stem from it!

    Like

    Reply

    1. The Gnome/Intel/AMD was chosen in a first batch because it’s known to work and Firefox developers have this setup, nothing more. For instance my laptop (provided by Red Hat) has Intel integrated GPU so I know it works on that.

      NVIDIA is known for issues (see https://bugzilla.mozilla.org/show_bug.cgi?id=1650583 or https://bugzilla.mozilla.org/show_bug.cgi?id=1663273) and it’s difficult and frustrating to debug closed sources drivers.

      Like

      Reply

      1. The point I mean to stress is that these days, application developers don’t concern themselves about who made the video card that provides the rendering: as a developer what you interface with is OpenGL/DirectX, but not Intel, AMD/ATI or Nvidia!

        And let the drivers be fixed; if they don’t implement OpenGL as per specification, it’s certainly a problem that stems from firefox. The sane approach here is it is to be solved in the driver, not in firefox.

        If the concerns about which video card is behind the OpenGL API are limited in scope to creating a list of which drivers work and which don’t, nevermind that, of course.
        But then the title is confusing – to get the story straight, what firefox is getting is more acceleration on platforms providing OpenGL, not “on Linux”. OpenGL exists on Windows, FreeBSD and others after all, right?

        Like

      2. Erratum: I meant to write, “if [the video drivers] don’t implement OpenGL as per specification, it’s certainly *not* a problem that stems from firefox”, although the typo was probably obvious

        Like

    2. ctk: While I generally agree with you, OpenGL support itself is actually a rather small problem here. AFAICS it’s way simpler to make a 3D-fullscreen (or windowed) game to work properly – in fact it’s just a subset of what happens in a modern browser. The main challenges are in things like windowing system integration (GLX/EGL), the windowing system (X11/Wayland), sandboxing (multi-process buffer sharing via e.g. DMABUF) etc.

      > The application is not the place to fix issues that do not stem from it!

      Right, but many people expect software to simly work – if Firefox, after an update, suddenly has glitches all over the place, many people will not just blame their driver vendor and carry on – they would switch to some other browser 😦
      This is much easier if the drivers are open source and thus we can help fixing them ourselves.

      Like

      Reply

  8. Hi Martin,

    Thanks for the hard work for us Firefox Linux users. This is really the substantial work for Firefox on Linux in as long as I can remember.

    I follow Firefox development quite closely, so sorry for peppering you with questions. I am genuinely really interested in your work here (as well as Robert, Jan and others of course).

    What’s the plan for other less commonly used desktops like MATE, Cinnamon, Budgie, XFCE and LXQT, etc? Do you think it is likely these will be enabled incrementally, or will these remain software webrender by default? In other words will webrender be enabled by default on all WM/DEs for approved drivers in the future? Or do you think only the most commonly used WM/DEs will be enabled by default on approved drivers?

    My second question is in relation to GLX/X11. Is EGL/X11 going to be flipped on by default? Will GLX/X11 support be removed?

    Third, what is the plan with non-compositing setups? Will these get hardware Webrender by default? I know there is that issue with re-implementing shaping in the gfx code.

    Finally, what is the plan for Nouveau and the proprietary Nvidia driver? I am on Linus’ side here in respect of Nvidia’s attitude to Linux development, but is the plan here to only enable software webrender by default in the near-term? Conversely, does it look like Nouveau support will be enabled by default?

    Thanks

    Like

    Reply

    1. Hej Alex, thanks for caring 🙂

      As to my knowledge:

      We want to ship WR by default, to all DEs, hopefully over the next couple of releases. The more feedback we get from people testing different DEs, the faster this will happen I guess 😉
      I personally wouldn’t expect a lot of DE specific driver bugs on mesa Intel/AMD these days, so the differences AFAIK come down to two things: is the DE always composited? And how does it handle CSD[1]? The easiest case is always composited in combination with our internal `CSD_SUPPORT_SYSTEM`. So Cinnamon would be an obvious next candidate (IIUC it’s actually just old Gnome). Once we figured out all issues with non-composited and `CSD_SUPPORT_CLIENT` (and `CSD_SUPPORT_NONE`), things should work everywhere.

      Concerning EGL/X11: yes, we’d like to flip that on everywhere over time and deprecate GLX sooner or later. The main blocker is currently the testing infrastructure, but there are also other areas that still need tackling. The EGL backend is already quite superior (DMABUF/hardware video decoding/partial damage/less glitches) and the difference will likely only get bigger.

      As to non-composited desktops: we had to work around a certain issue by falling back to the basic compositor for popups. But apparently it works fine with that, so yes, we’d like to enable WR (and EGL) by default for them as well. At some point the basic compositor will get dropped, but that probably still has time.
      Optimally people will slowly migrate to Wayland compositors, which *can* offer the same max performance (or even better) as non-composited X11 while not requiring odd legacy workarounds and being glitchy etc. I.e. Wayland was designed to make the distinction unnecessary. Or, if you like, the fact that we still have non-composited DEs is just a flaw of X11.

      As to Nvidia – yes for Nouveau, maybe for the prop. driver. If it turns out that things work just fine for people on the prop. driver, well, why not. But spending time trying to debug a blackbox is currently something I personally wouldn’t want to do, and apparently Martin feels the same.
      Help with Nouveau is very much appreciated, especially filing or even fixing bugs in mesa[2].

      Cheers

      1: https://searchfox.org/mozilla-central/source/widget/gtk/nsWindow.cpp#7855-7942
      2: https://gitlab.freedesktop.org/mesa/mesa/-/issues/

      Like

      Reply

  11. I got a used Thinkpad T480s with UHD Graphics 620 and I just can’t get VP9 HW decoding to work with Firefox on Fedora. I tried both intel-media-driver and libva-intel-driver. Firefox is firefox-89.0.2-2.fc34.x86_64. If I force VP9 on Youtube with enhanced-h264ify and then run firefox like so MOZ_ENABLE_WAYLAND=1 MOZ_LOG=”PlatformDecoderModule:5″ firefox 2>&1 | grep -E -i ‘vaapi|va-api’ I get the following errors:

    D/PlatformDecoderModule VA-API FFmpeg is disabled by platform
    D/PlatformDecoderModule DMABuf/VA-API is disabled.

    I’ve set media.ffmpeg.vaapi.enabled to true. If I force h264, HW decoding works, with a lot of logging. Any ideas? VP9 decoding works with mpv, for example.

    Like

    Reply

Leave a comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Design a site like this with WordPress.com
Get started