RenderCompositorANGLE::ShutdownEGLLibraryIfNecessary() is not necessary since Bug 1656034 fix. Device reset handling could be more platform independent.
Differential Revision: https://phabricator.services.mozilla.com/D130960
RenderCompositorANGLE::ShutdownEGLLibraryIfNecessary() is not necessary since Bug 1656034 fix. Device reset handling could be more platform independent.
Differential Revision: https://phabricator.services.mozilla.com/D130960
This passes the swgl context down from the renderer
instead of using the current context. This ensures
we report all of the contexts and don't double report.
Differential Revision: https://phabricator.services.mozilla.com/D116474
This passes the swgl context down from the renderer
instead of using the current context. This ensures
we report all of the contexts and don't double report.
Differential Revision: https://phabricator.services.mozilla.com/D116474
Crash could happen with WebRender rendering when RenderCompositorEGL is not ready for rendering. With the change, RenderCompositorEGL::BeginFrame() is not called when RenderCompositorEGL is not ready.
Differential Revision: https://phabricator.services.mozilla.com/D100871
These NVIDIA device resets are specific to Linux and trying to handle
them more gracefully is increasingly difficult. There are many
textures/buffers that we need to clear inside WebRender, but attempting
to add them to the list has proved difficult due to the number of places
we need to add, as well as race conditions with clearing them. Given
this shouldn't happen often, it doesn't seem worth optimizing for and we
should treat it just as an innocent device reset.
Testing this revealed an issue during recovery where unflushed device
resets were not handled as expected. When we checked for errors after
creating a new GL context, we would encounter a GL_CONTEXT_LOST error
which we failed to recover from. This is because we called
GLContext::fGetError instead of the GL method directly; the context lost
state was saved in mContextLost, and any subsequent calls to
GLContext::fGetError would continue to return GL_CONTEXT_LOST.
Differential Revision: https://phabricator.services.mozilla.com/D99905
Aside from on Windows, we do not appear to handle device resets properly
without the GPU process. This patch adds in the necessary plumbing to
handle the device reset properly. It also ensures that whenever we check
for a device reset reason, we handle all of the reasons (e.g. not just
the NV video memory purge reset reason) to ensure they are not lost, and
handles them all consistently in the same manner.
It also tracks the number of device resets for thresholding purposes
with an in process compositor. While it will only disable WebRender on
Linux at this time, it will put a note in the critical log if the
threshold was exceeded on all platforms. This may prove useful in
evaluating whether or not we should do the same everywhere.
Differential Revision: https://phabricator.services.mozilla.com/D98705
Implementing the Draw compositor via the native compositor interface
is simpler if the buffer age is passed into the top level render method.
Differential Revision: https://phabricator.services.mozilla.com/D95824
Implementing the Draw compositor via the native compositor interface
is simpler if the buffer age is passed into the top level render method.
Differential Revision: https://phabricator.services.mozilla.com/D95824
In a (large-ish) nutshell:
- Consolidate all counters under a single type.
- Counters are all arranged in an array and referred to via index.
- All counters can be displayed as average+max (float/int), graph, and change indicator.
- Specify what to show and in what form via a pref.
- All counters and visualizations support not having values every frame.
- GPU time queries visualization is easier to read relative to the frame budget:
- If the maximum value is under 16ms, the right side of the graph is fixed at 16ms.
- If the maximum value is above 16ms, draw a vertical bar at 16ms.
- Added a few new profile counters:
- Total frame CPU time (from API send to the end of GPU command submission).
- Visibility, Prepare, Batching and Glyph resolve times.
The main change is how profile counters are represented. Instead of having different types for different visualizations, every counter is represented the same way, tracking average/max values over half a ms and optionally recording a graph over a number of frames. Counters are stored in a vector and referred to via index (See constants at the top of profiler.rs).
The main motivation for this storage is to facilitate adding counters without having to think too much about where to store them and how to pass them to the renderer.
The profiler's UI is defined by a string with with a single syntax:
- Comma separated list of tokens (leading and trailing spaces ignored), which can be:
- A counter name:
- If prefixed with a '#' character, the counter is shown as a graph.
- If prefixed with a '*' character, the counter is shown as a change indicator
- By default (counter name without prefix), the counter is shown as average and max over half a second.
- A preset name:
- A preset is a builtin UI string in the same syntax that can be nested in the main UI string.
- Presets are defined towards the top of profiler.rs and can also refer to other presets.
- An empty token adds a bit of vertical space.
- A '|' token begins a new column.
- A '_' token begins a new row.
Differential Revision: https://phabricator.services.mozilla.com/D93603
In a (large-ish) nutshell:
- Consolidate all counters under a single type.
- Counters are all arranged in an array and referred to via index.
- All counters can be displayed as average+max (float/int), graph, and change indicator.
- Specify what to show and in what form via a pref.
- All counters and visualizations support not having values every frame.
- GPU time queries visualization is easier to read relative to the frame budget:
- If the maximum value is under 16ms, the right side of the graph is fixed at 16ms.
- If the maximum value is above 16ms, draw a vertical bar at 16ms.
- Added a few new profile counters:
- Total frame CPU time (from API send to the end of GPU command submission).
- Visibility, Prepare, Batching and Glyph resolve times.
The main change is how profile counters are represented. Instead of having different types for different visualizations, every counter is represented the same way, tracking average/max values over half a ms and optionally recording a graph over a number of frames. Counters are stored in a vector and referred to via index (See constants at the top of profiler.rs).
The main motivation for this storage is to facilitate adding counters without having to think too much about where to store them and how to pass them to the renderer.
The profiler's UI is defined by a string with with a single syntax:
- Comma separated list of tokens (leading and trailing spaces ignored), which can be:
- A counter name:
- If prefixed with a '#' character, the counter is shown as a graph.
- If prefixed with a '*' character, the counter is shown as a change indicator
- By default (counter name without prefix), the counter is shown as average and max over half a second.
- A preset name:
- A preset is a builtin UI string in the same syntax that can be nested in the main UI string.
- Presets are defined towards the top of profiler.rs and can also refer to other presets.
- An empty token adds a bit of vertical space.
- A '|' token begins a new column.
- A '_' token begins a new row.
Differential Revision: https://phabricator.services.mozilla.com/D93603
I liked the separation, but having everything in RendererOGL.cpp makes the next patch easier.
One nice effect of this patch is that all the recorder-related wr_renderer_* functions
are now called from the same file. Previously, most of them were called in
WebRenderCompositionRecorder.cpp, but the cleanup function
wr_renderer_release_composition_recorder_structures was called from RendererOGL.cpp.
Differential Revision: https://phabricator.services.mozilla.com/D89867
Rather than having two windowID -> [something] hash tables, this reduces it to
one: The renderer is already per-window so we just put the recorder into the
renderer.
Differential Revision: https://phabricator.services.mozilla.com/D89866
Release fence is delivered from RenderCompositorEGL to WebRenderImageHost via AsyncImagePipelineManager. And the fence is sent to client side by ImageBridgeParent.
Differential Revision: https://phabricator.services.mozilla.com/D88158
Currently RendererOGL has mixed-in details of SWGL context creation which becomes messy
and slightly unanticipated based on the nomenclature and structure of RendererOGL. Based
on other work in bug 1646835, it becomes more natural to move this context creation into
the specific SWGL RenderCompositors so that RendererOGL can be agnostic to any SWGL
details.
Differential Revision: https://phabricator.services.mozilla.com/D80273
This is a first implementation of a software-only SWGL RenderCompositor
that relies on the existing widget hooks for Basic compositing. It attempts
to lock the widget and get a DT whose underlying data it can supply directly
to SWGL to composite to. Critically, it does not rely on OpenGL or any other
form of HW accel to function. The interface between the RenderCompositor and
SWGL will be further refined in follow-up patches.
Differential Revision: https://phabricator.services.mozilla.com/D80268
