Closed Bug 1541029 Opened 5 years ago Closed 3 years ago

Remove accelerated api use from content - VideoData::CreateAndCopyData

Categories

(Core :: Audio/Video, defect, P3)

Unspecified
Windows 10
defect

Tracking

()

RESOLVED FIXED

People

(Reporter: jimm, Unassigned)

References

Details

We're picking up calls like this to d3d11 surfaces in ffmpeg library. For win32k lockdown this will have to move to another process or get removed.

https://searchfox.org/mozilla-central/rev/201450283cddc9e409cec707acb65ba6cf6037b1/dom/media/MediaData.cpp#352

This appears isolated from the actual decoding library. So maybe there's a way to move away from this without moving/modifying media decoding lobraries. Nils, any thoughts?

typical stack:
win32u!NtGdiDdDDIUnlock
win32u!NtGdiDdDDIUnlock
d3d11!CallAndLogImpl<long
d3d11!NDXGI::CDevice::UnlockCB
vm3dum64_10
vm3dum64_10
vm3dum64_10
d3d11!NDXGI::CDevice::Flush
d3d11!NDXGI::CDevice::ResolveSharedResourceImpl
d3d11!NDXGI::CDevice::DXGIReleaseSync
xul!mozilla::layers::AutoLockD3D11Texture::~AutoLockD3D11Texture
xul!mozilla::layers::D3D11YCbCrImage::SetData
xul!mozilla::VideoData::CreateAndCopyData
xul!mozilla::FFmpegVideoDecoder<46465650>::CreateImage
xul!mozilla::FFmpegVideoDecoder<46465650>::DoDecode
xul!mozilla::FFmpegDataDecoder<46465650>::DoDecode

Flags: needinfo?(drno)
Priority: -- → P3
Summary: Remove accelerated api use from content - ffmpeg → Remove accelerated api use from content - VideoData::CreateAndCopyData

This code is a performance optimization, since uploading directly to a GPU texture saves a copy (normally we copy to shmem, and then still have the same upload in the compositor process). It has a significant impact when trying to decode 4k video in software.

Depending on what sandboxing we want for other processes, we could do similar things in the RDD process or GPU process, and try decode in those places more often.

We could also just drop it if necessary, but it's definitely not free.

Flags: needinfo?(drno)
No longer blocks: win32k-lockdown

Yeah I think Matt is right that in the long run we want to consider having a fast path between the RDD process and the GPU process. But I think that is still some time out as it will takes us some time to move codecs over the RDD process.

Jean-Yves do you have any thoughts on this?

Flags: needinfo?(jyavenard)

Why would you want to remove it? What problems does it cause?

Removing it will be at the expense of speed and CPU usage.

Long term it will no longer be called from the content process, only the GPU and RDD process, but for now must software decoding is done in the content process.

Flags: needinfo?(jyavenard)

(In reply to Jean-Yves Avenard [:jya] from comment #4)

Why would you want to remove it? What problems does it cause?

Removing it will be at the expense of speed and CPU usage.

Long term it will no longer be called from the content process, only the GPU
and RDD process, but for now must software decoding is done in the content
process.

These classes use accelerated apis which call win32k sys calls under the hood. When we flip the win32k lockdown switch for content these apis will all fail.

I think this was fixed by bug 1595994.

Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.