- Make dmabuf preferences static so we don't need GetDMABufDevice() to access them.
- Configure GetDMABufDevice() when it's created.
- Init dmabuf members directly in class.
- Removed unused methods.
Differential Revision: https://phabricator.services.mozilla.com/D176404
DrawTargetWebgl renders a path by uploading vertex data to the back of
a large VBO using glBufferSubData then issuing a draw call, orphaning
the buffer when it becomes full. This results in many glBufferSubData
calls being interleaved with draw calls. On Mali GPUs this causes
severe performance issues as the driver is unable to determine that
any pending draw calls do not reference the updated region of the
buffer, and therefore must create a copy of the buffer for each
update.
However, since *we* know that we never overwrite a region that is
referenced by a submitted draw call, we can force the driver to avoid
making these copies. We do so by adding a new function
UnsynchronizedBufferSubData(), which acts like BufferSubData so long
as this rule is followed. Internally, this uses glMapBufferRange with
GL_MAP_UNSYNCHRONIZED_BIT, allowing the driver to omit the extraneous
copies.
Differential Revision: https://phabricator.services.mozilla.com/D174685
As above, but with a bit more type safety, plus a TLS cache so we don't
need to lock in the common case we have already initialized the wayland
display.
Differential Revision: https://phabricator.services.mozilla.com/D173964
I think this is a driver bug, since we are literally asking
`dlsym('wglGetExtensionsStringARB')()` for the list of extensions, but
on my AMD 6950xt windows machine with angle disabled, the string list
only has WGL_EXT_extensions_string listed, not the _ARB_ version.
But there's not much reason to assert this pedantically in the face of
driver bugs here.
Differential Revision: https://phabricator.services.mozilla.com/D172817
Modify AHardwareBuffer implementation as to support gl::SharedSurface of out-of-process WebGL. And remove unused AHardwareBuffer implementation.
By limiting AHardwareBuffer only in GPU process, AHardwareBuffer implementation becomes simpler. We do not need to handle cross process AHardwareBuffer delivery and cross process android Fence delivery.
Differential Revision: https://phabricator.services.mozilla.com/D167911
This updates the version wpf-gpu-raster which adds support for
GPUs/drivers that use truncation instead of rounding when converting
vertices to fixed point.
It also adds the GL vendor to InitContextResult so that we can detect
AMD on macOS and tell wpf-gpu-raster that truncation is going to happen.
Differential Revision: https://phabricator.services.mozilla.com/D167503
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
When available, we should use the [`EGL_KHR_no_config_context` extension] inside of
`GLContextEGL::CreateEGLPBufferOffscreenContext`. The usage of this extension will be necessary to
accommodate incoming upstream changes in ANGLE, which have [migrated away][incoming-breakage] from
[our usage of `EGL_FLEXIBLE_SURFACE_COMPATIBILITY_SUPPORTED_ANGLE` in
`gfx/webrender_bindings/RenderCompositorANGLE.cpp`][what-will-be-broken] in favor of this standard
extension. Luckily it's forwards-compatible to start consuming it now!
This revision changes a few things that are linked:
- Separate assignment and usage of a surface context from that of a context.
- Rename `GLContextEGL::mConfig` to `mSurfaceConfig` to better reflect its usage; it's only ever
used to create surfaces, not contexts.
Split out from @jgilbert's D164308 and D164309.
[`EGL_KHR_no_config_context` extension]: https://registry.khronos.org/EGL/extensions/KHR/EGL_KHR_no_config_context.txt
[incoming-breakage]: ad8e4d99a9
[what-will-be-broken]: https://searchfox.org/mozilla-central/rev/b19830c6b22f73758862d34d2c64f57735890e90/gfx/webrender_bindings/RenderCompositorANGLE.cpp#668
Differential Revision: https://phabricator.services.mozilla.com/D166708
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
When available, we should use the [`EGL_KHR_no_config_context` extension] inside of
`GLContextEGL::CreateEGLPBufferOffscreenContext`. The usage of this extension will be necessary to
accommodate incoming upstream changes in ANGLE, which have [migrated away][incoming-breakage] from
[our usage of `EGL_FLEXIBLE_SURFACE_COMPATIBILITY_SUPPORTED_ANGLE` in
`gfx/webrender_bindings/RenderCompositorANGLE.cpp`][what-will-be-broken] in favor of this standard
extension. Luckily it's forwards-compatible to start consuming it now!
This revision changes a few things that are linked:
- Separate assignment and usage of a surface context from that of a context.
- Rename `GLContextEGL::mConfig` to `mSurfaceConfig` to better reflect its usage; it's only ever
used to create surfaces, not contexts.
Split out from @jgilbert's D164308 and D164309.
[`EGL_KHR_no_config_context` extension]: https://registry.khronos.org/EGL/extensions/KHR/EGL_KHR_no_config_context.txt
[incoming-breakage]: ad8e4d99a9
[what-will-be-broken]: https://searchfox.org/mozilla-central/rev/b19830c6b22f73758862d34d2c64f57735890e90/gfx/webrender_bindings/RenderCompositorANGLE.cpp#668
Differential Revision: https://phabricator.services.mozilla.com/D166708
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
Due to a bug on versions of Android prior to 8.0, attempting to create
a SurfaceTexture from an isolated process results in an infinite
hang. We must therefore avoid doing this.
We currently create a dummy SurfaceTexture in order to call the
Surface constructor when instantiating a GeckoSurface from a
Parcel. This patch avoids this by making GeckoSurface own a Surface
rather than inherit from one.
Additionally, for every Surface allocated we create a corresponding
"sync" SurfaceTexture in the content processes. This is used when the
texture data is required in the content process, eg using video as a
WebGL texture upload source. This patch prevents us allocating such
SurfaceTextures. If out-of-process WebGL is enabled, video data can
still be used as a texture upload source as WebGL resides in the GPU
process. However, if out-of-process WebGL is disabled the texture
upload will fail.
Prior to shipping isolated content processes on affected Android
versions, we must therefore ensure we have an alternative solution to
using video as a WebGL texture upload source, or that out-of-process
WebGL can be relied upon.
Differential Revision: https://phabricator.services.mozilla.com/D165970
Due to a bug on versions of Android prior to 8.0, attempting to create
a SurfaceTexture from an isolated process results in an infinite
hang. We must therefore avoid doing this.
We currently create a dummy SurfaceTexture in order to call the
Surface constructor when instantiating a GeckoSurface from a
Parcel. This patch avoids this by making GeckoSurface own a Surface
rather than inherit from one.
Additionally, for every Surface allocated we create a corresponding
"sync" SurfaceTexture in the content processes. This is used when the
texture data is required in the content process, eg using video as a
WebGL texture upload source. This patch prevents us allocating such
SurfaceTextures. If out-of-process WebGL is enabled, video data can
still be used as a texture upload source as WebGL resides in the GPU
process. However, if out-of-process WebGL is disabled the texture
upload will fail.
Prior to shipping isolated content processes on affected Android
versions, we must therefore ensure we have an alternative solution to
using video as a WebGL texture upload source, or that out-of-process
WebGL can be relied upon.
Differential Revision: https://phabricator.services.mozilla.com/D165970
Previously we were querying the current ARRAY_BUFFER_BINDING, which
would fail if you did:
```
BindBuffer(ARRAY_BUFFER, a)
VertexAttribPointer(...)
BindBuffer(ARRAY_BUFFER, b)
```
We would assume we should call VeretxAttribPointer again with `b` bound,
when we need to bind `a` instead.
Unfortunately, this is hard to test, and we only hit this on drivers
where we don't use VAOs, which are rare now.
Differential Revision: https://phabricator.services.mozilla.com/D164744
The change addressed followings problems.
- Recycling of gl::SharedSurface by RemoteTextureMap is not handled by gl::SwapChain.
- PrepareForUse()/NotifyNotUsed() of remote texture's TextureHost(SurfaceTextureHost) is not handled
- Wrapping of RenderAndroidSurfaceTextureHost by RenderTextureHostWrapper is not handled
PrepareForUse()/NotifyNotUsed() is called based on compositor ref count of TextureHost. Normally TextureHost is wrapped by WebRenderTextureHost, then the WebRenderTextureHost handles PrepareForUse()/NotifyNotUsed(). But in remote texture case, WebRenderTextureHost wraps RemoteTextureHostWrapper. And compositable ref of remote texture's TextureHost is updated within RemoteTextureMap::mMutex. Then PrepareForUse()/NotifyNotUsed() happen outside of WebRenderTextureHost in non compositor thread.
With pref gfx.canvas.accelerated=true, canvas renderings were broken on android emulator. The boroken rendering seemed to happen by GL of android emulator. The boroken rendering did not happen with tests on android hardware.
Differential Revision: https://phabricator.services.mozilla.com/D159261
Also scale back some asserts from debug-fatal to just warnings, because
I kept hitting them during testing because of our poor surface lifetime
handling.
Differential Revision: https://phabricator.services.mozilla.com/D157993
When GtkWidget is hidden, underlying wl_surface is deleted. We need to also update EGLSurface of GtkWidget (GtkCompositorWidget)
as EGLSurface is directly linked to wl_surface:
- When GtkWidget is hidden, call GtkCompositorWidget::DisableRendering(). That releases GtkCompositorWidget resources
related to GtkWidget (XWindow/XVisual etc.) and marks the widget as hidden.
- If GtkWidget is backed by EGL call compositor resume which forces compositor to create new EGLSurface.
- Make sure GLContextEGL can create EGLSurface even when GtkWidget is hidden and wl_surface is missing.
It prevents fallback to SW rendering or pause RenderCompositorEGL which leads to Bug 1777664 (whole browser UI freeze).
- Return early from RenderCompositorEGL::BeginFrame()/RenderCompositorEGL::EndFrame() when GtkCompositorWidget is hidden.
Depends on D157357
Differential Revision: https://phabricator.services.mozilla.com/D157358
When GtkWidget is hidden, underlying wl_surface is deleted. We need to also update EGLSurface of GtkWidget (GtkCompositorWidget)
as EGLSurface is directly linked to wl_surface:
- When GtkWidget is hidden, call GtkCompositorWidget::DisableRendering(). That releases GtkCompositorWidget resources
related to GtkWidget (XWindow/XVisual etc.) and marks the widget as hidden.
- If GtkWidget is backed by EGL call compositor resume which forces compositor to create new EGLSurface.
- Make sure GLContextEGL can create EGLSurface even when GtkWidget is hidden and wl_surface is missing.
It prevents fallback to SW rendering or pause RenderCompositorEGL which leads to Bug 1777664 (whole browser UI freeze).
- Return early from RenderCompositorEGL::BeginFrame()/RenderCompositorEGL::EndFrame() when GtkCompositorWidget is hidden.
Depends on D157357
Differential Revision: https://phabricator.services.mozilla.com/D157358
On Android, SurfaceTextures provide a transform matrix that should be
applied to texture coordinates when sampling from the texture. Prior
to bug 1731980 we ignored this value, and simply y-flipped the video
instead. On most devices the transform is just a y-flip, so this
produced the correct results. However, on some devices the transform
included a scale as well as the y-flip, meaning that we rendered
videos at an incorrect size.
The fix for bug 1731980 was to correctly apply the transformation.
However, it now appears that on Mediatek 6735 devices the transform
provided by the system is incorrect. On these devices, videos were
rendered correctly when we ignored the transform and just did a
y-flip, and now that we apply the transform videos are rendered at the
wrong size.
This patch makes it so that we override the system-provided transform
on these devices with a simple y-flip. The existing mIgnoreTransform
flag has been changed to an optional "transform override" value to
achieve this. We ensure that we only override the transform for
SurfaceTextures that are output from a MediaCodec, to ensure that we
don't accidentally apply the wrong transform to SurfaceTextures
attached to other sources.
Differential Revision: https://phabricator.services.mozilla.com/D155706
In this patch, we ask the media engine to return a handle for shareable
dcomp surface, which will then be packaged into a new texture data type
and being shared with the GPU process via the video bridge.
DcompSurfaceImage is the image which contains the handle texture data,
which doesn't support being accessed in the content process. When the
compositor uploads the image to the GPU process, the corresponding
texture host will be created.
The render texture host will be created by that texture host, and it
will be used in DCLayerTree. In DCLayerTree, we create a new type of
surface for our dcomp handle. DCSurfaceHandle will ask the render
texture host to reconstruct the surface by the handle shared from the
remote process (the handle is actually duplicated to the parent process
first due to the sandbox policy, and then be duplicated to the GPU
process later)
DCSurfaceHandle will attach that surface to its visual in order to
display the video frame directly. In the whole process, it's not
possible for Gecko to access any decoded video data which is protected by the
media engine itself.
Depends on D149941
Differential Revision: https://phabricator.services.mozilla.com/D151019
Addresses a coverity warning. The problem looks very benign but the work around is simple and it's good to keep the volume static analysis warnings in check.
Differential Revision: https://phabricator.services.mozilla.com/D152525
Currently CopyToSwapChain creates spurious copies of the back buffer when SharedSurfaces aren't exportable (= ToSurfaceDescriptor returns Nothing from SharedSurface_Basic). These then later get read back into a CPU memory buffer when PresentFrontBufferToCompositor is used to send the buffer to RemoteTextureMap. This has associated performance and memory costs.
Conceptually, we want Present/CopyToSwapChain to just do the right thing and automatically push buffers to RemoteTextureMap, rather than secondarily needing a hidden call to PresentFrontBufferToCompositor. Then we can get rid of the need to create front buffers whose only purpose is to shuttle data to PresentFrontBufferToCompositor which then shuttles it RemoteTextureMap.
This patch achieves this by refactoring the guts of PresentFrontBufferToCompositor into Present/CopyToSwapChain. The remote texture ids are sent along inside SwapChainOptions if async present is enabled. Those remote texture ids are cached in ClientWebGLContext so that GetFrontBuffer can return them without any subsequent need for an IPDL call.
On the parent side, CopyToSwapChain will now notice if async present is to be used and if a SurfaceFactory does not generate SharedSurfaces that can be exported. In that case it cuts out the middle man and reads from the WebGLFramebuffer's back buffer directly into a CPU buffer to send to RemoteTextureMap.
This also adds a forceAsyncPresent option to SwapChainOptions so that in the future we can have a separate pref for Accelerated Canvas2D that will allow enabling async present independent of the global WebGL pref.
Differential Revision: https://phabricator.services.mozilla.com/D150720
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
stransky
Cristian Tuns
Brad Werth
Emilio Cobos Álvarez
Cristina Horotan
Natalia Csoregi
Jamie Nicol
Kelsey Gilbert
Noemi Erli
serge-sans-paille
Stanca Serban
Norisz Fay
sotaro
Jeff Muizelaar
Erich Gubler
Marian-Vasile Laza
Marco Castelluccio
Butkovits Atila
alwu
Sandor Molnar
Lee Salzman
Fabrice Desré
Andreea Pavel
Iulian Moraru
Nicolas Silva
Owen Rafferty
Narcis Beleuzu
Kelsey Gilbert
criss
Robert Mader
Sylvestre Ledru
Ashley Hale