Currently webgpu is enabled by default on Nightly Android. As it is
currently receiving no testing at all, we should disable it by default
by adding a blocklist entry. Adventurous souls will still be able to
enable it by setting the pref gfx.webgpu.ignore-blocklist=true.
Differential Revision: https://phabricator.services.mozilla.com/D205300
This changes comes with several different refactorings all rolled into one,
unfotunately I couldn't find a way to pull them apart:
- First of all annotations now can either recorded (that is, we copy the value
and have the crash reporting code own the copy) or registered. Several
annotations are changed to use this functionality so that we don't need to
update them as their value change.
- The code in the exception handler is modified to read the annotations from
the mozannotation_client crate. This has the unfortunate side-effect that
we need three different bits of code to serialize them: one for annotations
read from a child process, one for reading annotations from the main process
outside of the exception handler and one for reading annotations from the
main process within the exception handler. As we move to fully
out-of-process crash reporting the last two methods will go away.
- The mozannotation_client crate now doesn't record annotation types anymore.
I realized as I was working on this that storing types at runtime has two
issues: the first one is that buggy code might change the type of an
annotation (that is record it under two different types at two different
moments), the second issue is that types might become corrupt during a
crash, so better enforce them at annotation-writing time. The end result is
that the mozannotation_* crates now only store byte buffers, track the
format the data is stored in (null-terminated string, fixed size buffer,
etc...) but not the type of data each annotation is supposed to contain.
- Which brings us to the next change: concrete types for annotations are now
enforced when they're written out. If an annotation doesn't match the
expected type it's skipped. Storing an annotation with the wrong type will
also trigger an assertion in debug builds.
Differential Revision: https://phabricator.services.mozilla.com/D195248
Some features such as the GPU process (except on Android), backdrop
filter (because it always works with Software WebRender), ANGLE (because
it is generally good) and out of process WebGL (we generally want to
remote WebGL for sandboxing purposes) are special, and should not be
disabled simply because we are uncertain about our configuration. In
these situations, disable most features, but keep these enabled by
default.
Differential Revision: https://phabricator.services.mozilla.com/D197595
Some features such as the GPU process (except on Android), backdrop
filter (because it always works with Software WebRender), ANGLE (because
it is generally good) and out of process WebGL (we generally want to
remote WebGL for sandboxing purposes) are special, and should not be
disabled simply because we are uncertain about our configuration. In
these situations, disable most features, but keep these enabled by
default.
Differential Revision: https://phabricator.services.mozilla.com/D197595
- Run glxtest directly from GfxInfo::GetData() in case we're missing glx test data. That happens for unusual code paths
like profile manager run or xpcshell testing.
- Remove nsIGfxInfoDebug::fireTestProcess() hack to run glxtest in testsuite. We don't need that due this change.
Differential Revision: https://phabricator.services.mozilla.com/D175868
This is:
* An easier way for browser code to access it.
* Avoids having a bunch of per-platform implementations.
* We don't need to actually get graphics info for it to work.
So it should be a bit nicer over all.
Differential Revision: https://phabricator.services.mozilla.com/D168373
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
The biggest set of APIs from ns[T]StringObsolete which are still heavily used
are the string searching APIs. It appears the intention was for these to be
replaced by the `FindInReadable` APIs, however that doesn't appear to have
happened.
In addition, the APIs have some quirks around their handling of mixed character
widths. These APIs generally supported both narrow strings and the native
string type, probably because char16_t string literals weren't available until
c++11. Finally they also used easy-to-confuse unlabeled boolean and integer
optional arguments to control behaviour.
These patches do the following major changes to the searching APIs:
1. The ASCII case-insensitive search method was split out as
LowerCaseFindASCII, rather than using a boolean. This should be less
error-prone and more explicit, and allows the method to continue to use
narrow string literals for all string types (as only ASCII is supported).
2. The other [R]Find methods were restricted to only support arguments with
matching character types. I considered adding a FindASCII method which would
use narrow string literals for both wide and narrow strings but it would've
been the same amount of work as changing all of the literals to unicode
literals.
This ends up being the bulk of the changes in the patch.
3. All find methods were re-implemented using std::basic_string_view's find
algorithm or stl algorithms to reduce code complexity, and avoid the need to
carry around the logic from nsStringObsolete.cpp.
4. The implementations were moved to nsTStringRepr.cpp.
5. An overload of Find was added to try to catch callers which previously
called `Find(..., false)` or `Find(..., true)` to set case-sensitivity, due
to booleans normally implicitly coercing to `index_type`. This should
probably be removed at some point, but may be useful during the transition.
Differential Revision: https://phabricator.services.mozilla.com/D148300
The biggest set of APIs from ns[T]StringObsolete which are still heavily used
are the string searching APIs. It appears the intention was for these to be
replaced by the `FindInReadable` APIs, however that doesn't appear to have
happened.
In addition, the APIs have some quirks around their handling of mixed character
widths. These APIs generally supported both narrow strings and the native
string type, probably because char16_t string literals weren't available until
c++11. Finally they also used easy-to-confuse unlabeled boolean and integer
optional arguments to control behaviour.
These patches do the following major changes to the searching APIs:
1. The ASCII case-insensitive search method was split out as
LowerCaseFindASCII, rather than using a boolean. This should be less
error-prone and more explicit, and allows the method to continue to use
narrow string literals for all string types (as only ASCII is supported).
2. The other [R]Find methods were restricted to only support arguments with
matching character types. I considered adding a FindASCII method which would
use narrow string literals for both wide and narrow strings but it would've
been the same amount of work as changing all of the literals to unicode
literals.
This ends up being the bulk of the changes in the patch.
3. All find methods were re-implemented using std::basic_string_view's find
algorithm or stl algorithms to reduce code complexity, and avoid the need to
carry around the logic from nsStringObsolete.cpp.
4. The implementations were moved to nsTStringRepr.cpp.
5. An overload of Find was added to try to catch callers which previously
called `Find(..., false)` or `Find(..., true)` to set case-sensitivity, due
to booleans normally implicitly coercing to `index_type`. This should
probably be removed at some point, but may be useful during the transition.
Differential Revision: https://phabricator.services.mozilla.com/D148300
There is a crash in glFenceSync (used to recycle PBOs when uploading
textures) affecting several PowerVR GPUs. Block webrender on the known
bad combinations of GPU and driver versions.
Differential Revision: https://phabricator.services.mozilla.com/D148638
This removes a bunch of custom code from GfxInfo to obtain screen
information, and instead collects that screen information in
ScreenManager.
This, apart of removing duplicated code, has the extra benefit of
reporting multi-monitor information on GTK (and potentially in the
future reporting scale and refresh rate properly as well, I've kept the
telemetry as it was on that regard).
Differential Revision: https://phabricator.services.mozilla.com/D145178
This removes a bunch of custom code from GfxInfo to obtain screen
information, and instead collects that screen information in
ScreenManager.
This, apart of removing duplicated code, has the extra benefit of
reporting multi-monitor information on GTK (and potentially in the
future reporting scale and refresh rate properly as well, I've kept the
telemetry as it was on that regard).
Differential Revision: https://phabricator.services.mozilla.com/D145178
For example, the SDK class android.media.MediaDrm$KeyStatus will now
be defined as MediaDrm::KeyStatus rather than just KeyStatus.
Not only does this avoid polluting the top-level namespace, but it
also avoids a bug where invalid type names were generated if the
nested class contains a method with a parameter or return of the outer
class' type.
Differential Revision: https://phabricator.services.mozilla.com/D143043
On Android version 12, it appears as if the EGL context does not
correctly get detached from a Surface when its process dies. This
means that subsequent attempts to create an EGL context fail, meaning
we cannot render anything.
This results in a completely unusable browser following a GPU process
crash, which is worse than the alternative of a parent process crash.
Block the GPU process on Android 12 and above until we have found a
workaround.
Differential Revision: https://phabricator.services.mozilla.com/D142452
As historical reason, AndroidBridge has a lot of JNI wrappers. But we have
auto-generation JNI wrappers now, so it is unnecessary to keep wrappers in
AndroidBridge for GfxInfo.
So I would like to remove AndroidBridge dependencies from GfxInfo.
Differential Revision: https://phabricator.services.mozilla.com/D135324
Due to bug 1742986 and bug 1717863 we are blocking webrender on
Android devices PowerVR Rogue G6110 GPUs. These devices will use
software webrender instead.
Differential Revision: https://phabricator.services.mozilla.com/D132170
While webrender has been shipping for a long time on other Adreno 5xx
devices, we had disabled it on Adreno 505 and 506 due to frequent
crashes during shader compilation. This crash has now been fixed, so
we can ship webrender to these devices.
Depends on D117427
Differential Revision: https://phabricator.services.mozilla.com/D117428
Webrender had previously been disabled on Adreno 3xx devices running
Android 9 due to a rendering issue caused by a driver bug. (See bug
1712148) The issue has now been identified and a workaround put in
place, so we can re-enable webrender.
Depends on D117033
Differential Revision: https://phabricator.services.mozilla.com/D117034
Due to a report of flashing black rectangles on an Adreno 308 device
running Android 9. As a precaution disable webrender for android 9 and
later for all Adreno 3xx GPUs.
Differential Revision: https://phabricator.services.mozilla.com/D115622
We encounter frequent crashes in glLinkProgram on some Adreno
devices. This is likely due to a driver bug, but we have been unable
to figure out the exact cause and work around it.
According to the crash data, this bug appears to affect Adreno 505 and
506 devices running Android 9 only. Disable webrender on these devices
in order to avoid the crash.
Depends on D114949
Differential Revision: https://phabricator.services.mozilla.com/D114950
Previously we had disabled optimized shaders on Mali-T devices running
Android versions up to 5.1, due to broken rendering. We have now had a
report of the same issue on Android 7.1. As a precaution, disable
optimized shaders for all Mali-T devices regardless of android version.
Differential Revision: https://phabricator.services.mozilla.com/D113913
An earlier patch in this bug disabled webrender on these devices due
to reports of broken rendering. Now that the cause of the broken
rendering has been worked around, we can re-enable webrender.
Depends on D113313
Differential Revision: https://phabricator.services.mozilla.com/D113319
Previously in bug 1689064 we disabled our usage of optimized shaders
to work around a driver bug affecting Mali-T6xx devices. It now
appears this bug affects Mali-T7xx and T8xx devices too, only on
Android versions 5.1 or below. This patch disables shader optimization
for all Mali-T devices when the Android version is 5.1 or below.
Differential Revision: https://phabricator.services.mozilla.com/D113313
There appears to be a driver issue causing the browser to be unusable
on such devices. Disable webrender until we diagnose the issue and
find a workaround.
Differential Revision: https://phabricator.services.mozilla.com/D113296
Running webrender on PowerVR Rogue devices results in some images
being rendered with swapped R and B channels. This is because we use
texture swizzling for images in the shared texture cache, and
presumably the driver has a buggy implementation. This patch disables
texture swizzling on all PowerVR Rogue devices as a precaution.
It also ensures that we always use BGRA format textures in cases where
texture swizzling is unsupported, otherwise we encounter GL errors
when attempting to upload BGRA data to RGBA format textures, as GLES
does not support format conversion during upload. Furthermore, we make
it so that using RGBA+glTexStorage+swizzling is preferred to
BGRA+glTexImage in cases where swizzling is actually supported, as we
generally want to prefer glTexStorage to glTexImage.
Lastly, in cases where neither BGRA or swizzling are supported, rather
than attempting to upload BGRA data to RGBA textures (which will
result in a GL error) we pretend the BGRA data is RGBA. This will
result in the channels being swapped when rendering, but that is
preferable to the alternative of images not being uploaded at
all. This configuration shouldn't actually exist in the wild anyway.
Differential Revision: https://phabricator.services.mozilla.com/D111840
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
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
Jamie Nicol