1684090 - gfx.webrender.all == true, still WebRender stopped working between FF83 and FF84

Status: RESOLVED INVALID

(Core :: Graphics: WebRender, defect, P3)

Description

[Frank de Lange]

Somewhere between FF83 and FF84 - from what I can see upon release - WebRender ceased webrendering even though gfx.webrender.all is enabled and things did work on this - old, Thinkpad T42p - hardware. It still does not work on Nightly.

Comment 1

[Darkspirit (doesn't receive bug notification emails until AWS SES supports IPv6 DNS)]

Thanks for the report! Please set gfx.webrender.all to true, restart Firefox, open about:support, click on "Copy text to clipboard" and paste it here. Thanks!

Comment 2

[Frank de Lange]

Attachment: about:support dump

Comment 3

[Darkspirit (doesn't receive bug notification emails until AWS SES supports IPv6 DNS)]

Which desktop environment are you using?
Please also execute the $ glxinfo command and paste its output here.

Comment 4

[Andrew Osmond [:aosmond] (he/him)]

We don't seem to log enough info about the GL context initialization to know exactly what went wrong. I'll file a new bug about that. In the meantime, since this is a regression for you, would you be able to try running mozregression to pinpoint the build which introduced the problem? Something like:

mozregression --good 83 --bad 84 --pref gfx.webrender.all:true

should work.

https://mozilla.github.io/mozregression/quickstart.html

Comment 5

[Frank de Lange]

(In reply to Darkspirit from comment #3)

Which desktop environment are you using?
Please also execute the $ glxinfo command and paste its output here.

No "desktop environment", running Xmonad with some tools plus mate-settings-daemon for those bits which need it.

Comment 6

[Frank de Lange]

Attachment: glxinfo dump

Comment 7

[Darkspirit (doesn't receive bug notification emails until AWS SES supports IPv6 DNS)]

Thanks!

Vendor: X.Org R300 Project (0x1002)
Device: ATI RV350 (0x4e54)
Version: 20.2.4
Accelerated: yes
Video memory: 128MB
Unified memory: no
Preferred profile: compat (0x2)
Max core profile version: 0.0
Max compat profile version: 2.1
Max GLES1 profile version: 1.1
Max GLES[23] profile version: 2.0

https://www.techpowerup.com/gpu-specs/ati-rv350.g13

OpenGL 2.0

This configuration never supported WebRender. WebRender requires OpenGL 3.2 or GLES3.
gfx.webrender.all internally means layers.acceleration.force-enabled + gfx.webrender.enabled.

Before bug 1677825, Firefox was unable to use "WebRender" due to missing OpenGL 3.2 support, but made a fallback to using the deprecated "OpenGL" compositor. Now it simply falls back to "Basic" (software rendering). This is desired behavior: bug 1677825 comment 1

In case you were actually using WebRender, you must have used different hardware or Mesa's LIBGL_ALWAYS_SOFTWARE=1 environment variable to do OpenGL on the CPU instead of the GPU.

Your options:

• Set layers.acceleration.force-enabled to true and restart Firefox to keep using the deprecated OpenGL compositor as long it's available. It supports OpenGL 2.0.
• Join testing the experimental software GL backend for WebRender (gfx.webrender.all + gfx.webrender.software) using https://nightly.mozilla.org.

Comment 8

[Frank de Lange]

Well, as to whether I "was using WebRender" might be more of a play of words than a definite statement. I have been using FF (nightly) for a long time with gfx.webrender.all enabled which produced a definite performance boost from the start, even though there used to be rendering artefacts in the beginning (black borders around menus, etc). The problems with rendering artefacts were gradually resolved, things were shaping up well and FF outperformed Chromium and other Blink-based browsers on this hardware. All of that came to a halt when the thing suddenly fell back to the (abysmal) performance level experienced before I enabled gfx.webrender.all. If this is caused by an intentional change I'd suggest that change be made optional since "WebRender" by any name is still better than slow-as-molasses-render on older hardware.

As to rendering OpenGL in software, no, I have not had that enabled since it, again, leads to abysmal performance - these machines only have a single-core Pentium M after all.

May I suggest keeping the fallback alive, even if hidden behind some gfx.webrender.there_be_dragons switch? It would provide an answer to the question "To Firefox or not to Firefox" on this class of hardware.

Comment 9

[Frank de Lange]

I just tried the suggested options - layers.acceleration.force-enabled and gfx.webrender.all + gfx.webrender.software - neither of which provide an adequate level of performance. I'll do a check with FF83 to see what it reports about the used renderer, the performance difference between that and the current nightly is day and night, with nightly being aptly named.

Comment 10

[github-f]

Yup, FF83 reports that it using the "OpenGL" renderer even with gfx.webrender.all == true.

The real question now becomes how to get this performance level in current nightly as it makes the difference between a useable browser and using a different browser. That, I assume, is a question for another part of Bugzilla?

Compositing: OpenGL
Diagnostics
AzureCanvasBackend: skia
AzureContentBackend: skia
AzureFallbackCanvasBackend: none
CairoUseXRender: 0
CMSOutputProfile: Empty profile data
Display0: 1600x1200 default
DisplayCount: 1
Decision Log
HW_COMPOSITING:
available by default
OPENGL_COMPOSITING:
available by default
WEBRENDER:
available by default
force_enabled by user: Force enabled by envvar
disabled by env: Not qualified
unavailable by runtime: WebRender initialization failed
WEBRENDER_QUALIFIED:
available by default
denied by env: Not on allowlist
WEBRENDER_COMPOSITOR:
disabled by default: Disabled by default
WEBRENDER_PARTIAL:
available by default
WEBRENDER_ANGLE:
available by default
unavailable by env: OS not supported
WEBRENDER_DCOMP_PRESENT:
available by default
disabled by user: User disabled via pref
unavailable by env: Requires Windows 10 or later
unavailable by runtime: Requires ANGLE
OMTP:
available by default
broken by runtime: OMTP is not supported on 32-bit with <= 2 cores
WEBGPU:
disabled by default: Disabled by default
blocked by runtime: WebGPU can only be enabled in nightly

Comment 11

[Andrew Osmond [:aosmond] (he/him)]

I would expect setting layers.acceleration.force-enabled to true and gfx.webrender.force-disabled to true will get you OpenGL compositing on 84.

Comment 12

[Frank de Lange]

I'm doing my testing on current nightly (86.0a1 (2020-12-22) (32-bit)), this is where OpenGL does not work. It might work in FF84 but I'm looking for a way to make sure it keeps working in the future.

Comment 13

[Andrew Osmond [:aosmond] (he/him)]

I'm unaware offhand of a change that broke OpenGL, and I can't reproduce your problem. You can use mozregression to isolate the change however:

mozregression --good 83 --pref gfx.webrender.force-disabled:true layers.acceleration.force-enabled:true -a about:support

and check to see if you got OpenGL or not (OpenGL = good build, no OpenGL = bad build).

Comment 14

[Darkspirit (doesn't receive bug notification emails until AWS SES supports IPv6 DNS)]

Firefox 84 and Nightly: Please make sure you reset all webrender prefs to their default, set gfx.webrender.force-disabled to true, set layers.acceleration.force-enabled to true and restart Firefox.