When webrender's GL context is created, query the GL strings and
report them back to gfxInfo. This is used as a sanity check that
gfxInfo's cached values were correct. If they differ we don't change
any blocklisting decisions for the current session, but we do update
the cache so that the next run will use the correct values.
In practice we do not expect the cached values to differ from the
reported ones, as Android devices tend not to change their GPU, nor
update drivers without an OS update.
Differential Revision: https://phabricator.services.mozilla.com/D278247
Android's gfxInfo creates a GL context and queries the vendor,
renderer, version, and extensions strings. It then uses these for
blocklisting. Creating a GL context can be expensive, and this occurs
on the main thread early during startup.
This patch therefore caches the queried strings. In the happy path, we
read the strings from preferences and avoid having to initialize a GL
context altogether. If the cache is empty, or we detect the operating
system has been updated, then we create the context and query the
strings as before.
The relies on the assumption that the graphics driver will not be
updated without an operating system update, and that the GPU will not
change. This seems likely to be valid for the vast majority of users,
but the next patch will add a mechanism to help in cases where that
assumption does not hold.
Differential Revision: https://phabricator.services.mozilla.com/D278246
Now that Direct2D is no longer supported, we can start removing the associated Feature
and queries of it.
This patch does the awkward work of removing Direct2D feature testing throughout Gecko.
Differential Revision: https://phabricator.services.mozilla.com/D269855
These are supported by default in OpenGL, but in GLES they require the
extension GL_EXT_texture_norm16. By exposing whether this is supported
we will be able to ensure that producers of texture data (such as video
decoders) only provide consumers (such as webrender) with formats they
can handle.
The gfxFeature state is initialized from the gfxInfo blocklist. This was
convenient as Android's gfxInfo has access to the list of available GL
extensions. But importantly it also has the benefit of allowing us to
blocklist any devices on which we encounter issues with this extension.
Differential Revision: https://phabricator.services.mozilla.com/D253133
These are supported by default in OpenGL, but in GLES they require the
extension GL_EXT_texture_norm16. By exposing whether this is supported
we will be able to ensure that producers of texture data (such as video
decoders) only provide consumers (such as webrender) with formats they
can handle.
The gfxFeature state is initialized from the gfxInfo blocklist. This was
convenient as Android's gfxInfo has access to the list of available GL
extensions. But importantly it also has the benefit of allowing us to
blocklist any devices on which we encounter issues with this extension.
Differential Revision: https://phabricator.services.mozilla.com/D253133
These are supported by default in OpenGL, but in GLES they require the
extension GL_EXT_texture_norm16. By exposing whether this is supported
we will be able to ensure that producers of texture data (such as video
decoders) only provide consumers (such as webrender) with formats they
can handle.
The gfxFeature state is initialized from the gfxInfo blocklist. This was
convenient as Android's gfxInfo has access to the list of available GL
extensions. But importantly it also has the benefit of allowing us to
blocklist any devices on which we encounter issues with this extension.
Differential Revision: https://phabricator.services.mozilla.com/D253133
This is a non-functional change to clean up some of the memory
management in GfxInfo and GfxDriverInfo. This makes it easier to track
what owns what and helps later patches in the stack.
Differential Revision: https://phabricator.services.mozilla.com/D251789
This reverts commit ebecd3fbf1.
Revert "Bug 1969255 - Part 4. Distingush between Windows 10 and 11 in blocklist rules. r=win-reviewers,gfx-reviewers,bradwerth,gstoll"
This reverts commit 67e34e0032.
Revert "Bug 1969255 - Part 3. Add support for detailed OS version comparison blocklist rules. r=geckoview-reviewers,win-reviewers,gfx-reviewers,bradwerth,nalexander,gstoll"
This reverts commit e7a16b3708.
Revert "Bug 1969255 - Part 2. Switch over to managed pointers in GfxInfo. r=geckoview-reviewers,win-reviewers,gfx-reviewers,bradwerth,nalexander,gstoll"
This reverts commit 1823b99227.
Revert "Bug 1969255 - Part 1. Ensure we expose historically missing filter criteria on the blocklist. r=gfx-reviewers,bradwerth"
This reverts commit c5e3cb59b5.
This is a non-functional change to clean up some of the memory
management in GfxInfo and GfxDriverInfo. This makes it easier to track
what owns what and helps later patches in the stack.
Differential Revision: https://phabricator.services.mozilla.com/D251789
This reverts commit 71c854a7c7.
Revert "Bug 1969255 - Part 4. Distingush between Windows 10 and 11 in blocklist rules. r=win-reviewers,gfx-reviewers,bradwerth,gstoll"
This reverts commit f12b5a2e23.
Revert "Bug 1969255 - Part 3. Add support for detailed OS version comparison blocklist rules. r=geckoview-reviewers,win-reviewers,gfx-reviewers,bradwerth,nalexander,gstoll"
This reverts commit e6d94109d2.
Revert "Bug 1969255 - Part 2. Switch over to managed pointers in GfxInfo. r=geckoview-reviewers,win-reviewers,gfx-reviewers,bradwerth,nalexander,gstoll"
This reverts commit d984fec4f8.
Revert "Bug 1969255 - Part 1. Ensure we expose historically missing filter criteria on the blocklist. r=gfx-reviewers,bradwerth"
This reverts commit 2f4298473a.
This is a non-functional change to clean up some of the memory
management in GfxInfo and GfxDriverInfo. This makes it easier to track
what owns what and helps later patches in the stack.
Differential Revision: https://phabricator.services.mozilla.com/D251789
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
Sylvestre Ledru