This reverts commit e25a5f344af32bdd689500bae7b4f24f205ba9f0.
We believe bug 1664063 was causing to hit some broken device reset
handling code.
Differential Revision: https://phabricator.services.mozilla.com/D201658
CopyToSwapChain was silently failing, causing no texture to get pushed
to RemoteTextureMap, so that when a wait on it was occurring, it would
timeout.
The failure occurred in DrawTargetWebgl::FlushFromSkia, because the
DT's size actually exceeded the value of the texture limit pref when
it was attempting to allocate a temporary texture to blend back a
Skia layer to the WebGL framebuffer. This is fixed by allowing layering
to bypass this limit, as it is always expected that layer blending
succeed.
To guard against future instances of this bug, CopyToSwapChain now returns
a boolean result so that it is fallible and can signal to CanvasTranslator
that it needs to take appropriate fallback measures on failure.
Differential Revision: https://phabricator.services.mozilla.com/D199794
During testing Bug 1863257, there were cases that test failed with timeout in RemoteTextureMap::WaitRemoteTextureReady(). In this case, RemoteTextureOwner was not registered since first Surface allocation was failed at GeckoProcessManager.getSurfaceAllocator().
Even with the case, RemoteTextureOwner should be registered as context lost.
Differential Revision: https://phabricator.services.mozilla.com/D199312
It looks like we're accidentally putting SharedSurfaces that came from a different
SurfaceFactory back into a different one recycling. This happens because on context
loss in CanvasTranslator, the old GL context may go away, though the RemoteTextureOwnerClient
has a shared recycling bin that might accidentally keep the old surfaces.
This also tries to clear the old recycled surfaces as soon as possible on a context
loss now.
Differential Revision: https://phabricator.services.mozilla.com/D198918
When a context loss occurs on DrawTargetWebgl, this may result in a fallback TextureData
being created. Each of these are currently managed by two different RemoteTextureOwnerClients.
This is not really safe at all.
To fix this, CopyToSwapChain is modified so that it can be supplied a RemoteTextureOwnerClient.
Then CanvasTranslator can inject its own RemoteTextureOwnerClient into CopyToSwapChain, rather
than letting CopyToSwapChain use its own separate internal RemoteTextureOwnerClient.
This also tries to address a few other data consistency bugs with the fallback TextureData.
Differential Revision: https://phabricator.services.mozilla.com/D198487
This was a change for bug 1872087 that somehow got lost when I was rebasing. The idea
here is that DrawTargetWebgls use a single shared WebGL context, so it makes sense for
them to share recycle texture data, much like CanvasTranslator shares recycling of
texture data for D2D. This should increase the efficiency of use-cases that create and
destroy a lot of canvases every frame and would not normally benefit from recycling.
Depends on D197375
Differential Revision: https://phabricator.services.mozilla.com/D197376
This was a change for bug 1872087 that somehow got lost when I was rebasing. The idea
here is that DrawTargetWebgls use a single shared WebGL context, so it makes sense for
them to share recycle texture data, much like CanvasTranslator shares recycling of
texture data for D2D. This should increase the efficiency of use-cases that create and
destroy a lot of canvases every frame and would not normally benefit from recycling.
Depends on D197375
Differential Revision: https://phabricator.services.mozilla.com/D197376
Since we're not using WebGL remoting, we no longer have direct knowledge of the pid across
the IPDL gap inside WebGLContext. This must be explicitly passed in.
Differential Revision: https://phabricator.services.mozilla.com/D194348
DrawTargetWebgl will use WebGLContext in a direct, non-networked capacity. Currently
there are only a few places WebGLContext actually checks for a host context, and those
are easily stubbed our or made conditional.
Differential Revision: https://phabricator.services.mozilla.com/D194347
When we call IDXGIKeyedMutex::AcquireSync, we need to check for a
general failure, WAIT_ABANDONED and WAIT_TIMEOUT. The last two are
special because Microsoft's SUCCEEDED and FAILED macros consider them
successful.
Differential Revision: https://phabricator.services.mozilla.com/D196668
Since we're not using WebGL remoting, we no longer have direct knowledge of the pid across
the IPDL gap inside WebGLContext. This must be explicitly passed in.
Differential Revision: https://phabricator.services.mozilla.com/D194348
DrawTargetWebgl will use WebGLContext in a direct, non-networked capacity. Currently
there are only a few places WebGLContext actually checks for a host context, and those
are easily stubbed our or made conditional.
Differential Revision: https://phabricator.services.mozilla.com/D194347
This patch makes it so that WebGL that runs in the compositor process
can take advantage of the fact that GPUVideoImage should have an already
created TextureHost between the compositor process and the producing
utility process. For software decoders, this will allow us to avoid a
copy into a shmem from the utility process, and another copy into a
shmem to the compositor process.
Differential Revision: https://phabricator.services.mozilla.com/D195559
Since we're not using WebGL remoting, we no longer have direct knowledge of the pid across
the IPDL gap inside WebGLContext. This must be explicitly passed in.
Differential Revision: https://phabricator.services.mozilla.com/D194348
DrawTargetWebgl will use WebGLContext in a direct, non-networked capacity. Currently
there are only a few places WebGLContext actually checks for a host context, and those
are easily stubbed our or made conditional.
Differential Revision: https://phabricator.services.mozilla.com/D194347
This allows for disabling WebGL's use of GL_KHR_no_error, rather than the default of enabled.
Use snake_case so that searching for KHR_no_error finds this more
easily.
Differential Revision: https://phabricator.services.mozilla.com/D188781
SharedSurface_DMABUF::ToSurfaceDescriptor() could return Nothing() with error. It needs to be handled as failure.
SharedSurface::ToSurfaceDescriptor() is expected to return Nothing() only with SharedSurface_Basic.
Differential Revision: https://phabricator.services.mozilla.com/D188078
Currently WebGL on the GTK backend constantly creates new DMAbuf
surfaces for every frame, causing high CPU usage (Bug 1848171). At
60fps on a high-end Intel CPU this uses 50% of a core. On a Raspberry Pi
4 this uses around 100% of a core and limits FPS to about 50.
This patch allows DMABufSurfaces to be recycled and so greatly reduces
CPU usage on WebGL content (on a Raspberry Pi 4 this halves the CPU
usage on https://www.testufo.com/stutter#demo=smooth&foreground=ffffff&background=000000&pps=720
This patch was originally authored by Sotaro Ikeda but did not solve
their problem, I am co-opting it to fix Bug 1848171.
Differential Revision: https://phabricator.services.mozilla.com/D186223
When WebGL context is lost, we could not expect that pending remote texture becomes ready. We do not need to wait the remote texture ready.
Differential Revision: https://phabricator.services.mozilla.com/D180303
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
