This patch makes it so that we avoid blocking all features with the
blocklist, and instead continue to allow the safe subset proscribed by
GfxInfoBase::OnlyAllowFeatureOnKnownConfig. Any feature allowed in an
unknown configuration should be allowed in a blanket blocklist entry,
unless we know for a fact that we need to also block them.
Differential Revision: https://phabricator.services.mozilla.com/D197963
With Intel HD Graphics 620(KabyLake), hardware video decoding with zero video copy causes stall during destroying video MFTDecoder.
Differential Revision: https://phabricator.services.mozilla.com/D179908
Gfx blocklist doesn't actually use the desktop environment filter so
remove that functionality. We can reintroduce it in the future if we
need it.
Differential Revision: https://phabricator.services.mozilla.com/D166090
WebRender is a mature feature. We should start blocking it on known bad
devices over allowlisting known good devices. This may enable WebRender
in a few more obscure places than we shipped before.
Differential Revision: https://phabricator.services.mozilla.com/D160120
WebRender is a mature feature. We should start blocking it on known bad
devices over allowlisting known good devices. This may enable WebRender
in a few more obscure places than we shipped before.
Differential Revision: https://phabricator.services.mozilla.com/D160120
A bug is not reported related to "zero copy hardware decoded video" on Windows. Zero video frame copy needs "reuse decoder device ". And it is already enabled on Nightly / Early Beta by Bug 1773714.
RadeonBlockNoVideoCopy is renamed to RadeonBlockZeroVideoCopy
Differential Revision: https://phabricator.services.mozilla.com/D152139
Avoid copying hardware decoded video is already enabled on intel GPU on nightly by Bug 1763280. This bug is for enabling it on nightly on another GPUs on Windows.
Blocked drivers are from chromium's "disable_dxgi_zero_copy_video" in gpu_driver_bug_list.json
Differential Revision: https://phabricator.services.mozilla.com/D145194
This is a follow-up for bug1760464, we observed more crashes from devices which we didn't added to the block list before.
Therefore, we decided to block all Haswell GPUs for VP8 HW decoding (Intel supports that sine Broadwell) and a certain version of Intel driver.
Differential Revision: https://phabricator.services.mozilla.com/D142360
Windows has different driver version semantics than other platforms. We
shouldn't pad the driver versions the same way on Linux/OSX/Android for
our blocklist rules and instead just take the numbers as given. This
really only impacted Linux since it had numerous blocklist rules which
depending on the vendor or Mesa driver versions.
Differential Revision: https://phabricator.services.mozilla.com/D138905
This ends up enabling hw-wr on nightly on gen6 which was left disabled
for testing sw-wr, but should otherwise have no (or at least limited)
impact.
Differential Revision: https://phabricator.services.mozilla.com/D130926
`swrast` is reported as fallback software driver. This happens with
unknown sw-drivers (e.g. zink on lavapipe), but also when `glxtest`
incorrectly detects software rendering. This can be confusing and
is basically always wrong - by now it even got removed from Mesa
and for years only has been used on niche setups.
Make this more clear by using "mesa/software-unknown" instead.
No functional change beyond reporting intended here.
Differential Revision: https://phabricator.services.mozilla.com/D126052
Since Software WebRender is the replacement for Basic compositor, we
should not allow generic blocklist rules which block all features to
block Software WebRender. This feature must work under all
configurations, including safe mode, so it doesn't make sense to allow
blocking it.
This does not however prevent rules specifically targeting SW-WR from
blocking/allowing it.
Differential Revision: https://phabricator.services.mozilla.com/D99834
This patch enables Software WebRender for all Linux users. If their
configuration is also allowlisted for (accelerated) WebRender, then they
will default to that over Software WebRender.
Differential Revision: https://phabricator.services.mozilla.com/D97156
By default, anything we do for one Sandy Bridge gpu
we should do for all of them. See bug 1678388 for an
example of how we screwed this up.
Differential Revision: https://phabricator.services.mozilla.com/D97649
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