7

Firefox – we’re finally getting HW acceleration on Linux – Martin Stransky's Blo...

 3 years ago
source link: https://mastransky.wordpress.com/2021/01/10/firefox-were-finally-getting-hw-acceleration-on-linux/
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.

Firefox – we’re finally getting HW acceleration on Linux

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 [email protected].

Posted byMartin StranskyJanuary 10, 2021January 13, 2021Posted inFedoraTags:Firefox, OpenGL, Wayland, webrender, X11

Post navigation

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

  1. Hi, I guess that those Intel setups that are painted in green here [1] are as concerned as AMD ones ?
    Thanks

    [1] https://wiki.mozilla.org/Platform/GFX/WebRender_Where#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.

  2. It’s very surprising to see that WebRender will be enabled only on GNOME. If compositing is disabled in KWin, applications can still use OpenGL and Vulkan.

    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.

      1. Yes, I understand it. Unfortunately it leads to issues with transparency, like https://bugzilla.mozilla.org/show_bug.cgi?id=1479135 .
        Does the disabled compositing actually help when HW rasterization is used?

      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.

      3. 5da71984edb570ec3fc1c0fc02f52dfa?s=32&d=identicon&r=GRobert

        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 😦

    2. Hi Vlad, don’t worry, KDE is on the table, see https://bugzilla.mozilla.org/show_bug.cgi?id=1663273#c80
      Would be great to see more reports how Firefox works on KDE with WebRender enabled.

    3. Vlad, I’m looking at https://bugzilla.mozilla.org/show_bug.cgi?id=1675768 and I don’t see any mention of KDE/Gnome. That means I might be confused by https://bugzilla.mozilla.org/show_bug.cgi?id=1680505 which is Gnome/Wayland only. Can you check WebRender state on your Firefox installation?

      EDIT: I’ll try to check it later today when I have KDE workstation available.

      1. Well, I’ve been running Firefox in Plasma/Wayland with WebRender for months and it works beautifully 🙂

      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.

      3. 5da71984edb570ec3fc1c0fc02f52dfa?s=32&d=identicon&r=GRobert

        Vlad: concerning Wayland+WR on KDE, at least nightly/86 is broken/blocked by https://bugs.kde.org/show_bug.cgi?id=428499

        IIUC after your compositor rework (https://invent.kde.org/plasma/kwin/-/merge_requests/507) this should be easier to fix now – but then we’d still need to wait for older KWin to either get fixed or go away – or do version checks in FF, which would be unfortunate.

  3. f047a3b5528f6f187ac4ef1c7d81014a?s=32&d=identicon&r=GRajeesh

    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?

    1. You can create a new Firefox profile (see https://fedoraproject.org/wiki/How_to_debug_Firefox_problems?rd=Bug_info_Firefox#Create_a_new_profile) and you’ll get default values there. Check if WebRender is enabled at about:support.

      You can also go to about:config and type webrender there. All bold lines are changed from default setup. You can revert them to default values by the arrow icon.

  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.

    1. Can you report that a bugzilla.mozilla.org and attach stats from about:memory ? Also cc me in that bug.
      Thanks.

  5. d96a7a2b090645614274efb31719d6c5?s=32&d=identicon&r=GLucas A. W.

    I’m hopeful of seeing progress in development to improve the WR experience under the Xfce desktop environment.

  6. 555ab0c0cba6281364f7932ebc23d0dc?s=32&d=identicon&r=GRomani

    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.

    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.

  7. 4048f4b583df6173fc27e3fe8c7c5ae6?s=32&d=identicon&r=Gctk

    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!

    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.

      1. 4048f4b583df6173fc27e3fe8c7c5ae6?s=32&d=identicon&r=Gctk

        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?

      2. 4048f4b583df6173fc27e3fe8c7c5ae6?s=32&d=identicon&r=Gctk

        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

    2. 5da71984edb570ec3fc1c0fc02f52dfa?s=32&d=identicon&r=GRobert Mader

      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.

  8. 050c0496e10f53a97bb34d9474524a0e?s=32&d=identicon&r=GAlex

    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

    1. 5da71984edb570ec3fc1c0fc02f52dfa?s=32&d=identicon&r=GRobert

      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/

      1. 050c0496e10f53a97bb34d9474524a0e?s=32&d=identicon&r=GAlex

        Thanks for taking the time to reply to my questions Robert.

        Thanks for all your hard work!

Leave a Reply Cancel reply

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


report

Recommend

About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK