This patch just adds the plumbing to allow for baked in blocklist rules
or the downloadable blocklist to prevent certain configurations from
getting WebGPU. It does not add any rules.
It also changes us from allowing WebGPU only in nightly, including
tests, to not release and not beta. This allows try to run the WebGPU
tests as expected, since even try builds forked from mozilla-central are
not considered nightly builds by CI (or so it seems).
Differential Revision: https://phabricator.services.mozilla.com/D141682
This patch adds several new prefs to control what happens with
OffscreenCanvas. gfx.offscreencanvas.enabled works as it did before.
- gfx.offscreencanvas.domain-enabled: Enables OffscreenCanvas for
domains on the allowlist.
- gfx.offscreencanvas.domain-allowlist: Comma separated allowlist
which controls which domains can access the OffscreenCanvas constructor
and HTMLCanvasElement.transferControlToOffscreen.
- dom.workers.requestAnimation: Controls whether or not
request/cancelAnimationFrame are accessible from dedicated workers.
Ideally this would have used the same decision process as
OffscreenCanvas but there were unrelated build/runtime issues around
using a Func directive with DedicatedWorkerGlobalScope.
Differential Revision: https://phabricator.services.mozilla.com/D135928
If GL is threadsafe, we can run on the compositor thread. This appears
to have performance benefits, possibly because the renderer thread is
too busy. If GL is not threadsafe, we must run the WebGL OOP instances
on the renderer thread.
At the time of writing, only the nouveau drivers on Linux are considered
to be not threadsafe, so most users will see WebGL running on the
compositor thread. This patch also adds prefers to override the
blocklist to either assume GL is threadsafe
(webgl.threadsafe-gl.force-enabled) and not threadsafe
(webgl.threadsafe-gl.force-disabled).
Differential Revision: https://phabricator.services.mozilla.com/D130634
The default size on most platforms is 256*256 which corresponds to the default blob tile size. I didn't check on android so I set it to 512*512 above which we never batch the upload so that the behavior is unchanged, but I suspect that a smaller threshold like 256*256 would also work better there.
On Windows with heavy blob image workloads, not batching gives a 20%-30% improvement to the time spent in update_texture_cache.
Differential Revision: https://phabricator.services.mozilla.com/D129516
With Feature::WINDOW_OCCLUSION, about:support could show if window occlusion is enabled. And Feature::WINDOW_OCCLUSION could be used to override windows occlusion setting. It could be used for Bug 1733955.
Differential Revision: https://phabricator.services.mozilla.com/D127752
Right now adding a dynamic pref for webrender involves plumbing in gfxPlatform, gfxVars, CompositBridgeParent, WebRenderBridgeParent, WebRenderAPI, the bindings, and then messaging the pref change to the right thread in WebRender.
That's quite a bit time consuming for something we tend to do for multiple things.
We already have a pretty good system for boolean debug prefs where the pref only needs to be listed in gfxPlatform and in the DebugPref enum of webrender_api/lib.rs, which has led us to use it for non-debug purposes.
This patch adds a system similar to the DebugFlags with values passed in a bitfield to be able to use gfxVars. In WebRender the parameters are key-value pairs which flow through the pipeline so that any component can react to them. A followup will add integer parameters.
The patch also moves a few prefs to this system and adds a pref to use PBO uploads.
Differential Revision: https://phabricator.services.mozilla.com/D126100
The prefs name is gfx.webrender.blob-tile-size and can be changed at runtime.
It changes the behavior of a wrench reftest that was ensuring that we don't crash with unreasonable tile sizes. The new behavior (sanitizing the tile size) means we can render the image while we would previously skip it.
Differential Revision: https://phabricator.services.mozilla.com/D124789
MOZ_WEBRENDER=0 now does nothing -- you will either get HW-WR or SW-WR
depending on the platform configuration. The pref
gfx.webrender.force-legacy-layers is removed. This leaves no
configuration option to disable WebRender.
MOZ_WEBRENDER=1 will continue to force WR on, which will ensure in CI we
get HW-WR unless gfx.webrender.software is true.
Differential Revision: https://phabricator.services.mozilla.com/D122474
MOZ_WEBRENDER=0 now does nothing -- you will either get HW-WR or SW-WR
depending on the platform configuration. The pref
gfx.webrender.force-legacy-layers is removed. This leaves no
configuration option to disable WebRender.
MOZ_WEBRENDER=1 will continue to force WR on, which will ensure in CI we
get HW-WR unless gfx.webrender.software is true.
Differential Revision: https://phabricator.services.mozilla.com/D122474
Reject software rasterizers on Linux (except Software WebRender) when
trying to create full WebRender, unless WebRender was force enabled.
Differential Revision: https://phabricator.services.mozilla.com/D117534
When trying to create a GLContextEGL or GLContextGLX, we should check to
see what our display is backed by. If using a software driver, we should
fail to create the context for WebRender, so that it can fallback to
Software WebRender.
Differential Revision: https://phabricator.services.mozilla.com/D117473
We still need the blocklist to control rollout on Android, but on
desktop, we should be shipping Software WebRender to all users, except
those in safe mode or whom have explicitly disabled WebRender.
Differential Revision: https://phabricator.services.mozilla.com/D117088
We still need the blocklist to control rollout on Android, but on
desktop, we should be shipping Software WebRender to all users, except
those in safe mode or whom have explicitly disabled WebRender.
Differential Revision: https://phabricator.services.mozilla.com/D117088
force-disable was originally override other enabling prefs (gfx.webrender.enabled, gfx.webrender.all, and gfx.webrender.all.qualified). But it does not override gfx.webrender.software, since gfx.webrender.software is used for testing in CI.
Differential Revision: https://phabricator.services.mozilla.com/D116439
If a user is able to get D3D11, and Software WebRender hasn't been
forced on (either by the Fission experiment or our pref), then we prefer
D3D11 in late beta and release. This will allow users who start with
D3D11 in the GPU process, to fallback to Software WebRender in the GPU
process.
Differential Revision: https://phabricator.services.mozilla.com/D114286
In bug 1680087 we disabled webrender's partial present feature on
Mali-T6xx and T7xx devices due to rendering issues caused by a buggy
implementation in the driver. We have now seen reports of the same
issue on a Mali-T8xx device.
This patch expands the block to include all Mali-Txxx devices. As a
follow up we should make this dependent on the driver version, so
that users with working drivers can take advantage of the feature.
Differential Revision: https://phabricator.services.mozilla.com/D113477
This patch leaves DirectComposition turned on by default on nightly but
disables DirectComposition on beta/release due to known rendering
artifact issues.
Differential Revision: https://phabricator.services.mozilla.com/D111965
Loading cached shaders with glProgramBinary fails consistently for all
but the most trivial of our shaders on Adreno 3xx, so caching and
attempting to load them is a waste of time. Chromium and other
projects also appear to have disabled their shader caches on Adreno
3xx due to bugs.
This patch moves the gfx.webrender.program-binary-disk pref
declaration from all.js to StaticPrefList.yaml. Rather than directly
using the value of the pref to decide whether to create the shader
cache, we now initialize a Feature in gfxConfigManager with a default
value from the pref and then configure it from the blocklist. On
Android we block the feature on Adreno 3xx devices. The pref remains
true by default on Android and Windows, and false by default on Linux
and Macos.
Differential Revision: https://phabricator.services.mozilla.com/D111427
Fission without WebRender is an unsupported configuration and enrolls
users based on their compositor. However because of our own rollout of
WebRender, a user might start in early beta with WebRender and lose it
in late beta, while they remain enrolled in the Fission experiment.
Also, a user could lose WebRender because of crashes or device reset,
and we may fall back to Basic.
This patch forces Software WebRender as available (but does not override
Hardware WebRender) if Fission is enabled for users enrolled in the
Fission experiment. It also prevents fallback to Basic layers when
disabling acceleration due to crashes and runtime errors, so the user
will be stuck with Software WebRender at a minimum. It also enables
Software WebRender for Windows popups with transparency.
Differential Revision: https://phabricator.services.mozilla.com/D107661
Windows users on Basic / without D3D11 compositing, with the GPU
process, and with small screens may get Software WebRender on the
late beta and release channel.
Differential Revision: https://phabricator.services.mozilla.com/D107920
Fission without WebRender is an unsupported configuration and enrolls
users based on their compositor. However because of our own rollout of
WebRender, a user might start in early beta with WebRender and lose it
in late beta, while they remain enrolled in the Fission experiment.
Also, a user could lose WebRender because of crashes or device reset,
and we may fall back to Basic.
This patch forces Software WebRender as available (but does not override
Hardware WebRender) if Fission is enabled. It also prevents fallback to
Basic layers when disabling acceleration due to crashes and runtime
errors, so the user will be stuck with Software WebRender at a minimum.
It also enables Software WebRender for Windows popups with transparency.
Differential Revision: https://phabricator.services.mozilla.com/D107661