moz://gfx newsletter #54

Hey all, Jim Mathies here, the new Mozilla Graphics Team manager. We haven’t had a Graphics Newsletter since July, so there’s lots to catch up on. TL/DR – We’re shipping our Rust based WebRender backend to a very wide audience as of Firefox 84. Read on for more detail on our progress.

WebRender Current Status

The release audience for WebRender has expanded quite a bit over the last six months. As a result we expect to achieve nearly 80% desktop coverage by the end of the year and have a goal of shipping to 100% of our user base by next summer. 

Operating System Support

MacOS – As of Firefox 84, we are shipping to all versions of MacOS including the latest Big Sur release.

Windows 10 – We are currently shipping to all versions of Windows 10.

Windows 8/8.1 – We are currently shipping to all versions of Windows 8.

Windows 7 – We are currently shipping to a subset of Windows 7 users. Users currently excluded are running versions of the operating system which have not received the first major platform update.  Prior to this update Windows 7 lacked features WebRender relies on for painting to a window managed by a separate process. We are working on adding a fallback mechanism that moves composition into the parent browser process to work around this. We hope to ship support for this fallback mechanism in Firefox 85.

Android – We are currently shipping to devices that leverage the Mali-G chipset, Pixel devices, and a majority of Adreno 5 and 6 devices. Mali-T GPUs are our next big release target. Once we get Mali-T support out the door, we’ll have achieved 70% coverage for our mobile user base.

Linux – We have a little announcement to make here, in Firefox 84 will ship with an accelerated WebRender backend for the first time ever to a subset of Linux users. The target cohort leverages X11, Gnome, and recent Mesa library versions. We plan to expand this rollout to more desktop configurations over time, stay tuned!

Qualified Hardware

A note about qualified hardware – we have the ability to restrict who received the new pipeline based on a combination of hardware parameters – GPU manufacturer, generation, driver versions, battery power, video refresh rate, dual monitor configurations, and even screen size. We leveraged these filters heavily during our initial rollout to target specific cohorts. Thankfully most of these filters are no longer in use as our target audience has expanded greatly over the last six months.

As of Firefox 83, we are shipping to a majority of nVidia and AMD GPUs, and to all Intel GPUs newer than Generation 6. We actually shipped to Generation 6 GPUs in 83 but had to back off when some users reported rendering glitches on Reddit. The fix for this issue landed in 85 and has since been uplifted to 84 for rollout to Release, bringing WebRender support to the vast majority of modern Intel chipsets in Firefox 84.

The remaining GPUs we plan to target include older Intel Generation 4.5 and 5, a batch of mobile specific ‘LP’ Intel chipsets, and various older AMD/ATI/nVidia chipsets that represent the long tail of compatible chipsets from these manufacturers.

If you’re curious to see if your device is qualified and running with the new pipeline, visit about:support in a tab and view the Graphics section for this information. 

The Long Tail

WebRender is an accelerated rendering backend. This means we leverage the power of your graphics hardware to speed getting pixels to the screen. Unfortunately there are some hardware configurations which will never be able to support this type of rendering pipeline. That’s a problem in that without 100% WebRender coverage for the Firefox user base, we’ll never be able to remove the old pipelining code these users leverage today. Our solution here involves a new fallback mechanism that performs rendering in software. Since WebRender currently supports an OpenGL based hardware backend, software fallback is essentially a software implementation of certain OpenGL ES3 features tailored for WebRender support. We’ve recently started testing software fallback in Nightly and are seeing better than expected performance. We’re not ready to ship this implementation yet but we’re getting closer. Once ready, software fallback will provide WebRender support to the ‘long tail’ of lower-end hardware, uncommon configurations, and users with specific issues like bad drivers.

Shipping software fallback will allow us to close the loop on 100% WebRender coverage, at which point the Graphics Team can move forward on new and interesting projects we’ve been itching to get too for a while now.

WebGPU

Independent of WebRender rollout we are continuing our work on Firefox’s WebGPU implementation  currently available for testing in Nightly builds.  The specification is on track to reach MVP status in the near future, after which it will go through a period of feedback and change on the road to the release of the final specification sometime in 2021.

Looking Beyond WebRender

WebRender development and shipping has taken a few years to accomplish. We’re finally at a point where the team is starting to think about what we’ll work on once we’ve shipped WebRender to our entire user population. There’s lots to do! An overall theme is currently emerging in our planning – Visual Quality and Performance! We’re investigating various opportunities to extend the WebRender pipeline deeper into Gecko’s layout engine, HDR features, improved color management, performance improvements for SVG and Canvas, and improvements in power consumption. We’ll post more about these projects in future posts, stay tuned!

Happy New Year from the Mozilla Graphics Team!

9 thoughts on “moz://gfx newsletter #54

  1. Great technical work, sloppy presentation to end users.
    With such a major change hitting release, that can make the difference between usable and unusable,
    why are there no toggles under Performance Options: WebRender / WebRender software-d3d11 white-screen-bug / WebRender software / D3D11/OGL Advanced Layers / D3D11/OGL / Basic?
    Maybe even stick a reason for entries being grayed out due to bad drivers or whatever.
    Heck, make Performance a section of it’s own under Options! Sell it better because it’s honestly amazing.

  2. Exposing low level technical details could be a good or bad thing, depending on the target audience. If Firefox aims to attract general public, I can understand why they want to hide details and automatically handle fallbacks. Otherwise user might be overwhelmed by unfamiliar information. Heck, Chrome has lots of cool technologies and Google never exposes remotely close enough details to user through chrome://flags comparing to Firefox.

    On the other hand, if one day Mozilla decides to completely give up general public and Firefox should only target power users, I bet the first thing they gonna (should) do is expose those important, user perceivable configs in options page. I don’t believe Mozilla will ever give up general public though.

    1. From 5 years olds to grandmas, everybody plays games and goes to game options and plays with render choices. It makes life easier for both the user, and the dev. Even my cat feels insulted by your user is dumb assumption.

      WebRender aims to offer smooth 60fps for the web.Well, where did I hear that before?

      It’s basically like a game engine now, with all that stems from it – higher/lower performance, higher/lower battery level, smooth/jerky/bugged/unable to run depending on the rendering path.

      Makes damn sense to have a GUI choice for it, there’s nothing outlandish with the suggestion.
      Specially when there is not really an automatic fallback, and even the power-user prefs are all over the place, unclear and constantly changing.

  3. Pardon my bluntness, but is it really worth the effort investing developer time to support Windows 7, an OS which hasn’t received security updates for nearly a year? I am not against Firefox running on Windows 7, although it encourages Windows 7 users to continue using an insecure OS, but to go great lengths to ensure WebRender also works on Windows 7 without platform update installed? Really?

  4. So, Linux+Nvidia+Proprietary will fall into “uncommon configuration” or “bad driver” category? Do you consider fact that deprecating “old and buggy” OpenGL backend in favor to Software Webrender actually makes browser SLOWER for those users?

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s