When we encounter an excessive number of device resets in the GPU
process, we would previously just disable the GPU process over blaming
the acceleration itself. Now we either restart the GPU process in a
last ditch attempt to clear the device state, and failing that, disable
acceleration due to excessive resets.
Differential Revision: https://phabricator.services.mozilla.com/D197721
Add probes for total number of launch attempts and unstable number of
launch attempts. Port expired CRASH_FALLBACKS probe to glean and renew
it, telling us the number of times we handled each crash fallback with
each method. And finally, add a probe to tell us the status of the GPU
process gfxFeature - this is already available on desktop via the
telemetry environment, but adding a glean probe allows us to gather
the data on Android too.
Differential Revision: https://phabricator.services.mozilla.com/D196866
On Android the OS may kill a process at any time while the app is in
the background. We try to avoid relaunching the GPU process in this
case, waiting instead until the app is foregrounded again. However, as
things stand if a content process is killed after the GPU process has
been killed, then the GPU process will be currently be
relaunched. This patch avoids that occuring by preventing
UnmapLayerTreeId() from launching a new process.
Additionally, we make it so that any GPU processes that are launched
whilst in the background are automatically assumed to be stable,
meaning they do not count towards the unstable launch count, and the
GPU process will not be disabled due to background process kills.
Differential Revision: https://phabricator.services.mozilla.com/D196292
This patch reworks CompositorManagerParent to be able to:
1) Get the owning IPDL actor for a given namespace
2) Rework shutdown to be more consistent
3) Block until either the relevant shared surface is added or the actor
is destroyed.
Differential Revision: https://phabricator.services.mozilla.com/D195964
Current gecko enables "software decoded video overlay" only when "hardware decoded video overlay" is enabled. On current release, "hardware decoded video overlay" is not enabled yet with non-Intel GPU, then "software decoded video overlay" is not yet enabled on release. It is not good. We want to enable "software decoded video overlay" independently from "hardware decoded video overlay". Then settings of video overlay is split between "hardware decoded video overlay" and "software decoded video overlay". Then "software decoded video overlay" could be enabled/disabled independently from status of "hardware decoded video overlay".
* settings of hardware decoded video overlay
- nsIGfxInfo::FEATURE_VIDEO_OVERLAY:
- gfx.webrender.dcomp-video-hw-overlay-win
- gfx.webrender.dcomp-video-hw-overlay-win-force-enabled
- gfxVars::UseWebRenderDCompVideoHwOverlayWin()
* settings of software decoded video overlay
- nsIGfxInfo::FEATURE_VIDEO_SOFTWARE_OVERLAY
- gfx.webrender.dcomp-video-sw-overlay-win
- gfx.webrender.dcomp-video-sw-overlay-win-force-enabled
- gfxVars::UseWebRenderDCompVideoSwOverlayWin()
Differential Revision: https://phabricator.services.mozilla.com/D175993
We already avoid launching the GPU process during shutdown, but shutdown
could happen after we initiated the launch and before it completes. Top
level IPDL protocols assert that we don't create them during shutdown,
so we need to be more diligent about checking for that.
Differential Revision: https://phabricator.services.mozilla.com/D175054
On Android, GPU process exists by default. When GPU process does not exist, an error should disable GPU process.
On Android, WebGL handling process could easily crash. The crash could trigger disable GPU process. Current out-of-process WebGL implementation creates WebGLParent in parent process. Then a crash in parent process could be triggered by WebGL. Then it seems better to disable out-of-process WebGL when GPU process does not exist.
And it seems also better to disable accelerated canvas, since it uses WebGL for acceleration.
Differential Revision: https://phabricator.services.mozilla.com/D167512
When we fallback without recreating the GPU process, we should ensure
that the gfxVar updates have been processed before recreating the
compositor sessions. This is achieved by blocking on the sync
PGPU::SendDeviceStatus IPDL message. This additional sync message only
happens during fallback and thus should be fairly cheap.
Differential Revision: https://phabricator.services.mozilla.com/D162020
This patch moves the media engine from the RDD process to the new
utility process, and create video bridge between the new utility process
and the GPU process in order to share the texture.
Differential Revision: https://phabricator.services.mozilla.com/D155901
Add crash annotations for the total number of webrender renderers, as
well as the number that are currently not paused, as this error could
be caused by having multiple renderers in a resumed state
concurrently. Additionally, add some gfxCriticalNotes for potentially
relevant error cases.
Differential Revision: https://phabricator.services.mozilla.com/D150000
In bug 1762424 we introduced a rendering path on Android using the
SurfaceControl API, in order to work around a bug preventing recovery
from a GPU process crash. However, the initial implementation caused
this bug: repeatedly sending the same SurfaceControl objects over AIDL
to the GPU process resulted in them being leaked, eventually causing
severe display issues. Not only were we duplicating the SurfaceControl
for each widget, but each time a widget was resized too.
This patch reworks our usage of the SurfaceControl API to avoid ever
having to send them cross-process. Instead, we create a single child
SurfaceControl object for each SurfaceControl that is attached to a
widget. (Typically there will be a single one shared between all
widgets, changing only when the app is paused and resumed, which is
much fewer than one per widget per resize.)
In the parent process we obtain the Surfaces that will be rendered in
to from the child SurfaceControls, and only send those Surfaces to the
GPU process. Thankfully unlike SurfaceControls, sending Surfaces
cross-process does not cause leaks. When the GPU process dies we
simply destroy all of the child SurfaceControls, and recreate them
again on-demand.
Differential Revision: https://phabricator.services.mozilla.com/D147437
WebRenderErrors errors after initialization will often be memory/driver
related. We can try to recover from this more gracefully by tearing down
the compositors instead of just crashing when we have finished falling
back. If one has a GPU process, it will be killed, and otherwise, it
will simulate a device reset in the parent process. This graceful
recovery can only be used if the process is declared "stable", according
to existing criteria for the GPU process (minimum uptime and frames
composited).
Differential Revision: https://phabricator.services.mozilla.com/D146477
Now that we send everything (except sometimes the user value
is sanitized) we should no longer perform this check.
This is also good because it eliminates security code you
have to have (and thus accidently omitting it is a
vulnerability) and changes it to security code that happens
automatically, and is enforced by the compiler (via mandatory
ctor argument.)
Depends on D141414
Differential Revision: https://phabricator.services.mozilla.com/D141415
PreferenceUpdate is the IPC message notifying a child process
that a preference has been updated. To correctly decide whether
or not a value should be sanitized in it, we need to know
what type of destination process it is; we add parameters to
Preferences::GetPreference indicating that.
Inside of ToDomPref we call ShouldSanitizePreference to
correctly populate the sanitized bit.
Depends on D141412
Differential Revision: https://phabricator.services.mozilla.com/D141413
This simplifies the number of negations needed,
and makes things easy to understand. I think
anyway; I know that without renaming it I made
several annoying-to-diagnose negation errors...
Depends on D141411
Differential Revision: https://phabricator.services.mozilla.com/D141412
A couple places where it might be a web content process
still pass 'false' - this will be corrected in a later
patch.
Depends on D141410
Differential Revision: https://phabricator.services.mozilla.com/D141411
dom/media/ipc/RDDProcessManager.cpp(320,21): error: comparison of integers of different signs: 'base::ProcessId' (aka 'unsigned long') and 'int' [-Werror,-Wsign-compare]
gpuProcessPid != -1 ? gpuProcessPid : base::GetCurrentProcId();
~~~~~~~~~~~~~ ^ ~~
dom/media/ipc/RDDProcessManager.cpp(332,21): error: comparison of integers of different signs: 'base::ProcessId' (aka 'unsigned long') and 'int' [-Werror,-Wsign-compare]
if (gpuProcessPid != -1) {
~~~~~~~~~~~~~ ^ ~~
gfx/layers/ipc/SharedSurfacesParent.cpp(360,38): error: comparison of integers of different signs: 'base::ProcessId' (aka 'unsigned long') and 'int' [-Werror,-Wsign-compare]
if (!gpm || gpm->GPUProcessPid() != -1) {
~~~~~~~~~~~~~~~~~~~~ ^ ~~
ipc/glue/MessageChannel.cpp(2145,13): error: comparison of integers of different signs: 'int32_t' (aka 'int') and 'const base::ProcessId' (aka 'const unsigned long') [-Werror,-Wsign-compare]
if (pid != base::kInvalidProcessId &&
~~~ ^ ~~~~~~~~~~~~~~~~~~~~~~~
Differential Revision: https://phabricator.services.mozilla.com/D144688
Now that we send everything (except sometimes the user value
is sanitized) we should no longer perform this check.
This is also good because it eliminates security code you
have to have (and thus accidently omitting it is a
vulnerability) and changes it to security code that happens
automatically, and is enforced by the compiler (via mandatory
ctor argument.)
Depends on D141414
Differential Revision: https://phabricator.services.mozilla.com/D141415
PreferenceUpdate is the IPC message notifying a child process
that a preference has been updated. To correctly decide whether
or not a value should be sanitized in it, we need to know
what type of destination process it is; we add parameters to
Preferences::GetPreference indicating that.
Inside of ToDomPref we call ShouldSanitizePreference to
correctly populate the sanitized bit.
Depends on D141412
Differential Revision: https://phabricator.services.mozilla.com/D141413
This simplifies the number of negations needed,
and makes things easy to understand. I think
anyway; I know that without renaming it I made
several annoying-to-diagnose negation errors...
Depends on D141411
Differential Revision: https://phabricator.services.mozilla.com/D141412
A couple places where it might be a web content process
still pass 'false' - this will be corrected in a later
patch.
Depends on D141410
Differential Revision: https://phabricator.services.mozilla.com/D141411
Now that we send everything (except sometimes the user value
is sanitized) we should no longer perform this check.
This is also good because it eliminates security code you
have to have (and thus accidently omitting it is a
vulnerability) and changes it to security code that happens
automatically, and is enforced by the compiler (via mandatory
ctor argument.)
Depends on D141414
Differential Revision: https://phabricator.services.mozilla.com/D141415
PreferenceUpdate is the IPC message notifying a child process
that a preference has been updated. To correctly decide whether
or not a value should be sanitized in it, we need to know
what type of destination process it is; we add parameters to
Preferences::GetPreference indicating that.
Inside of ToDomPref we call ShouldSanitizePreference to
correctly populate the sanitized bit.
Depends on D141412
Differential Revision: https://phabricator.services.mozilla.com/D141413
This simplifies the number of negations needed,
and makes things easy to understand. I think
anyway; I know that without renaming it I made
several annoying-to-diagnose negation errors...
Depends on D141411
Differential Revision: https://phabricator.services.mozilla.com/D141412
A couple places where it might be a web content process
still pass 'false' - this will be corrected in a later
patch.
Depends on D141410
Differential Revision: https://phabricator.services.mozilla.com/D141411
Now that we send everything (except sometimes the user value
is sanitized) we should no longer perform this check.
This is also good because it eliminates security code you
have to have (and thus accidently omitting it is a
vulnerability) and changes it to security code that happens
automatically, and is enforced by the compiler (via mandatory
ctor argument.)
Depends on D141414
Differential Revision: https://phabricator.services.mozilla.com/D141415
PreferenceUpdate is the IPC message notifying a child process
that a preference has been updated. To correctly decide whether
or not a value should be sanitized in it, we need to know
what type of destination process it is; we add parameters to
Preferences::GetPreference indicating that.
Inside of ToDomPref we call ShouldSanitizePreference to
correctly populate the sanitized bit.
Depends on D141412
Differential Revision: https://phabricator.services.mozilla.com/D141413
This simplifies the number of negations needed,
and makes things easy to understand. I think
anyway; I know that without renaming it I made
several annoying-to-diagnose negation errors...
Depends on D141411
Differential Revision: https://phabricator.services.mozilla.com/D141412
A couple places where it might be a web content process
still pass 'false' - this will be corrected in a later
patch.
Depends on D141410
Differential Revision: https://phabricator.services.mozilla.com/D141411
In bug 1762025 we found ourselves in a situation where we are unable
to ever create an EGLSurface, meaning we were continually attempting
to initialize a compositor, encountering a NEW_SURFACE webrender
error, causing us to tear down the compositor and create a new one,
repeating the cycle indefinitely.
This leaves the user with an unusable browser. We'd be better off
simply crashing. This patch adds a flag to FallbackFromAcceleration(),
which forces a crash if we have already exhausted all of the fallback
options. When calling FallbackFromAcceleration due to a NEW_SURFACE
error we set the flag to true. It may also be worthwhile setting this
flag for more errors in the future.
Differential Revision: https://phabricator.services.mozilla.com/D143486
The GPU process is destroyed in `ShutdownPhase::XPCOMShutdown` thus we shall not try to create it if we are in or beyond that phase.
Actually we might want to consider to block the creation even earlier if it does not exist, maybe from `ShutdownPhase::AppShutdown`, but this patch wants to just repair the crashes.
Differential Revision: https://phabricator.services.mozilla.com/D143349
SimulateDeviceReset() works differently from actual device reset handling. It seems better to make SimulateDeviceReset() more similar to actual device reset handling.
Differential Revision: https://phabricator.services.mozilla.com/D140161
