4 years ago
Summary: No video displayed on Acer Iconia Win8 tablet with OMTC → No video displayed on Acer Iconia Win8 tablet with OMTC, Cairo, non-E10S
4 years ago
Priority: -- → P1
Milan - can you get someone to look into this? A year ago this graphics hardware wasn't blacklisted and it played full screen video beautifully.
Don't have the device, but maybe we can do something just based on the regression range - can somebody get that?
ni on marcia to check which Acer Iconia tablet she is in the QA lab.
The one I repro this on is a W510, with atom z2760 CPU.
(In reply to Marcia Knous [:marcia - use needinfo] from comment #3) > ni on marcia to check which Acer Iconia tablet she is in the QA lab. My machine in the lab is Acer Iconia W700 which has an Intel based processor.
(In reply to Milan Sreckovic [:milan] from comment #2) > Don't have the device, but maybe we can do something just based on the > regression range - can somebody get that? This will almost certainly just show the changeset where OMTC was enabled.
(In reply to Matt Woodrow (:mattwoodrow) from comment #6) > (In reply to Milan Sreckovic [:milan] from comment #2) > > Don't have the device, but maybe we can do something just based on the > > regression range - can somebody get that? > > This will almost certainly just show the changeset where OMTC was enabled. I imagine you're right, we should just try chasing it on the solution side. David, can you borrow this device from Marcia and see if you can trace the problem down? We're on a short timeline for MSE, so it'd be good to find out what's going on quickly.
Can repro pretty easily on the device. Will take a look.
Assignee: nobody → dvander
Status: NEW → ASSIGNED
FWIW, seems to work fine if I disable D3D11 and switch to the software compositor, but that doesn't match up with the original report.
The tablet is an Acer Iconia W520.
(In reply to Anthony Jones (:kentuckyfriedtakahe, :k17e) from comment #10) > The tablet is an Acer Iconia W520. No, our tablet on which the bug was reported is a W510. It has SNID 24700724865 on the side, and Acer's website lists that as a W510. http://us.acer.com/ac/en/US/content/drivers/-;24700724865;- Since dvander says he can repro on Marcia's W700, I bet the bug is not limited to only the W510.
My drivers don't seem to be blacklisted though (at least on nightly).
David, how are you disabling D3D11? With layers.prefer-d3d9 pref? As for the original device being blacklisted - I'm not sure what actually catches it, and I wonder if it's run time test.
(In reply to Milan Sreckovic [:milan] from comment #13) > David, how are you disabling D3D11? With layers.prefer-d3d9 pref? > > As for the original device being blacklisted - I'm not sure what actually > catches it, and I wonder if it's run time test. I turned layers acceleration off - but turning prefer-d3d9 to true seems to work as well, actually.
And it also looks like on Release/Beta/Aurora these drivers are blacklisted, but not on nightly.
(In reply to David Anderson [:dvander] from comment #15) > And it also looks like on Release/Beta/Aurora these drivers are blacklisted, > but not on nightly. Could be related to bug 1097321.
It looks like it wasn't a blacklist change but the fact that we use WARP now. At least, that is the reason for the nightly D3D11 bustage. Unfortunately, that is going to be a different problem from cpearce's. It looks like the tablet I have has newer drivers (from 2013). Maybe there's a way to downgrade them, but failing that, do we have any more of these lying around?
According to the model number the tablet I've got is a W3-810, and it has Windows 8.1 (not 8.0). Downgrading drivers doesn't appear to be an option. So to move forward with the original bug we'll need an older device.
Matt Woodrow has "won" an Acer Iconia tablet at the Auckland office to take back to his home :-P
With OTMC disabled, then all layers are blacklisted for this device and we end up with BasicLayers. With OMTC enabled, we're not blacklisted, and get the D3D11 compositor. In the latter configuration we're getting the hardware accelerated decoder, and we're failing in DXGITextureHostD3D11::OpenSharedShared. ID3D11Device::OpenSharedResource is returning E_INVALIDARG. Looks like switching to OMTC lost our blacklist entry, and we probably needed it. Is there any way to blacklist the decoder only, or do we need to re-blacklist layers for this device?
If you set media.windows-media-foundation.use-dxva=false, do you still get no video? We don't have a way to blacklist specific DXVA decoders; we've never needed it until now. In the past, if the HW decoder was bad we'd usually get a failure to initialize the DXVA path and we'd be able to fallback to software. What if you force Direct3D9 compositing? Does that work?
Yes, both of those changes (individually) result in working video.
What are the implications of us switching to prefer D3D9 on this device? Is it the least amount of work to get this working again? Another idea would be to set media.windows-media-foundation.use-dxva=false when we detect this failure at runtime. Or we could try to be clever and run enough of the pipeline at first start up in order to detect this failure and set the pref, so that the first video we try to play won't fail.
(In reply to David Anderson [:dvander] from comment #17) > It looks like it wasn't a blacklist change but the fact that we use WARP > now. At least, that is the reason for the nightly D3D11 bustage. Looks like this comment was entirely correct for this device too. Disabing WARP also disables d3d11 (since we're blacklisted), and the problem goes away.
Forcing WARP on my desktop seems to work fine though, so it's not a fundamental issue with DXVA and WARP. Bas, any ideas why this combination might be broken on some hardware?
Created attachment 8552051 [details] [diff] [review] Disable DXVA when using WARP We need something to uplift to beta, so I think the easiest thing to do here is to disable DXVA when using a WARP backed compositor. WARP is a CPU implementation of D3D11, so it's probably faster to use CPU decoding instead of readback anyway.
Attachment #8552051 - Flags: review?(cpearce)
Attachment #8552051 - Flags: review?(bas)
Attachment #8552051 - Flags: review?(cpearce) → review+
Comment on attachment 8552051 [details] [diff] [review] Disable DXVA when using WARP Review of attachment 8552051 [details] [diff] [review]: ----------------------------------------------------------------- I feel this is a good idea.
Attachment #8552051 - Flags: review?(bas) → review+
Status: ASSIGNED → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla38
status-firefox36: --- → affected
status-firefox37: --- → affected
status-firefox38: --- → fixed
Comment on attachment 8552051 [details] [diff] [review] Disable DXVA when using WARP Approval Request Comment [Feature/regressing bug #]: MSE [User impact if declined]: Video fails to play on some Windows devices. [Describe test coverage new/current, TreeHerder]: Landed on m-c. [Risks and why]: This touches both compositing and video playback on Windows, but it just changes the code path selected for video in certain configurations. It's a straightforward change and easy to revert. The compositor changes have no effect outside video playback. I don't think there will be any regressions, but any which occur should be obvious. [String/UUID change made/needed]: None.
Matt, this doesn't apply cleanly to beta, and I'm not sure how to resolve the conflicts. Would you mind doing a backport?
status-firefox37: affected → fixed
WARP support wasn't added until 37, so 36 isn't affected by this bug :)
status-firefox36: affected → unaffected
You need to log in before you can comment on or make changes to this bug.