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)
Tracking
()
RESOLVED
FIXED
mozilla51
People
(Reporter: mozbugz, Assigned: mozbugz)
References
Details
Crash Data
Attachments
(2 files)
58 bytes,
text/x-review-board-request
|
ajones
:
review+
ritu
:
approval-mozilla-aurora+
|
Details |
2.35 KB,
patch
|
mozbugz
:
review+
lizzard
:
approval-mozilla-beta+
|
Details | Diff | Splinter Review |
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.
Comment hidden (mozreview-request) |
Comment 2•8 years ago
|
||
mozreview-review |
Comment on attachment 8789685 [details] Bug 1301615 - Restrict block from bug 1267970 to win10 - https://reviewboard.mozilla.org/r/77820/#review76204
Attachment #8789685 -
Flags: review?(ajones) → review+
Pushed by gsquelart@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/2d621742ba6c Restrict block from bug 1267970 to win10 - r=kentuckyfriedtakahe
Assignee | ||
Comment 4•8 years ago
|
||
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?
Assignee | ||
Comment 5•8 years ago
|
||
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 6•8 years ago
|
||
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.
Assignee | ||
Comment 8•8 years ago
|
||
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).
Assignee | ||
Comment 10•8 years ago
|
||
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?
Comment 11•8 years ago
|
||
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
Comment 12•8 years ago
|
||
"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.
Comment 13•8 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/2d621742ba6c
Status: NEW → RESOLVED
Closed: 8 years ago
status-firefox51:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla51
Assignee | ||
Comment 14•8 years ago
|
||
(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)
Comment 16•8 years ago
|
||
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)
Comment 17•8 years ago
|
||
Argh this did not make it onto m-r as it should have.
Comment 18•8 years ago
|
||
Sorry, this missed the RC3 build.
status-firefox49:
--- → wontfix
status-firefox50:
--- → affected
Comment 19•8 years ago
|
||
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+
Comment 21•8 years ago
|
||
bugherder uplift |
https://hg.mozilla.org/releases/mozilla-aurora/rev/0e5cc34aa8b4
You need to log in
before you can comment on or make changes to this bug.
Description
•