Potential texture locking deadlock when decoding multiple videos at once
Categories
(Core :: Audio/Video: Playback, defect, P2)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox83 | --- | fixed |
People
(Reporter: jya, Assigned: jya)
References
Details
Attachments
(1 file)
Saw this while working on bug 1595994.
When running the test media-source/mediasource-changetype-play-without-codecs-parameter.html and with the Windows H264 decodering running in the RDD process we will crash as locking the texture will timeout.
The reason for this is a combination of factors where when running outside of the GPU process we will always use a SyncObjectClient to synchronise the structures, and reusing the same device across all decoders.
While following bug 1595994 the h264 decoding will be done in the RDD, today it is possible for the decoding to be done in the content process.
This will be the case on system where the GPU process is disabled such as with Windows 8 and earlier.
The reason for this is that when copying the decoded surface into a new one, we use a SyncObjectClient that will lock the device. All those SyncObjectClient use the same HANDLE.
So with AMD, we will lock the same device, using the same HANDLE across multiple thread and multiple processes.
And we see deadlocks.
|
Assignee | |
Updated•4 years ago
|
|
|
Assignee | |
Comment 1•4 years ago
|
||
Attempt to lock textures from the same D3D11 devices on multiple threads at once can lead to deadlocks as observed with AMD cards.
Pushed by jyavenard@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/1e467d7ca5ff Only synchronise textures after a copy serially. r=mattwoodrow
|
||
Comment 3•4 years ago
|
||
| bugherder | ||
Description
•