Also ship to release if the Intel driver is 21.20.16.4550 or later.
Add Intel Gen 6 GT1 (Sandybridge) and allow it to ride to early beta.
Differential Revision: https://phabricator.services.mozilla.com/D89613
This patch adds detection for XWayland, as that is sometimes an
important distinction when debugging WebRender bugs. For all intents and
purposes, it should work the same as X11, but sometimes does not.
This patch also fixes the desktop environment detection for a few corner
cases. Budgie, in particular, claims to be a GNOME variant, which is not
correct for our purposes, and DWM wasn't detected at all.
Differential Revision: https://phabricator.services.mozilla.com/D83876
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
AMD does not release any graphics cards under the vendor ID 0x1022. That
appears to be reserved for their non-graphics hardware. Instead they
have chosen to continue releasing graphics hardware under the ATI vendor
ID 0x1002. This patch removes all of the AMD ID rules and replaces them,
if applicable, with ATI ID rules. This has meant that sometimes we
failed to block things in the past that we expected to.
Differential Revision: https://phabricator.services.mozilla.com/D64443
--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
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
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
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
Investigation showed that on this platform the texture unit state becomes
corrupted whenever we set the non-identity swizzling (getting garbage from textureSize()).
Given no easy workaround, we disable swizzling for this GPU family on Mac, for now.
Differential Revision: https://phabricator.services.mozilla.com/D41274
--HG--
extra : moz-landing-system : lando
This reunifies the behaviour changed in bug 1294232 to ensure that the
vendor ID of GfxInfo is the same between graphics hardware. Vendor ID
should always represent Intel, Nvidia, ATI, etc such that callers can
reason about the performance characteristics without being exposed to
the driver implementation for that platform. Now we split off the more
detailed driver information into the "driver vendor" which will contain
more information, such as what implementation is being used (e.g.
mesa/i965 for modern Intel graphics cards). This field is exposed to the
blocklist and will be useful for allowing different rules for different
driver implementations.
We also now provide a default implementation for
GfxInfoBase::FindMonitors for platforms missing support. This will just
list the primary screen size used without listing secondary monitors,
refresh rate, and such.
Differential Revision: https://phabricator.services.mozilla.com/D29471
This reunifies the behaviour changed in bug 1294232 to ensure that the
vendor ID of GfxInfo is the same between graphics hardware. Vendor ID
should always represent Intel, Nvidia, ATI, etc such that callers can
reason about the performance characteristics without being exposed to
the driver implementation for that platform. Now we split off the more
detailed driver information into the "driver vendor" which will contain
more information, such as what implementation is being used (e.g.
mesa/i965 for modern Intel graphics cards). This field is exposed to the
blocklist and will be useful for allowing different rules for different
driver implementations.
We also now provide a default implementation for
GfxInfoBase::FindMonitors for platforms missing support. This will just
list the primary screen size used without listing secondary monitors,
refresh rate, and such.
Differential Revision: https://phabricator.services.mozilla.com/D29471
This reunifies the behaviour changed in bug 1294232 to ensure that the
vendor ID of GfxInfo is the same between graphics hardware. Vendor ID
should always represent Intel, Nvidia, ATI, etc such that callers can
reason about the performance characteristics without being exposed to
the driver implementation for that platform. Now we split off the more
detailed driver information into the "driver vendor" which will contain
more information, such as what implementation is being used (e.g.
mesa/i965 for modern Intel graphics cards). This field is exposed to the
blocklist and will be useful for allowing different rules for different
driver implementations.
We also now provide a default implementation for
GfxInfoBase::FindMonitors for platforms missing support. This will just
list the primary screen size used without listing secondary monitors,
refresh rate, and such.
Differential Revision: https://phabricator.services.mozilla.com/D29471
New Windows devices are coming out that have GPU Device ID strings of
the form
ACPI\VEN_QCOM&DEV_007C&SUBSYS_CLS08998&REV_007C
as reported in the bug description. Since the VEN_ ID is not numeric,
this change interprets the QCOM string so that it can be whitelisted
and then whitelists it.
MozReview-Commit-ID: 2ABRzvHKn6v
--HG--
extra : rebase_source : 6951d3bfc060abc298c93dd31db07715d6857cc5