Closed Bug 1301615 Opened 8 years ago Closed 8 years ago

Hw decoding block from bug 1267970 should have been restricted to win10

Categories

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

49 Branch
All
Windows
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla51
Tracking Status
firefox49 --- wontfix
firefox50 --- fixed
firefox51 --- fixed

People

(Reporter: mozbugz, Assigned: mozbugz)

References

Details

Crash Data

Attachments

(2 files)

Bug 1267970 is blocking hardware video decoding for a range of ATI drivers across all Windows OS's, but the reports (and signature itself) show that this problem only exists on Windows 10.
Pushed by gsquelart@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/2d621742ba6c
Restrict block from bug 1267970 to win10 - r=kentuckyfriedtakahe
Comment on attachment 8789685 [details]
Bug 1301615 - Restrict block from bug 1267970 to win10 -

Approval Request Comment
[Feature/regressing bug #]: bug 1267970
[User impact if declined]: windows <10 users may fall back to sw decoding when unnecessary
[Describe test coverage new/current, TreeHerder]: Existing media test, try: https://treeherder.mozilla.org/#/jobs?repo=try&revision=98ae6435a27d7917ebea890ecd44d5394c9550bc
[Risks and why]: Even lower than for bug 1267970, as the blocking is more restricted than before
[String/UUID change made/needed]: None
Attachment #8789685 - Flags: approval-mozilla-aurora?
Rebase for beta only (the other patch applies to aurora as-is); carrying r+.

Approval Request Comment
[Feature/regressing bug #]: bug 1267970
[User impact if declined]: windows <10 users may fall back to sw decoding when unnecessary
[Describe test coverage new/current, TreeHerder]: Existing media test, try: https://treeherder.mozilla.org/#/jobs?repo=try&revision=b276856bc99821e8f17a1f969781b6f2f8de1e8f
[Risks and why]: Even lower than for bug 1267970, as the blocking is more restricted than before
[String/UUID change made/needed]: None
Attachment #8789729 - Flags: review+
Attachment #8789729 - Flags: approval-mozilla-beta?
Comment on attachment 8789729 [details] [diff] [review]
1301615-beta.patch

Restricting the block sounds good. Thanks for catching this. 
Let's uplift this for RC3.
Attachment #8789729 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
Is there people crashing with driver 15.301.1901 and Radeon cards series <= 7000 or <= 7600?
If not, I suggest reducing block to exclude that version (which is the last for newest 'legacy' cards); it is supposed to work in Win 10 too.
Or block only affected range of cards.
Please look at http://support.amd.com/en-us/kb-articles/Pages/AMD-Radeon-Software-Crimson-Edition-16.2.1-for-Non-GCN-Products-Release-Notes.aspx for exact model numbers.

Thanks.
With that driver version 15.301.1901, we have crash reports for these device IDs:
0x9830 AMD Radeon HD 8400
0x9851 AMD Radeon R4 Graphics
0x6658 AMD Radeon R7 200 Series
0x67b0 AMD Radeon R9 200 Series
0x9838 AMD Radeon HD 8240
0x983d AMD Radeon HD 8250
(Found handy list there: http://developer.amd.com/resources/ati-catalyst-pc-vendor-id-1002-li/ )

Paul, in bug 1267970 comment 81 you talk about "non Win10-targeted drivers for non-GCN devices", would you have suggestions on how to decide whether I should block that driver version (for video decoding) or let it be used?
Flags: needinfo?(paul.blinzer)
Looks like only newer devices that can use up-to-date drivers. Then, my suggestion would be to block by device range and driver, excluding non-gcn ones with driver 15.301.1901 ("16.2.1") or 15.20.1062​ ("15.7.1", which is the last non-beta driver for these cards).
Thank you Ricardo.
But the difficulty (for me at least) would be to know which devices are GCN or not; is there an easy way to know, or a comprehensive list somewhere?
If you compare the Product Family Compatibility tables of the release notes for the old driver with the new you can find the model ranges; if you need to block by Device ID or something else I have no idea how to help, sorry.
Old (Non-GCN): http://support.amd.com/en-us/kb-articles/Pages/AMD-Radeon-Software-Crimson-Edition-16.2.1-for-Non-GCN-Products-Release-Notes.aspx
Current models: http://support.amd.com/en-us/kb-articles/Pages/Radeon-Software-Crimson-Edition-16-9-1-Release-Notes.aspx
"How-To Identify the Manufacturer and Model of an AMD Graphics Card"
http://support.amd.com/en-us/kb-articles/Pages/HowtoidentifythemodelofanATIgraphicscard.aspx
In this article they point http://pcidatabase.com/ as another place to find Device IDs.
https://hg.mozilla.org/mozilla-central/rev/2d621742ba6c
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla51
(In reply to Ricardo from comment #9)
> Looks like only newer devices that can use up-to-date drivers. Then, my
> suggestion would be to block by device range and driver, excluding non-gcn
> ones with driver 15.301.1901 ("16.2.1") or 15.20.1062​ ("15.7.1", which is
> the last non-beta driver for these cards).

I suppose I could just unblock these two specific driver version for all devices, as:
- There are only 8 crashes out of 33713 this year -- and judging from the detailed reports, probably only really 3 people were affected on FF47.
- Non-GCN devices have only crashed once in FF47, and their drivers cannot be upgraded anyway.
- GCN devices have an upgrade path.

Anthony, what do you think?
Flags: needinfo?(ajones)
(In reply to Gerald Squelart [:gerald] from comment #14)
> Anthony, what do you think?

The upside of blocking hardware H.264 decoding is that we enable MSE/VP9. The crash numbers are most likely to under reported so I don't want to obsess too much about them. I'm not swayed very much by the lack of an upgrade path on the basis that users rarely upgrade anyway, and that software decode is actually pretty good. Accelerated layers makes a much bigger difference to overall playback performance than hardware vs software decode.

Our numbers tell us that most CPUs are capable of decoding video so we are choosing stability and network performance over power consumption. Don't forget that we've got the worlds fastest VP9 decoder.

I'm happy with software decode on GPUs that crash until we get the out of process decoding up and running. The first patches for that have already started landing in nightly.
Flags: needinfo?(ajones)
Anthony,

While CPU playback for 1080p is a possibility due to a fast SW decoder, there's notable battery impact with SW decode on the affected devices for notebooks, let alone that on some lower-end machines this may affect user experience for higher resolution playback on Firefox with common use scenarios (doing some limited multitasking or multiple tabs open while playback runs in background) vs HW 264 decode.
Even if crashes may be under-reported, it must be huge underreport if one reported crash indicates a sizeable amount of systems not reported. That would indicate more substantial concern in the field report process then. 

I understand playing it safe, but this seems too limiting to the majority of users that would be able to update their drivers if they run into this problem. 

As for the list, I see that the links I would have suggested already have been referenced. So don't think I can add to that conversation.
Flags: needinfo?(paul.blinzer)
Argh this did not make it onto m-r as it should have.
Sorry, this missed the RC3 build.
Please place commit at mozilla-release, for next 49.x build and tinderbox builds.
Otherwise "media.hardware-video-decoding.force-enabled" or "layers.acceleration.force-enabled" will be another setting people will need to change to workaround unfriendly changes. Too many recent breakages for a browser that once tried to be friendly.
Comment on attachment 8789685 [details]
Bug 1301615 - Restrict block from bug 1267970 to win10 -

Seems like a good idea, Aurora50+
Attachment #8789685 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: