Software Fallback for Web Render Dog Fooding Phase

Jim Mathies

unread,

Oct 27, 2020, 4:18:20 PM10/27/20

to

Hey all,

tl/dr; Help us by testing WebRender software fallback, and file bugs against the meta 'sw-wr-dogfood'.

WebRender Software Fallback is a project involving the development of a software (vs. accelerated) backend for WebRender. Its purpose is to replace the old graphics pipelines on platforms where we suffer from various stability issues revolving around driver issues, missing rendering features, and as a target for the long tail of hardware that doesn't show up in our release population in significant numbers. We plan to ship this new backend to targeted devices and drivers on various platforms in 2021.

Today we are kicking off a dog fooding phase to accumulate bug reports for issues and Firefox profiler profiles for performance issues. If you're interested in helping please continue reading!

If you are currently running Nightly, please try temporarily enabling software fallback and comparing it to your regular browsing experience.

During testing if you -

1) Run into stability issues, we'd appreciate bug reports with crash signatures.

2) Notice painting glitches or errors, we'd appreciate bug reports with screenshots.

3) Detect noticeable performance issues with page interaction and scrolling that normally don't occur, we'd appreciate bug reports with Firefox profiles.

We're interested in reports from users who currently qualify for one of the WebRender accelerated backends as well as from users who do not. If your device currently defaults to one of the older graphics pipelines (in particular, Basic Layers) we're very interested in hearing about your experience with software fallback. You can identify your default backend by checking about:support's Graphics section.

To switch to using software fallback, flip the following prefs -

gfx.webrender.all = true
gfx.webrender.software = true

The first pref change ensures WebRender is enabled. The second pref switches WebRender to use the software fallback backend.

Once you have finished testing, reset both of these preferences to their defaults to reset to your default graphics backend. We'd like to ask that you run with software fallback for as long as you are comfortable using it and report any issues you come across via Bugzilla. File bugs under Core : Graphics : WebRender [1] and please block any bugs filed against the meta bug 'sw-wr-dogfood' [2] so that the Graphics team can find and triage them.

Thanks for the help!
Platform Graphics Team

[1] https://bugzilla.mozilla.org/enter_bug.cgi?product=Core&component=Graphics%3A%20WebRender
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=sw-wr-dogfood

Botond Ballo

unread,

Oct 27, 2020, 4:38:32 PM10/27/20

to Jim Mathies, dev-platform

On Tue, Oct 27, 2020 at 4:20 PM Jim Mathies <jmat...@mozilla.com> wrote:
> To switch to using software fallback, flip the following prefs -
>
> gfx.webrender.all = true
> gfx.webrender.software = true

Are there plans to make the second pref show up in about:config? In
today's nightly, it looks like it needs to be added manually.

Thanks,
Botond

Jim Mathies

unread,

Oct 27, 2020, 4:43:41 PM10/27/20

to

Yep, sorry about that. We'll get a default landed this week. For the time being you'll have to create that pref manually.

Regards,
Jim

Jeff Muizelaar

unread,

Oct 27, 2020, 4:46:35 PM10/27/20

to Jim Mathies, Mozilla

I actually put the pref in the landing queue earlier today. It's just
waiting for the tree to open.
https://bugzilla.mozilla.org/show_bug.cgi?id=1673715

-Jeff

> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform

Gabriele Svelto

unread,

Oct 28, 2020, 4:02:14 AM10/28/20

to Jim Mathies, dev-pl...@lists.mozilla.org

On 27/10/20 21:18, Jim Mathies wrote:
> 3) Detect noticeable performance issues with page interaction and scrolling that normally don't occur, we'd appreciate bug reports with Firefox profiles.

Is the software fallback expected to use all available CPU cores/threads
for rendering? I enabled it and played around a bit on Google Maps.
Performance is visibly lower than with hardware support - something I
did expect - but I could see only one core being loaded at 100%, the
rest were sitting idle. That surprised me because most software
fallbacks (e.g. LLVMpipe on Mesa) tend to use all available CPU resources.

So I was wondering if this was a deliberate choice (to conserve power on
laptops maybe?) or if I should file a bug.

Gabriele

OpenPGP_signature

Jeff Muizelaar

unread,

Oct 28, 2020, 8:50:06 AM10/28/20

to Gabriele Svelto, Jim Mathies, Mozilla

It is not expected to use all cores. We deliberately designed it this
way because the target audience tends to have a low core count and
this kept the complexity down. It also keeps the performance on high
core count machines more representative of performance on low core
count machines.

-Jeff

On Wed, Oct 28, 2020 at 4:02 AM Gabriele Svelto <gsv...@mozilla.com> wrote:
>
> On 27/10/20 21:18, Jim Mathies wrote:

> > 3) Detect noticeable performance issues with page interaction and scrolling that normally don't occur, we'd appreciate bug reports with Firefox profiles.
>

> Is the software fallback expected to use all available CPU cores/threads
> for rendering? I enabled it and played around a bit on Google Maps.
> Performance is visibly lower than with hardware support - something I
> did expect - but I could see only one core being loaded at 100%, the
> rest were sitting idle. That surprised me because most software
> fallbacks (e.g. LLVMpipe on Mesa) tend to use all available CPU resources.
>
> So I was wondering if this was a deliberate choice (to conserve power on
> laptops maybe?) or if I should file a bug.
>
> Gabriele

Jeff Muizelaar

unread,

Oct 30, 2020, 4:25:27 PM10/30/20

to Jim Mathies, Mozilla

Note: there was a major performance regression that happened in
https://bugzilla.mozilla.org/show_bug.cgi?id=1642308. It is being
backed out, but any testing done on 20201030034830 until the next
nightly isn't going to be useful.

-Jeff

On Tue, Oct 27, 2020 at 4:20 PM Jim Mathies <jmat...@mozilla.com> wrote:
>

Jeff Muizelaar

unread,

Oct 30, 2020, 8:21:38 PM10/30/20

to Jim Mathies, Mozilla

The new nightly (20201030213850) with this fixed is out.

-Jeff

On Fri, Oct 30, 2020 at 4:25 PM Jeff Muizelaar <jmuiz...@mozilla.com> wrote:
>
> Note: there was a major performance regression that happened in
> https://bugzilla.mozilla.org/show_bug.cgi?id=1642308. It is being
> backed out, but any testing done on 20201030034830 until the next
> nightly isn't going to be useful.
>
> -Jeff
>
> On Tue, Oct 27, 2020 at 4:20 PM Jim Mathies <jmat...@mozilla.com> wrote:
> >