Destroy RenderBufferTextureHosts that use VideoBridgeParent's Shmems before destroying all VideoBridgeParent's Shmems by PVideoBridgeParent::OnChannelError().
Differential Revision: https://phabricator.services.mozilla.com/D169796
LibX11 versions prior to 1.7 have a race condition that made it unsafe to use
in multiple threads. Since Firefox 104, we created a CanvasRender thread that
is used to service WebGL commands off the Renderer thread so that WebGL does
not block WebRender. If WebGL uses GLX, this can lead us to using GLX on the
two different threads. In combination with an unsafe version of libX11, this
can lead to severe instability.
Further evidence points to the fact that the fix in 1.7 may have caused further
crashes that were not resolved until 1.7.4. Yet other reports indicate other
drivers than Mesa may still have issues even after 1.7.4. Ultimately, there
may be no safe version of libX11 to use right now.
However, GLX, which uses libX11, is considered legacy at this point, with many
users transitioning to EGL instead. It seems reasonable to not allow GLX to be
used from multiple threads at all, unless overridden by a pref, to work around
this.
We already have a FEATURE_THREADSAFE_GL in place to denote this, which was
currently used mainly for Nouveau which is also unsafe to use on multiple
threads. If this feature fails, the CanvasRender thread is not used, and
all WebGL commands go back to being on the Renderer thread as normal, avoiding
the problem.
A further snag is that recent ANGLE updates required a larger CanvasRenderer
thread stack size to avoid exhausting the stack. This patch uncovers the fact
that the Renderer and Compositor threads did not similarly have their stack
sizes adjusted in case WebGL is running on those threads instead.
Differential Revision: https://phabricator.services.mozilla.com/D170992
LibX11 versions prior to 1.7 have a race condition that made it unsafe to use
in multiple threads. Since Firefox 104, we created a CanvasRender thread that
is used to service WebGL commands off the Renderer thread so that WebGL does
not block WebRender. If WebGL uses GLX, this can lead us to using GLX on the
two different threads. In combination with an unsafe version of libX11, this
can lead to severe instability.
Further evidence points to the fact that the fix in 1.7 may have caused further
crashes that were not resolved until 1.7.4. Yet other reports indicate other
drivers than Mesa may still have issues even after 1.7.4. Ultimately, there
may be no safe version of libX11 to use right now.
However, GLX, which uses libX11, is considered legacy at this point, with many
users transitioning to EGL instead. It seems reasonable to not allow GLX to be
used from multiple threads at all, unless overridden by a pref, to work around
this.
We already have a FEATURE_THREADSAFE_GL in place to denote this, which was
currently used mainly for Nouveau which is also unsafe to use on multiple
threads. If this feature fails, the CanvasRender thread is not used, and
all WebGL commands go back to being on the Renderer thread as normal, avoiding
the problem.
A further snag is that recent ANGLE updates required a larger CanvasRenderer
thread stack size to avoid exhausting the stack. This patch uncovers the fact
that the Renderer and Compositor threads did not similarly have their stack
sizes adjusted in case WebGL is running on those threads instead.
Differential Revision: https://phabricator.services.mozilla.com/D170992
This was interesting enough that @jgilbert wanted this, so I'm including this for completeness in
the current patch stack.
Split out from @jgilbert's D164308.
Differential Revision: https://phabricator.services.mozilla.com/D166709
This is basically an implementation detail that the existing callers doesn't really need to know.
Factor it out.
Split out from @jgilbert's D164308.
Differential Revision: https://phabricator.services.mozilla.com/D166707
This was interesting enough that @jgilbert wanted this, so I'm including this for completeness in
the current patch stack.
Split out from @jgilbert's D164308.
Differential Revision: https://phabricator.services.mozilla.com/D166709
This is basically an implementation detail that the existing callers doesn't really need to know.
Factor it out.
Split out from @jgilbert's D164308.
Differential Revision: https://phabricator.services.mozilla.com/D166707
WebGPU uses CompositableInProcessManager to push TextureHost directly from WebGPUParent to WebRender. But CompositableInProcessManager plumbing has a problem and caused Bug 1805209.
gecko already has a similar mechanism, called RemoteTextureMap. It is used in oop WebGL. If WebGPU uses RemoteTextureMap instead of CompositableInProcessManager, both WebGPU and oop WebGL use same mechanism.
WebGPUParent pushes a new texture to RemoteTextureMap. The RemoteTextureMap notifies the pushed texture to WebRenderImageHost.
Before the change, only one TextureHost is used for one swap chain. With the change, multiple TextureHosts are used for one swap chain with recycling.
The changes are followings.
- Use RemoteTextureMap instead of CompositableInProcessManager.
- Use RemoteTextureOwnerId instead of CompositableHandle.
- Use WebRenderCanvasData instead of WebRenderInProcessImageData.
- Add remote texture pushed callback functionality to RemoteTextureMap. With it, RemoteTextureMap notifies a new pushed remote texture to WebRenderImageHost.
- Remove CompositableInProcessManager.
Differential Revision: https://phabricator.services.mozilla.com/D164890
it started as a single method new_frame_ready with a composite parameter, to be split into two functions that end up calling the same HandleFrameOneDoc with a composite parameter so the extra function doesn't provide anything.
Differential Revision: https://phabricator.services.mozilla.com/D162299
Only transactions that contain the generate_frame flag are tracked by the pending frame and frame build counters.
This patch attempts to make this clearer with two small adjustments:
Firstly by putting the IncPendingFrameCount call right next to Transaction::GenerateFrame.
Secondly, undoing the hack in wr_notifier_wake_up. The latter is called outside of normal rendered/tracked frames and was calling HandleFrameOneDoc which decrements the rendered frame counter. To compensate it had to manually increment both counters via IncPendingFrameCount and manually decrement the built frame counter via DecPendingFrameBuildCount. Instead this patch introduces the aTrackedFrame argument so that HandleFrameOneDoc only fiddles with the counters when needed and wake_up does not have to hack around it.
Differential Revision: https://phabricator.services.mozilla.com/D162298
The previous name could have related to any situation where a composite is needed such as when animating or receiving transactions, but the function is actually specifically about scheduling a new composite if the previous one was skipped.
Differential Revision: https://phabricator.services.mozilla.com/D162295
- Ensure that the pending frame count is decremented by HandleFrameOneDoc even after some of the rare early-outs.
- Always check TooManyPendingFrames in CompositeToTarget.
It is unclear that these will actually catch (all of) the extraneous skipped frames. If anything, the simplification will make further investigation easier.
Differential Revision: https://phabricator.services.mozilla.com/D162294
This prevents copies and avoids the hack we have to avoid this, which
right now is using nsDependent{C,}String.
Non-virtual actors can still use `nsString` if they need to on the
receiving end.
Differential Revision: https://phabricator.services.mozilla.com/D152519
If MaybeRecordFrame is called after EndFrame, this means we are reading from
the back buffer state immediately after a call to SwapBuffers. The state of
the back buffer is undefined in that scenario, and mostly was just returning
old frames. We actually want to call MaybeRecordFrame before EndFrame, so we
get the valid contents of the back buffer before it is swapped out.
Differential Revision: https://phabricator.services.mozilla.com/D151988
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
The renderer thread is at the end of the rendering pipeline. For smoothness it is important that it completes its work quickly as soon as it receives some. It does not produce work for other threads so we don't risk of causing some build up. On the other hand, the higher priority will help with with avoiding some cases of congestion of work coming from the content process.
This only bumps the priority of the renderer thread as opposed to the entire GPU process (Blink does the latter). This is because we currently have too many thread on the GPU process so there is a risk of completely starving other processes. It's still something we want to consider and might be safer after we have done the work of reducing the number of threads.
Differential Revision: https://phabricator.services.mozilla.com/D143056
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
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
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
