Out-of-process WebGL needs GfxInfo to exist in the composition
process (which is the GPU process if it exists and the parent process
otherwise). This patch enables the Linux version of that component in
the GPU process; the IPC currently used to give content processes copies
of the parent's GPU info is extended to also send it to the GPU process.
Differential Revision: https://phabricator.services.mozilla.com/D85443
FEATURE_FAILURE_D3D11_NEED_HWCOMP is one of the main reasons
people get the basic compositor. This will let us dig into
why we get FEATURE_FAILURE_D3D11_NEED_HWCOMP.
Differential Revision: https://phabricator.services.mozilla.com/D77554
There's no use case for stateful comparators, so they can be just plain
function pointers.
This is used in some hot places like CSS selector matching.
Differential Revision: https://phabricator.services.mozilla.com/D77084
This is similar to a change that landed directly into 74. We don't want to
roll-out to these users yet and we don't want to have to think about it every
release.
Differential Revision: https://phabricator.services.mozilla.com/D66453
--HG--
extra : moz-landing-system : lando
Now that GfxInfo supports allowlisting, we can port our existing
configuration in gfxPlatform to using allowlist rules. This will
greatly increase maintainability and certainty that the expected
devices are getting WebRender.
Differential Revision: https://phabricator.services.mozilla.com/D62325
--HG--
extra : moz-landing-system : lando
Now that GfxInfo supports allowlisting, we can port our existing
configuration in gfxPlatform to using allowlist rules. This will
greatly increase maintainability and certainty that the expected
devices are getting WebRender.
Differential Revision: https://phabricator.services.mozilla.com/D62325
--HG--
extra : moz-landing-system : lando
We would like to get to a world where we compare/store enums instead of
strings, and this is a step towards.
Differential Revision: https://phabricator.services.mozilla.com/D62503
--HG--
extra : moz-landing-system : lando
Currently the blocklist can block groups of devices, called a
DeviceFamily. However this only allows us to check specific IDs and not
ranges of device IDs like we do currently for the WebRender allowlist.
This patch allows a device family to now specify start and end values
for device IDs we want to match in the blocklist rule.
Differential Revision: https://phabricator.services.mozilla.com/D62324
--HG--
extra : moz-landing-system : lando
As part of the WebRender rollout, we have been only allowing users
meeting particular platform, battery and screen size requirements (among
others) to get WebRender by default. This patch adds support for battery
and screen size filters in the blocklist rules to allow us to control
that more easily. It also adds kludgey support for checking for recent
Windows 10 build numbers for allowlist purposes; implementing this the
proper way would require an implementation like driver version checks,
which are much more complicated than most of the rules.
Differential Revision: https://phabricator.services.mozilla.com/D62323
--HG--
extra : moz-landing-system : lando
The blocklist currently works by checking the current configuration
against a set of GfxDriverInfo rules. We stop searching as soon as we
find the first match, and return whatever status code that has.
This patch adds a second pass for features marked for allowing. The
current blocklisting rules will still apply as normal. However it will
then review the allowlist rules using the same logic. If we don't get
a match, then we block the feature otherwise we use the allow status
code given in the rule.
New status codes introduced as part of this patch are as follows:
DENIED - Did not match any rules on the allowlist.
ALLOW_ALWAYS - Same as STATUS_OK but passed the allowlist.
ALLOW_QUALIFIED - Same as ALLOW_ALWAYS but should be controlled by
our qualified preference for experimentation purposes.
Differential Revision: https://phabricator.services.mozilla.com/D62322
--HG--
extra : moz-landing-system : lando
Currently the blocklist can block groups of devices, called a
DeviceFamily. However this only allows us to check specific IDs and not
ranges of device IDs like we do currently for the WebRender allowlist.
This patch allows a device family to now specify start and end values
for device IDs we want to match in the blocklist rule.
Differential Revision: https://phabricator.services.mozilla.com/D62324
--HG--
extra : moz-landing-system : lando
As part of the WebRender rollout, we have been only allowing users
meeting particular platform, battery and screen size requirements (among
others) to get WebRender by default. This patch adds support for battery
and screen size filters in the blocklist rules to allow us to control
that more easily. It also adds kludgey support for checking for recent
Windows 10 build numbers for allowlist purposes; implementing this the
proper way would require an implementation like driver version checks,
which are much more complicated than most of the rules.
Differential Revision: https://phabricator.services.mozilla.com/D62323
--HG--
extra : moz-landing-system : lando
The blocklist currently works by checking the current configuration
against a set of GfxDriverInfo rules. We stop searching as soon as we
find the first match, and return whatever status code that has.
This patch adds a second pass for features marked for allowing. The
current blocklisting rules will still apply as normal. However it will
then review the allowlist rules using the same logic. If we don't get
a match, then we block the feature otherwise we use the allow status
code given in the rule.
New status codes introduced as part of this patch are as follows:
DENIED - Did not match any rules on the allowlist.
ALLOW_ALWAYS - Same as STATUS_OK but passed the allowlist.
ALLOW_QUALIFIED - Same as ALLOW_ALWAYS but should be controlled by
our qualified preference for experimentation purposes.
Differential Revision: https://phabricator.services.mozilla.com/D62322
--HG--
extra : moz-landing-system : lando
This patch also exposes the desktop environment and window protocol on
the gfx blocklist, allowing us more control over feature deployment.
This will help with the slow rollout of WebRender to release channels.
Differential Revision: https://phabricator.services.mozilla.com/D56563
--HG--
extra : moz-landing-system : lando