1196411 - Detect GPUs that don't support 1080p60 and don't use DXVA for them

Status: RESOLVED FIXED

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

Description

[Matt Woodrow (:mattwoodrow)]

Some GPUs can't support 1080p60 DXVA decoding (notably the vast majority of AMD ones), and yet offer no way to programmatically detect this.

We currently just try it, and then fallback to software decoding when we detect that we're dropping frames.

I'd like to make the fallback code more lenient (so that it's less likely to kick in), but to do this, I want to avoid starting DXVA on GPUs that will never work.

Since there's no way to detect this, it seems the best thing to do is just keep a list of all the older AMD devices, and check the current GPU against it.

Comment 1

[Matt Woodrow (:mattwoodrow)]

Attachment: Don't try DXVA 60fps for slower AMD GPUs

Comment 2

[Jean-Yves Avenard [:jya]]

Comment on attachment 8650072 [details] [diff] [review]
Don't try DXVA 60fps for slower AMD GPUs

Review of attachment 8650072 [details] [diff] [review]:
-----------------------------------------------------------------

::: dom/media/platforms/wmf/DXVA2Manager.cpp
@@ +180,5 @@
>    HRESULT hr = ConvertMFTypeToDXVAType(aType, &desc);
>    NS_ENSURE_TRUE(SUCCEEDED(hr), false);
>  
> +  // AMD cards with UVD3 or earlier perform poorly trying to decode 1080p60 in hardware,
> +  // so use software instead. Pick 45 as an arbitrary upper bound for the framerate we can

they don't handle 50p either ?

50p is typically what you would see in PAL (or SECAM) countries

Comment 3

[Matt Woodrow (:mattwoodrow)]

