Thanks to the previous patch in this series we can now play video
using the non-essl3 GL_OES_EGL_image_external extension, therefore we
no longer require the essl3 version.
It is assumed that all android devices support
GL_OES_EGL_image_external (non-essl3). Even if that is not the case,
webrender is no worse off than layers in that regard.
Differential Revision: https://phabricator.services.mozilla.com/D108909
On some Mali devices we have encountered driver crashes caused by
calling textureSize(samplerExternalOES) in a shader without also
potentially sampling from the texture in the shader. ARM's suggested
workaround was to trick the driver in to thinking that the texture may
be sampled from (ie by sampling in a branch which is never dynamically
taken).
This is done by checking the value of a dummy uniform, and sampling
the texture if the value is non-default. Using a constant expression
did not work because the compiler would optimize the condition (and
therefore the sample) away.
Also re-enable webrender on Mali-72 and G76 devices, as it was blocked
due to this bug.
Differential Revision: https://phabricator.services.mozilla.com/D105493
Note that quite a few Mali-Txxx devices still won't get webrender, due
to lack of GL_OES_EGL_image_external_essl3 support. Bug 1507074 tracks
lifting this requirement.
Depends on D105338
Differential Revision: https://phabricator.services.mozilla.com/D105339
Webrender has been enabled for most Adreno 5xx and 6xx devices for a
while now, but 505 and 506 were held back due to bug 1609191. We were
seeing a moderate number of crashes during what we suspected was
shader compilation.
The crashes on 505 and 506 have all but disappeared. Additionally,
after shipping to the wider release audience we saw the same crashes
on other 5xx devices, not just 505 and 506, but the numbers were never
so high as to be worrying. So we are safe to ship to 505 and 506 as
well.
Depends on D105337
Differential Revision: https://phabricator.services.mozilla.com/D105338
In bug 1688017 we blocked webrender on Mali-G76 devices due to reports
of crashes when playing video. Based on more reports by users and
further investigation of the crash data, it appears that Mali-G72 GPUs
are also affected by the same bug, but only on Android 11 (for both
GPUs). Crashes on other Mali GPUs and earlier android versions do
exist, but in much lower numbers.
Update the block to include G72 as well as G76, but only for Android
11.
Differential Revision: https://phabricator.services.mozilla.com/D105047
Webrender's pre-optimized shaders result in completely broken
rendering on a Huawei MediaPad M2 (Mali-T628). As a precaution,
disable optimized shaders on all Mali-T6xx devices.
Differential Revision: https://phabricator.services.mozilla.com/D104752
Webrender's pre-optimized shaders result in completely broken
rendering on a Huawei MediaPad M2 (Mali-T628). As a precaution,
disable optimized shaders on all Mali-T6xx devices.
Differential Revision: https://phabricator.services.mozilla.com/D104752
Webrender's pre-optimized shaders result in completely broken
rendering on a Huawei MediaPad M2 (Mali-T628). As a precaution,
disable optimized shaders on all Mali-T6xx devices.
Differential Revision: https://phabricator.services.mozilla.com/D104752
Currently webrender requires the extension
GL_OES_EGL_image_external_essl3 to render video. There exist some
older GLES 3 devices which do not support this extension, and
attempting to render video on these devices results in a shader
compilation error and falling back to OpenGL layers.
In bug 1507074 we will implement a long term solution for such
devices, but in the meantime block webrender on devices which do not
support this extension.
Differential Revision: https://phabricator.services.mozilla.com/D104669
Currently webrender requires the extension
GL_OES_EGL_image_external_essl3 to render video. There exist some
older GLES 3 devices which do not support this extension, and
attempting to render video on these devices results in a shader
compilation error and falling back to OpenGL layers.
In bug 1507074 we will implement a long term solution for such
devices, but in the meantime block webrender on devices which do not
support this extension.
Differential Revision: https://phabricator.services.mozilla.com/D104669
A user reported completely broken rendering on their Mali-G31 device,
starting when webrender was enabled. Block webrender on Mali-G31
devices until the cause has been identified and fixed.
Differential Revision: https://phabricator.services.mozilla.com/D103748
As we make the transition to using EGL over GLX, we will need our
detection code to be sufficient without EGL to determine the device in
use. This patch makes us always use the EGL testing code over the GLX
testing code, regardless of the pref/envvar setting.
At the very least, we need to know the vendor ID of the device in use.
We can determine this if there is only one GPU on the PCI list, if we
get a driver name from Mesa, or if it is a proprietary driver (i.e.
NVIDIA) which includes its name in the vendor ID. If we know the vendor
ID, we can usually derive the device ID from the PCI list.
We now also track which path glxtest took. If we successfully did the
test via EGL, then we will allow the pref/envvar to use EGL instead of
GLX. If the test reverted to GLX, then it will use GLX regardless of the
pref/envvar. This is necessary because we need to know if the libraries
are available or not -- some systems may be missing one or the other.
Differential Revision: https://phabricator.services.mozilla.com/D102933
As we make the transition to using EGL over GLX, we will need our
detection code to be sufficient without EGL to determine the device in
use. This patch makes us always use the EGL testing code over the GLX
testing code, regardless of the pref/envvar setting.
At the very least, we need to know the vendor ID of the device in use.
We can determine this if there is only one GPU on the PCI list, if we
get a driver name from Mesa, or if it is a proprietary driver (i.e.
NVIDIA) which includes its name in the vendor ID. If we know the vendor
ID, we can usually derive the device ID from the PCI list.
We now also track which path glxtest took. If we successfully did the
test via EGL, then we will allow the pref/envvar to use EGL instead of
GLX. If the test reverted to GLX, then it will use GLX regardless of the
pref/envvar. This is necessary because we need to know if the libraries
are available or not -- some systems may be missing one or the other.
Differential Revision: https://phabricator.services.mozilla.com/D102933
We're seeing reports of crashes when users attempt to watch video on
Mali-G76 devices. Disable webrender for now on Mali-G76 until the
underlying problem is identified and fixed.
Differential Revision: https://phabricator.services.mozilla.com/D102903
Fetch the DRM device in the EGL version of glxtest, set it in gfxInfo and pass
it to gfxVars. Finally, use it in nsDMABufDevice::Configure().
While on it, also clean up EGL typedefs and defines a bit to match how it's
done for GLX.
Inspired by and copied from wlroots and Xwayland. Thanks to emersion!
Differential Revision: https://phabricator.services.mozilla.com/D98108
On Mali-Gxx there is a driver bug which causes partial updates to offscreen
render targets to fail. This was originally encountered in bug 1558374, where we
thought that the problem was just to do with scissored glClear()s, so we used a
shader to clear the target instead of glClear(). On some sites, however, even
this is not enough, and sometimes renderering to the target fails leaving some
of the previous content in place.
We appear to be able to work around this by ensuring that the entire render
target is cleared, by calling glClear() with the scissor test disabled. This
means that for picture cache tiles we must ensure the entire valid region is
rendered. This patch also reverts the first attempt at a fix from bug 1558374,
as it is no longer necessary since the entire target is being cleared.
Differential Revision: https://phabricator.services.mozilla.com/D90531
On Mali-G71 and G72 we see artifacts when scrolling around pages, in the form of
black squares or bits of content appearing in the wrong location. This appears
to be due to a driver bug when calling glClear() to clear a picture cache tile
texture with a scissor rect set.
We encountered a similar issue on some Intel hardware in bug 1638672, and worked
around it by using a custom shader to clear the texture rather than
glClear. This change applies this work around to Mali-Gxx devices too.
Differential Revision: https://phabricator.services.mozilla.com/D85867
* Majorly simplity CanvasRenderer
* Replace GLScreenBuffer with trivial GLSwapChain
* Use descriptor structs so that future SharedSurface changes aren't so painful
to propagate
* Mortgage/strip out more OffscreenCanvas code for now
Differential Revision: https://phabricator.services.mozilla.com/D75055
* Majorly simplity CanvasRenderer
* Replace GLScreenBuffer with trivial GLSwapChain
* Use descriptor structs so that future SharedSurface changes aren't so painful
to propagate
* Mortgage/strip out more OffscreenCanvas code for now
Differential Revision: https://phabricator.services.mozilla.com/D75055
* Majorly simplity CanvasRenderer
* Replace GLScreenBuffer with trivial GLSwapChain
* Use descriptor structs so that future SharedSurface changes aren't so painful
to propagate
* Mortgage/strip out more OffscreenCanvas code for now
Differential Revision: https://phabricator.services.mozilla.com/D75055
* Majorly simplity CanvasRenderer
* Replace GLScreenBuffer with trivial GLSwapChain
* Use descriptor structs so that future SharedSurface changes aren't so painful
to propagate
* Mortgage/strip out more OffscreenCanvas code for now
Differential Revision: https://phabricator.services.mozilla.com/D75055
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
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
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
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
Jamie Nicol
Brindusan Cristian
Noemi Erli
Narcis Beleuzu
Andrew Osmond
Robert Mader
sotaro
Sylvestre Ledru
Mihai Alexandru Michis
Kris Taeleman
Daosheng Mu
Kartikaya Gupta
Jeff Gilbert
Dorel Luca
Dzmitry Malyshau
Emilio Cobos Álvarez
Csoregi Natalia