Closed Bug 1684090 Opened 4 years ago Closed 4 years ago

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

Categories

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

Firefox 84
x86
Linux
defect

Tracking

()

RESOLVED INVALID
Tracking Status
firefox-esr78 --- unaffected
firefox84 --- wontfix
firefox85 --- wontfix
firefox86 --- wontfix

People

(Reporter: bugzilla-f, Unassigned)

References

(Blocks 1 open bug, Regression)

Details

(Keywords: regression)

Attachments

(2 files)

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.

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!

Attached file about:support dump

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

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

Blocks: wr-linux
Severity: -- → S3
Has STR: --- → yes
Flags: needinfo?(bugzilla-f)
Keywords: regression
Priority: -- → P3
See Also: → 1684182

(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.

Flags: needinfo?(bugzilla-f)
Attached file glxinfo dump

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.
Status: NEW → RESOLVED
Closed: 4 years ago
Regressed by: 1677825
Resolution: --- → INVALID
Has Regression Range: --- → yes

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.

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.

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

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

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.

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).

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.

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: