Open Bug 1320054 Opened 7 years ago Updated 2 years ago

Re-evaluate DXVA D3D11 blocklist

Categories

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

53 Branch
Unspecified
Windows
defect

Tracking

()

Tracking Status
firefox53 --- affected

People

(Reporter: marco, Unassigned)

References

Details

We've built the DXVA D3D11 blocklist on beta, we should probably re-evaluate it now that it's been on release for a while.
We're currently doing it on a bug report basis (when a bug is reported, e.g. bug 1299520, we analyze and check if we should blocklist the affected driver versions), I think we should do it actively.

We should also re-evaluate the 64-bit drivers (see also bug 1315089).
Thank you for starting this, Marco.

For context, here are some of my reasons for only carefully adding specific driver versions based on crash reports:
- Some users complain when their hardware gets blocked even though they personally never experienced crashes.
- If we block wider ranges of drivers, we may hide genuine Firefox issues.
- OOP decoding (bug 1288618) should make this list completely obsolete, so we shouldn't spend more time on it than really necessary.

What kind of re-evaluation are you thinking about?

If we go ahead, we may want to also improve the blocklist syntax, as the list is now 1700+ characters long! I've got some easy-to-implement ideas, we can discuss that later...
(In reply to Gerald Squelart [:gerald] from comment #1)
> - OOP decoding (bug 1288618) should make this list completely obsolete, so
> we shouldn't spend more time on it than really necessary.

When is it going to be released?


> What kind of re-evaluation are you thinking about?

I was thinking we could simply look at the crashes we've had since we rolled out DXVA D3D11 and evaluate which additional driver versions we should add to the blocklist.
One thing about bug 1288618 and out of process video decoding - if that process crashes, the overall hardware acceleration is gone as well, not just the video decoding acceleration.  So, there is still advantage in being able to maintain a separate blocking for video only.
I talked to Matt today about adding a two stage fallback. This would allow an us to fall back to unaccelerated video but accelerated layers if the crash happens during video playback.

We need to take more risks on slow machines than we do on faster machines that have no trouble decoding video.
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.