When Surfaces/SurfaceTextures are allocated they are given a handle,
which is a monotonically increasing 32-bit integer. To render
Surfaces, we typically pass the Surface handle to the compositor,
which then looks it up in a map to find the corresponding
SurfaceTexture.
Following a GPU process restart, content may be left with stale
handles referencing SurfaceTextures which no longer exist. Once new
SurfaceTextures are allocated, these stale handles may reference new
SurfaceTextures with no relation to the old handle. This can lead to
rendering the wrong texture. Additionally, we may crash when
allocating "sync" SurfaceTextures, as the previous sync texture for a
certain handle may not have been released yet.
To fix this, this patch combines the existing handle with a new ID
uniquely identifying the process in which the SurfaceTexture was
allocated (or 0 for the parent process). We use a monotonically
increasing value rather than the pid to guard against the new GPU
process possibly having the same pid as the previous instance. We
combine these two 32-bit integers and use the resulting 64-bit integer
as the Surface handle.
Differential Revision: https://phabricator.services.mozilla.com/D150963
The async front buffer posting is going to be enabled by another bug.
Async IPC was added for async front buffer posting for out-of-process WebGL.
Client does not use TextureClient for storing SurfaceDescriptor.
It works basically same way as to in-process WebGL around nsDisplayCanvas, WebRenderCanvasData, WebRenderCommandBuilder and WebRenderBridgeParent.
SharedSurfaces of SurfaceDescriptorD3D10 are kept alive during their usage. It is for keeping a shread handle valid.
Copied data buffers of SharedShurface_Basics are kept alive during their usage. It is for keeping RenderBufferTextureHost valid.
Differential Revision: https://phabricator.services.mozilla.com/D150197
The async front buffer posting is going to be enabled by another bug.
Async IPC was added for async front buffer posting for out-of-process WebGL.
Client does not use TextureClient for storing SurfaceDescriptor.
It works basically same way as to in-process WebGL around nsDisplayCanvas, WebRenderCanvasData, WebRenderCommandBuilder and WebRenderBridgeParent.
SharedSurfaces of SurfaceDescriptorD3D10 are kept alive during their usage. It is for keeping a shread handle valid.
Copied data buffers of SharedShurface_Basics are kept alive during their usage. It is for keeping RenderBufferTextureHost valid.
Differential Revision: https://phabricator.services.mozilla.com/D150197
Also, no reason not to complete iteration across uTex[012], as opposed
to breaking early once we hit the first one that isn't present.
A shader with e.g. uTex1 but not uTex0 is weird, but there's no reason
for it not to work.
Differential Revision: https://phabricator.services.mozilla.com/D150270
On multi-GPU setups, EGLs "surfaceless" platform may pick the wrong device.
There is a very recent extension which solves this issue,
`EGL_EXT_explicit_device`, however it states:
> Using EGL_EXT_explicit_device with EGL_MESA_platform_surfaceless is
> functionally identical to EGL_EXT_platform_device.
Thus, if we previously detected a render node device, use
`EGL_EXT_platform_device` to create the display in headless scenarios.
For all other cases, notably ARM SOCs where
`EGL_DRM_RENDER_NODE_FILE_EXT` is not yet availble, continue to
fall back to the surfaceless platform.
Note: this patch also does some cleanups. Most importantly,
`EGL_MESA_platform_surfaceless` is a client extension, not a
display extension. The check for it must thus always have failed.
Instead, check for it before trying to use it when creating the
display.
Also remove the rendundant redifinition in `GLDefs.h` - it's
already included in the upstream EGL headers.
Differential Revision: https://phabricator.services.mozilla.com/D148946
- Update SharedSurfaceDMABUF for EGL_MESA_image_dma_buf_export DMABufSurface interface.
- Test surface export and import in SurfaceFactory_DMABUF::CanCreateSurface() to make sure it really works.
Depends on D147636
Differential Revision: https://phabricator.services.mozilla.com/D147637
Avoid relying on X11 errors to detect failures where alternative means would
suffice (i.e. checking results for failure or MakeCurrent failures). All other
users of ScopedXErrorHandler outside of GLContextProviderGLX use it only to
ignore errors rather than actually check the error result. Given those concerns,
we also change the default X11 error handler to merely ignore errors rather than
abort, such that X11 calls in Gecko no longer require an error trap by default.
This also avoids contention with other libraries that may temporarily override
the error handler such as GDK or Cairo since Gecko will never touch the handler
after startup.
Differential Revision: https://phabricator.services.mozilla.com/D147247
Avoid relying on X11 errors to detect failures where alternative means would
suffice (i.e. checking results for failure or MakeCurrent failures). All other
users of ScopedXErrorHandler outside of GLContextProviderGLX use it only to
ignore errors rather than actually check the error result. Given those concerns,
we also change the default X11 error handler to merely ignore errors rather than
abort, such that X11 calls in Gecko no longer require an error trap by default.
This also avoids contention with other libraries that may temporarily override
the error handler such as GDK or Cairo since Gecko will never touch the handler
after startup.
Differential Revision: https://phabricator.services.mozilla.com/D147247
With CI's NVIDIA GPU, SharedHandle of ID3D11Texture2D of hardware decoded video during no video copy caused rendering problem. When SharedHandle is not used, the rendering problem did not happen. But when video is rendered to WebGL texture, SharedHandle need to be used.
In this case, D3D11TextureIMFSampleImage copies original ID3D11Texture2D to a new ID3D11Texture2D and use a shared handled of the copied texture. And no video copy of future video frames are disabled.
NoCopyNV12Texture is renamed to ZeroCopyNV12Texture to clarify its meaning.
Differential Revision: https://phabricator.services.mozilla.com/D144598
