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
For WebGPU, we produce the textures in the compositor process and the
content process doesn't need to be that involved except for hooking up
the texture to the display list. Currently this is done via an external
image ID.
Given that WebGPU needs to work with OffscreenCanvas, it would be best
if its display pipeline was consistent whether it was gotten from an
HTMLCanvasElement, OffscreenCanvas on the main thread, or on a worker
thread. As such, using an AsyncImagePipeline would be best.
However there is no real need to bounce the handles across process
boundaries. Hence this patch which adds CompositableInProcessManager.
This static class is responsible for collecting WebRenderImageHost
objects backed by TextureHost objects which do not leave the compositor
process. This will allow WebGPUParent to schedule compositions directly
in future patches.
Differential Revision: https://phabricator.services.mozilla.com/D138588
For WebGPU, we produce the textures in the compositor process and the
content process doesn't need to be that involved except for hooking up
the texture to the display list. Currently this is done via an external
image ID.
Given that WebGPU needs to work with OffscreenCanvas, it would be best
if its display pipeline was consistent whether it was gotten from an
HTMLCanvasElement, OffscreenCanvas on the main thread, or on a worker
thread. As such, using an AsyncImagePipeline would be best.
However there is no real need to bounce the handles across process
boundaries. Hence this patch which adds CompositableInProcessManager.
This static class is responsible for collecting WebRenderImageHost
objects backed by TextureHost objects which do not leave the compositor
process. This will allow WebGPUParent to schedule compositions directly
in future patches.
Differential Revision: https://phabricator.services.mozilla.com/D138588
This patch adds the necessary IPDL plumbing to allow us to create WebGL
instances off the main thread in the content process, and to execute
them on the Renderer thread in the compositor process.
Differential Revision: https://phabricator.services.mozilla.com/D127839
The background hang monitor uses the same timing thresholds as the one used by
the compositor thread, for similar reasons.
Differential Revision: https://phabricator.services.mozilla.com/D120117
Instead of warning against callers directly accessing the thread message loop,
actuually prevent them from doing so. This is also a preliminary step to
changing the type of the internally-created thread, which will no longer
directly expose its message loop.
Differential Revision: https://phabricator.services.mozilla.com/D119562
GLContext for CompositorOGL does not need depth buffer. Then it is better to re-create the mSingletonGL during fallback to RenderCompositorOGLSWGL.
Differential Revision: https://phabricator.services.mozilla.com/D110057
Name of Singleton is commonly used in gecko.
Name of SharedGL is confusing. It looks like "shared context", but it is not. The GL context is actually a singleton GLContext that is used by all WebRender. Each window creates one EGLSurface for each window. EGLSurface is switched for each window rendering.
Differential Revision: https://phabricator.services.mozilla.com/D108714
wr_notifier_wake_up uses RenderThread::WakeUp, which in turn just directly
calls Renderer::Update. As a side-effect, this can queue a composite to the
main framebuffer deep inside the renderer, but without having gone through
the normal pathway of Renderer::UpdateAndRender. UpdateAndRender ensures
that any RenderCompositor is properly prepared for the frame by calling
BeginFrame and other hooks as appropriate. But since we went through just
Update instead, there is never any call to BeginFrame and the SWGL framebuffer
never gets a chance to be properly set up in the RenderCompositor. In such
cases that we actually need to composite to the framebuffer, it seems more
appropriate to call UpdateAndRender, which also supports a boolean indicating
whether or not we actually intend to render something. To further simplify,
we just reuse the existing HandleFrameOneDoc handler to avoid needing separate
entry-points into UpdateAndRender.
Differential Revision: https://phabricator.services.mozilla.com/D99733
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
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
Use ID3D11VideoProcessor for video frame rendering.
WebRenderError::VIDEO_OVERLAY does not cause disabling WebRender. It just change gfxVars::UseWebRenderDCompVideoOverlayWin() to false.
Differential Revision: https://phabricator.services.mozilla.com/D88763
The following functions are asynchronously called by a bit different ways. It seems not good. It seems better to unify them.
PrepareForUse()
NofityForUse()
NotifyNotUsed()
Differential Revision: https://phabricator.services.mozilla.com/D87709
Simple implementation of skipping SyncObjectD3D11Host::Synchronize(). More optimization could be done in Bug 1635629.
Differential Revision: https://phabricator.services.mozilla.com/D75781
When android SurfaceTexture is rendered to WebGL, the SurfaceTexture should not be attached to GL context of WebRender.
Differential Revision: https://phabricator.services.mozilla.com/D66367
In bug 1470348 we started to detach all SurfaceTextures from the
current GL context in CompositorOGL::Pause(). This was required for
VR, so that when the VR presentation was entered the SurfaceTextures
could be attached to the VR context instead.
When RenderCompositorEGL was implemented for webrender, we copied the
call to detach from CompositorOGL. However, due to extra complexity in
webrender's threading model, this is causing assertion failures.
VR no longer relies upon the SurfaceTextures being detached when the
compositor is paused, as it now uses its own SurfaceTexture
set. Therefore we can remove the detach call from both
CompositorOGL::Pause and RenderCompositorEGL::Pause.
Differential Revision: https://phabricator.services.mozilla.com/D74832
There could be a case that new RenderThread::PrepareForUse() and new WebRender transaction by WebRenderBridgeParent::MaybeGenerateFrame() achieve during calling UpdateAndRender().
Differential Revision: https://phabricator.services.mozilla.com/D74365
Bug 1632096 added the capability to shared gl context with WebRender. This bug extends the support to non shared gl context.
Differential Revision: https://phabricator.services.mozilla.com/D72579
CanvasClientSharedSurface did not handle a case that CanvasClientSharedSurface was re-created, but GLScreenBuffer was not re-created. And RenderCompositorEGL::Pause() detaches all SurfaceTesxtures, but RenderAndroidSurfaceTextureHostOGL did not handle it.
Differential Revision: https://phabricator.services.mozilla.com/D70667
This removes the WebRender side of the previous slow frame indicator and replace it with a simple implementation that only looks at the CPU time on the render backend and renderer thread involved for building a frame.
A followup patch will add a separate indicator for when the displaylist/ipc/scene bits take too long.
Differential Revision: https://phabricator.services.mozilla.com/D69247
There are multiple SurfacePools: Main thread painting and the non-WebRender compositors create a new pool per window, and WebRender creates one shared pool across all windows. The non-WebRender users set the pool size limit to zero, i.e. no recycling across paints. This preserves the pre-existing behavior.
WebRender's pool size is configurable with the gfx.webrender.compositor.surface-pool-size pref.
Every window holds on to a SurfacePoolHandle. A SurfacePoolHandle has an owning reference to the pool, via a surface pool wrapper. Once all handles are gone, the surface pool goes away, too.
The SurfacePool holds on to IOSurfaces and MozFramebuffers. Both are created on demand, independently, but are associated with each other.
A given NativeLayer uses only one surface pool handle during its lifetime. The native layer no longer influences which GLContext its framebuffers are created for; the GL context is now managed by the surface pool handle.
As a result, a NativeLayer can no longer change which GLContext its framebuffers are created by.
So in the future, if we ever need to migrate a window frome one GLContext to another, we will need to recreate the NativeLayers inside it. I think that's ok.
Differential Revision: https://phabricator.services.mozilla.com/D54859
Removes NofityForUse() functions for simplicity.
Ensure that RenderTextureHost::PrepareForUse() is called before RenderTextureHost:: Lock(). When a task of calling RenderTextureHost::PrepareForUse() is simply posted to render thread, there is a case that RenderTextureHost:: Lock() is called before PrepareForUse() .
Differential Revision: https://phabricator.services.mozilla.com/D51974