(In reply to Jean-Yves Avenard [:jya] from comment #2)
> Comment on attachment 8650072 [details] [diff] [review]
> Don't try DXVA 60fps for slower AMD GPUs
> 
> Review of attachment 8650072 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> ::: dom/media/platforms/wmf/DXVA2Manager.cpp
> @@ +180,5 @@
> >    HRESULT hr = ConvertMFTypeToDXVAType(aType, &desc);
> >    NS_ENSURE_TRUE(SUCCEEDED(hr), false);
> >  
> > +  // AMD cards with UVD3 or earlier perform poorly trying to decode 1080p60 in hardware,
> > +  // so use software instead. Pick 45 as an arbitrary upper bound for the framerate we can
> 
> they don't handle 50p either ?
> 
> 50p is typically what you would see in PAL (or SECAM) countries

I don't have any of those to test with. I suspect not, it was hitting around 40-50fps for a 60fps video.

Comment 4

[Pulsebot]

https://hg.mozilla.org/integration/mozilla-inbound/rev/b06457a116b2

Comment 5

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/b06457a116b2

Comment 6

[Matt Woodrow (:mattwoodrow)]

Comment on attachment 8650072 [details] [diff] [review]
Don't try DXVA 60fps for slower AMD GPUs

Approval Request Comment
[Feature/regressing bug #]: None
[User impact if declined]: Most AMD cards will drop frames of 1080p 60fps videos for the first second until we fallback to software, this makes us use software initially.
[Describe test coverage new/current, TreeHerder]: Tested manually.
[Risks and why]: Low risk.
[String/UUID change made/needed]: None

Comment 7

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

Comment on attachment 8650072 [details] [diff] [review]
Don't try DXVA 60fps for slower AMD GPUs

This is a pretty big change so I would like to uplift to Aurora and let it stabilize for a few days before considering an uplift to Beta.

Comment 8

[Ryan VanderMeulen [:RyanVM]]

Needs rebasing for Aurora uplift.

Comment 9

[Matt Woodrow (:mattwoodrow)]

Attachment: Aurora patch

Comment 10

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/358055206195

Comment 11

[clogged.drainpipe]

(In reply to Jean-Yves Avenard [:jya] from comment #2)
> Comment on attachment 8650072 [details] [diff] [review]
> Don't try DXVA 60fps for slower AMD GPUs
> 
> Review of attachment 8650072 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> ::: dom/media/platforms/wmf/DXVA2Manager.cpp
> @@ +180,5 @@
> >    HRESULT hr = ConvertMFTypeToDXVAType(aType, &desc);
> >    NS_ENSURE_TRUE(SUCCEEDED(hr), false);
> >  
> > +  // AMD cards with UVD3 or earlier perform poorly trying to decode 1080p60 in hardware,
> > +  // so use software instead. Pick 45 as an arbitrary upper bound for the framerate we can
> 
> they don't handle 50p either ?
> 
> 50p is typically what you would see in PAL (or SECAM) countries

1080p50 is OK as long as it is the only video playing systemwide. 720p60 is works similarly well.

For example, my card(Radeon HD4890) can DXVA decode approximately 50 frames of 1080p H264 video. If I attempt to DXVA decode 1080p60 I get massive framedrops. This is NOT a per video limitation but a system-wide one, so if I have a 1080p30 video playing and I open another one, then massive framedrops happen. I have not tested the limits of 720p video decoding, but a single 720p60 video works perfectly fine. I would guess that I could play a handful of 480p30 videos at the same time via DXVA and still be just fine.

Comment 12

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

Comment on attachment 8650072 [details] [diff] [review]
Don't try DXVA 60fps for slower AMD GPUs

This patch has been in Aurora for a few days, it seems safe to uplift to Beta41.

Comment 13

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-beta/rev/65d63fc8b1de

Comment 14

[clogged.drainpipe]

I think the framerate check should be >50 not >45. This way 50fps videos(they are not uncommon on youtube) will still work.

Comment 15

[Anthony Jones (:ajones, :kentuckyfriedtakahe, :k17e)]

(In reply to clogged.drainpipe from comment #14)
> I think the framerate check should be >50 not >45. This way 50fps
> videos(they are not uncommon on youtube) will still work.

Why not file a new bug and upload a patch?

Comment 16

[Matt Woodrow (:mattwoodrow)]

Backed this out of the release branches for causing bug 1202700.

https://hg.mozilla.org/releases/mozilla-beta/rev/8b5c02e508e9
https://hg.mozilla.org/releases/mozilla-aurora/rev/3e0e14fd2f2c

Comment 17

[Paul Blinzer]

I am following up on a regression I found when using Firefox on some of my AMD systems with GPUs using UVD3 and found this bug and the associated code change as "culprit".
It seems that the change added a number of devices that are fully capable of playing back 1080p60 without an issue and do so fine on other browsers (Edge, Chrome, etc) and therefore IMO should be removed, let alone that the approach used to blacklist them is very coarse. 

If there are problems with 1080p60 playback with UVD3 or other such hardware, then that is likely an issue with the drivers particular platform power profile than the hardware; it can and should be fixed there. Did you file a bug with AMD before issuing this "fix"?

Comment 18

[clogged.drainpipe]

(In reply to Paul Blinzer from comment #17)
> I am following up on a regression I found when using Firefox on some of my
> AMD systems with GPUs using UVD3 and found this bug and the associated code
> change as "culprit".
> It seems that the change added a number of devices that are fully capable of
> playing back 1080p60 without an issue and do so fine on other browsers
> (Edge, Chrome, etc) and therefore IMO should be removed, let alone that the
> approach used to blacklist them is very coarse. 
> 
> If there are problems with 1080p60 playback with UVD3 or other such
> hardware, then that is likely an issue with the drivers particular platform
> power profile than the hardware; it can and should be fixed there. Did you
> file a bug with AMD before issuing this "fix"?

The HD4000 series has UVD 2, and only supports 1080p50. I would guess that UVD 3 supports 1080p60, but I am not certain.

Comment 19

[Matt Woodrow (:mattwoodrow)]

(In reply to Paul Blinzer from comment #17)
> I am following up on a regression I found when using Firefox on some of my
> AMD systems with GPUs using UVD3 and found this bug and the associated code
> change as "culprit".
> It seems that the change added a number of devices that are fully capable of
> playing back 1080p60 without an issue and do so fine on other browsers
> (Edge, Chrome, etc) and therefore IMO should be removed, let alone that the
> approach used to blacklist them is very coarse. 
> 
> If there are problems with 1080p60 playback with UVD3 or other such
> hardware, then that is likely an issue with the drivers particular platform
> power profile than the hardware; it can and should be fixed there. Did you
> file a bug with AMD before issuing this "fix"?

We discussed this offline.

AMD is going to make it easier to detect support for 60fps video, and we are going to implement support for that checking in bug 1239098.