This is just a renaming patch, motivated by a need for clarity before
addding more YUV formats. Comments and log messages are updated as well,
and one function in MacIOSurface is renamed.
There is one small change in TextureHost.cpp to satisfy clang-tidy.
Differential Revision: https://phabricator.services.mozilla.com/D217883
By default, hardware video decoder uses compositor device for D3D11Device. In this case, mSyncObject->Synchronize() in RenderCompositorANGLE::BeginFrame() is not necessary.
When ID3D11Texture2D is created by compositor device, the Synchronize() is not necessary.
Differential Revision: https://phabricator.services.mozilla.com/D201693
Normally when D3D11Texture2D is copied by ID3D11DeviceContext::CopySubresourceRegion() with compositor device, WebRender does not need to wait copy complete, since WebRender also uses compositor device.
But with Non-intel GPUs(like NDIVIA), there is a case that the copy complete need to be wait explicitly even with compositor device
mSyncObject->Synchronize() could not be used with compositor device.
Wait of the query is not called in D3D11DXVA2Manager::CopyToImage(), since the wait could take long time. Then the Wait of the query is deferred to just before blitting for video overlay.
Differential Revision: https://phabricator.services.mozilla.com/D200041
gecko uses IDXGIResource::GetSharedHandle(). But it is recommend not to use anymore to retrieve the handle to a shared resource.
IDXGIResource1::CreateSharedHandle() with D3D11_RESOURCE_MISC_SHARED_NTHANDLE flag should be used instead of the GetSharedHandle().
The CreateSharedHandle() could be called only once for a shared resource. Later calls fail.
HANDLEs of ID3D11Texture2D are replaced by gfx::FileHandleWrappers.
Differential Revision: https://phabricator.services.mozilla.com/D192173
The change is a preparation for Bug 1865984, Bug 1863474 and Bug 1861605.
FenceD3D11 is going to be used by Bug 1865984 and Bug 1863474. And FileHandleWrapper is going to be added for wrapping shared handle of ID3D11Fence and ID3D11Texture2D(Bug 1861605).
For now, FenceInfo is expected to be delivered just during creating TextureHost. It works for WebGL and WebGPU.
Differential Revision: https://phabricator.services.mozilla.com/D194612
The change is a preparation for Bug 1865984, Bug 1863474 and Bug 1861605.
FenceD3D11 is going to be used by Bug 1865984 and Bug 1863474. And FileHandleWrapper is going to be added for wrapping shared handle of ID3D11Fence and ID3D11Texture2D(Bug 1861605).
For now, FenceInfo is expected to be delivered just during creating TextureHost. It works for WebGL and WebGPU.
Differential Revision: https://phabricator.services.mozilla.com/D194612
WindowsHandle exists for ipc. And we normally use HANDLE in Windows only code. We do not need to use both WindowsHandle and HANDLE in Windows only code.
This is a preparation for Bug 1861605.
Differential Revision: https://phabricator.services.mozilla.com/D192811
SyncObjectD3D11Host::Synchronize() could spend time when GPU is busy.
The Synchronize() call is not necessary when all RenderDXGITextureHosts have GpuProcessTextureId or KeyedMutex.
Differential Revision: https://phabricator.services.mozilla.com/D185619
Current gecko enables "software decoded video overlay" only when "hardware decoded video overlay" is enabled. On current release, "hardware decoded video overlay" is not enabled yet with non-Intel GPU, then "software decoded video overlay" is not yet enabled on release. It is not good. We want to enable "software decoded video overlay" independently from "hardware decoded video overlay". Then settings of video overlay is split between "hardware decoded video overlay" and "software decoded video overlay". Then "software decoded video overlay" could be enabled/disabled independently from status of "hardware decoded video overlay".
* settings of hardware decoded video overlay
- nsIGfxInfo::FEATURE_VIDEO_OVERLAY:
- gfx.webrender.dcomp-video-hw-overlay-win
- gfx.webrender.dcomp-video-hw-overlay-win-force-enabled
- gfxVars::UseWebRenderDCompVideoHwOverlayWin()
* settings of software decoded video overlay
- nsIGfxInfo::FEATURE_VIDEO_SOFTWARE_OVERLAY
- gfx.webrender.dcomp-video-sw-overlay-win
- gfx.webrender.dcomp-video-sw-overlay-win-force-enabled
- gfxVars::UseWebRenderDCompVideoSwOverlayWin()
Differential Revision: https://phabricator.services.mozilla.com/D175993
If an external image shows up multiple times while using a different image rendering
setting on each instance, we can erroneously call handler.lock() for each instance in
parallel, thus defaulting to the last image rendering setting supplied for all instances
in that batch.
To work around this, we get rid of the concept of having RenderTextureHosts maintain and
set the image rendering state, which results in a nice simplification. Then, when we go
to actually bind an external image inside WebRender, we set the image rendering state
at that point, so that regardless of how many instances of an external image are locked
simultaneously, we always use the correct image rendering setting for a batch.
Differential Revision: https://phabricator.services.mozilla.com/D158920
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
This is a preparation of Bug 1723207.
D3D11TextureIMFSampleImage is used for storing ID3D11Texture2D of IMFSample. Array index handling is added, since there are cases that hardware decoder uses array texture. D3D11TextureIMFSampleImage is expected to be used in GPU process.
Differential Revision: https://phabricator.services.mozilla.com/D140017
+ Begin to add video tests to ensure we ratchet towards correctness.
+ Test rec709 x (yuv420p, yuv420p10, gbrp) x (tv, pc) x codecs.
+ Just mark fuzziness for now. Better would be e.g. 16_127_233 'bad
references'.
Differential Revision: https://phabricator.services.mozilla.com/D115298
+ Begin to add video tests to ensure we ratchet towards correctness.
+ Test rec709 x (yuv420p, yuv420p10, gbrp) x (tv, pc) x codecs.
+ Just mark fuzziness for now. Better would be e.g. 16_127_233 'bad
references'.
Differential Revision: https://phabricator.services.mozilla.com/D115298
+ Begin to add video tests to ensure we ratchet towards correctness.
+ Test rec709 x (yuv420p, yuv420p10, gbrp) x (tv, pc) x codecs.
+ Just mark fuzziness for now. Better would be e.g. 16_127_233 'bad
references'.
Differential Revision: https://phabricator.services.mozilla.com/D115298
+ Begin to add video tests to ensure we ratchet towards correctness.
+ Test rec709 x (yuv420p, yuv420p10, gbrp) x (tv, pc) x codecs.
+ Just mark fuzziness for now. Better would be e.g. 16_127_233 'bad
references'.
Differential Revision: https://phabricator.services.mozilla.com/D115298
