Hook up blocklist and prefs for webrender on Metal ANGLE
Categories
(Core :: Graphics, task)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox154 | --- | fixed |
People
(Reporter: jnicol, Assigned: jnicol)
References
(Blocks 1 open bug)
Details
(Whiteboard: [fxpe])
Attachments
(3 files)
Similar to bug 2053067 but for webrender instead of WebGL. We want a pref to be able to enable/disable this, and a blocklist entry.
The existing gfx.webrender.force-angle is already used to enable or disable webrender ANGLE. But it also indicates whether webrender is allowed to run without ANGLE, or whether webrender should be disabled altogether if ANGLE is disabled. We should separate these two meanings: add a new pref gfx.webrender.enable-angle for the former, and keep force-angle meaning the latter.
We should add a separate blocklist entry specifically for webrender on Metal ANGLE, rather than reusing the WebGL-specific one added in bug 2053067. It may be useful to be able to blocklist WebGL and webrender on Metal ANGLE independently.
Like in bug 2053067, we'll add specific blocklist blocks for pre macOS 12 and for devices with multiple GPUs. Then a universal block (for now) since we're not yet even building or shipping the required ANGLE libraries.
Updated•1 month ago
|
| Assignee | ||
Comment 1•1 month ago
|
||
This pref allows running webrender on ANGLE in the parent process. This
used to be blocked by default because we were, at the time, unable to
create a separate EGL displays for the compositor and webgl contexts.
This caused issues when both WebGL and webrender were instantiated in
the parent process.
This is no longer an issue, and the pref has been true for a long
time. This patch therefore removes it, ever so slightly simplifying
webrender configuration.
Note that this uncovers a pre-existing issue in the gfxConfigManager
tests. The tests left mWrForceAngleNoGPUProcess set as false despite the
fact the pref is true in real life. They therefore expected ANGLE and
consequently webrender to be disabled when the GPU process was disabled,
when in reality webrender and ANGLE will be enabled for users even when
the GPU process is disabled. The test expectations are now updated to
match what users will actually see.
Updated•1 month ago
|
| Assignee | ||
Comment 2•1 month ago
|
||
The existing pref gfx.webrender.force-angle previously had two effects:
-
Whether ANGLE should be enabled for webrender.
-
Whether webrender requires ANGLE, and should be disabled
altogether if ANGLE is unavailable.
This patch adds a new pref gfx.webrender.enable-angle to determine
number 1, and the existing "force-angle" pref continues to determine
number 2.
| Assignee | ||
Comment 3•1 month ago
|
||
Adds a new blocklist feature WEBRENDER_ANGLE_METAL which determines
whether we are allowed to run webrender on ANGLE's Metal backend on
macOS. The existing WEBRENDER_ANGLE gfxFeature now depends on either
D3D11_HW_ANGLE or WEBRENDER_METAL_ANGLE, on Windows and macOS
respectively.
WEBRENDER_ANGLE_METAL is currently universally blocked, as we don't yet
build or ship the required ANGLE libraries on macOS. There are also
specific blocks for macOS versions earlier than 12, and for devices with
mutliple GPUs, as they will require additional work to unblock following
the initial rollout.
Lastly, universally set the UseWebRenderANGLE gfxVar based on the
WEBRENDER_ANGLE gfxFeature status. This ensures the gfxVar will be set
true on macOS once the required blocklist and prefs are enabled. On
platforms without an ANGLE backend feature the WEBRENDER_ANGLE feature
will always be disabled anyway.
Comment 5•1 month ago
|
||
| bugherder | ||
https://hg.mozilla.org/mozilla-central/rev/0bb1321d54d1
https://hg.mozilla.org/mozilla-central/rev/199b0304bb14
https://hg.mozilla.org/mozilla-central/rev/5cfc4fbc67f0
Updated•1 month ago
|
Description
•