1762125 - No HW video decoding for some Intel drivers on Windows because of incorrect gfx blocklist rule

Status: RESOLVED FIXED

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

Description

[dragos.slash]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:100.0) Gecko/20100101 Firefox/100.0

Steps to reproduce:

I get no hardware video decoding at all with Firefox. I have tried AVC (H264), VP9, AV1.
Chromium is able to do hardware decoding without any issues.
If I set "media.hardware-video-decoding.force-enabled" to "true", then Firefox can do AVC (H264), but still no VP9 or AV1.

The hardware is capable of decoding all these three codecs: Intel i7-11800h and NVIDIA 3080 (notebook). OS is x64 Windows 10 Enterprise LTSC 21h2 (19044.1586). I use the latest drivers, all software is up to date.

I am attatching some screenshots, their names should be self-descriptive. They contain screenshots of Firefox, Chromium, TaskManager and DXVAchecker while these browsers are running video files using the aforementioned codecs. There is a screenshot of MPV as well which shows the video metadata, including MPV's own pseudo-UI confirming it is using HW decoding. DXVAchecker is also confirming Chromium is able to use HW dec for both VP9 and AV1.

I have tested Firefox ESR, Firefox Stable and the current Nightly, they behave.

Actual results:

No HW video decoding, resulting in high CPU usage.

Expected results:

Firefox should be capable of using HW decoding.

Comment 1

[dragos.slash]

Attachment: screenshots

Comment 2

[dragos.slash]

ESR, Stable and Nightly behave the same. I must have truncated the message by mistake.

Comment 3

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::Audio/Video: Playback' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 4

[Alastor Wu [:alwu]]

Would you mind to provide your about:support?
Also, why you think Firefox didn't use HW decoding? In your screenshot, there did have GPU usage. A way to verify what decoder you're using is to install this add-on and see videoDecoderName description.
Thanks!

Comment 5

[dragos.slash]

Attachment: h264_default_no_hw_accel.png

Comment 6

[dragos.slash]

Attachment: h264_hw_accel_forced.png

Comment 7

[dragos.slash]

Attachment: about_support.txt

Comment 8

[dragos.slash]

Attachment: about_support_raw_data.txt

Comment 9

[dragos.slash]

I will attach the about:support.
I can tell it is not using HW decoding based in resource usage. Disabling HW decoding in MPV will result in the same usage as Firefox. Enabling HW decoding in MPV will result in a significantly lower resource usage, and is in line with Chromium.
I have also tried that extension.

Also two screenshots:
h264_default_no_hw_accel.png -> Firefox in its default state, does nnot use HW decoding. H264 codec.
h264_hw_accel_forced.png -> pref. "media.hardware-video-decoding.force-enabled" set to "true". Same video file, H264 codec.

Do note that setting "media.hardware-video-decoding.force-enabled" to "true" will only get Firefox to use HW acceleration for H264. VP9 and AV1 are still done in software.

Comment 10

[dragos.slash]

Attachment: VP9 and AV1

VP9 and AV1 will only be decoded in software, regardless of "media.hardware-video-decoding.force-enabled" state. Top screenshots are Nightly 100 in its default config. Bottom ones have only the aforementioned change.

Comment 11

[Alastor Wu [:alwu]]

AV1 HW decoding is only supported on Intel Gen 12, your graphic card is Tiger Lake (gen11) which doesn't support that. But for VP9, your setup should be enough for HW decoding.

Bug 1760804 is going to change how we would query HW decoder on Windows, we could wait for it landing and see if that helps or not.

Comment 12

[dragos.slash]

Well, this particular iGPU on i7-11800h does support HW AV1 decoding. Both Chromium and MPV are capable of doing it. I hope Mozilla won't artificially limit the AV1 decoding to AlderLake.
That said, I can run Firefox off the RTX 3080, and the results are the same. Firefox simply won't use HW decoding.

Comment 13

[dragos.slash]

Attachment: AV1_HW_dec_TigerLakeH.png

Comment 14

[Alastor Wu [:alwu]]

oh, ok. Let's wait for Bug 1760804 and revisit this bug if the issue still presents.

Comment 15

[Jim Mathies [:jimm]]

Ashely's work in Bug 1754239 - Add hardware accelerated media encode/decode information to about:support should help as well.

Comment 16

[Jim Mathies [:jimm]]

Follow up on this once we have more hardware support information.

Comment 17

[Alastor Wu [:alwu]]

Could you help me again try the Nightly to see if you could use HW for VPX and AV1 decoding?
Thank you.

Comment 18

[dragos.slash]

No changes. h264, VP9 and AV1 are all soft decoded.
Nightly 101.0.0.8132 2022-04-07

Comment 19

[Zaggy1024]

dragos, on that Nightly release, could you run some logs? Navigate to your Firefox folder in a command prompt and run firefox using this command:
firefox -MOZ_LOG="MediaSource:5,MediaFormatReader:5,MediaDemuxer:5,PlatformDecoderModule:5,MediaDecoder:5,sync,timestamp" -MOZ_LOG_FILE="%userprofile%\Documents\firefox_log"
That will write log files to your Documents folder, the relevant one should be firefox_log.child-1.moz_log most likely. It will have lines starting with [GPU XXXXXX: Main Thread] if it's the correct file.

Also, judging by the fact that media.hardware-video-decoding.force-enabled is only used once to override FEATURE_HARDWARE_DECODING, I would guess there must be something causing that feature status to be disabled. Is there any way to determine why that is being turned off yet?

Comment 20

[dragos.slash]

Attachment: firefox_log.zip

I attempted to run the VP9 video in the newest Nightly, using a clean profile.

Comment 21

[Zaggy1024]

It looks like GetCanUseHardwareVideoDecodingOrDefault() is returning false when WMFDecoderModule.cpp initializes:

2022-04-07 21:36:38.359000 UTC - [GPU 13900: Main Thread]: D/PlatformDecoderModule sDXVAEnabled: true, CanUseHardwareVideoDecoding: false
2022-04-07 21:36:38.364000 UTC - [GPU 13900: COM MTA]: D/PlatformDecoderModule H264 is enabled
2022-04-07 21:36:38.365000 UTC - [GPU 13900: COM MTA]: D/PlatformDecoderModule VP8 MFT requires DXVA
2022-04-07 21:36:38.365000 UTC - [GPU 13900: COM MTA]: D/PlatformDecoderModule VP9 MFT requires DXVA
2022-04-07 21:36:38.365000 UTC - [GPU 13900: COM MTA]: D/PlatformDecoderModule AV1 MFT requires DXVA
2022-04-07 21:36:38.366000 UTC - [GPU 13900: COM MTA]: D/PlatformDecoderModule MP3 is enabled
2022-04-07 21:36:38.367000 UTC - [GPU 13900: COM MTA]: D/PlatformDecoderModule AAC is enabled
2022-04-07 21:36:38.367000 UTC - [GPU 13900: Main Thread]: D/PlatformDecoderModule WMFDecoderModule::Init finishing

Might this be caused by some blocklist entry? I'm not sure if there's something else that could cause FEATURE_HARDWARE_VIDEO_DECODING not to be OK here:
https://searchfox.org/mozilla-central/source/gfx/thebes/gfxPlatform.cpp#2420

Comment 22

[Alastor Wu [:alwu]]

HW decoding seems being blocked by this. Reporter's driver is 30.0.101.1404 (2-18-2022) which is pretty new.

Jeff, is this blocking list correct? Should we specify a concrete version?

Thanks.

Comment 23

[Jeff Muizelaar [:jrmuizel]]

Attachment: Bug 1762125. Allow DXVA on newer Intel drivers.

Newer Intel drivers break our assumptions about the bottom four digits
being the build id and we end up blocking newer drivers with build ids
like 11404. This reverts the change in bug 1295902 which changed this
blocklist rule to only look at the build number. I think bug 1295902 was
just trying to be more correct and I don't know that it actually blocks
important crashes. Decoding now mostly happens in the GPU process
so the impact of these crashes is reduced from what it originally was.

The information on how to interpret Intel driver version is from:
https://www.intel.ca/content/www/ca/en/support/articles/000005654/graphics.html

The proper fix is to have Intel specific driver version parsing.

Comment 24

[Jeff Muizelaar [:jrmuizel]]

This query suggests that's we're blocking 13% of our Intel users from getting hardware video decoding instead of the .4% that would've been blocked if we didn't have bug 1295902.

https://sql.telemetry.mozilla.org/queries/85227/source

Comment 25

[Jeff Muizelaar [:jrmuizel]]

I was able to reproduce this locally. Twitch at 1080p was unplayable on a Intel Xe laptop with a recent driver.

Comment 26

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/806873368d4c
Allow DXVA on newer Intel drivers. r=alwu

Comment 27

[Jeff Muizelaar [:jrmuizel]]

Here are the most common driver versions that are blocked by the current rule and would be unblocked by my change on this bug:

25,673	8.15.10.1749
13,882	8.15.10.2702
12,984	30.0.101.1122
11,992	8.15.10.1930
8,819	30.0.101.1191
6,601	8.15.10.2697
4,194	8.15.10.2302
4,165	10.0.19041.868

There are a bunch of 8.15.x.x drivers that we might still want blocked. It's probably safer to also block those if we decide to uplift this to release.

Comment 28

[Jeff Muizelaar [:jrmuizel]]

Keeping 8.15.x.x blocked would bump the .4% back up to 9%

Comment 29

[Jeff Muizelaar [:jrmuizel]]

I'll try to get a graph over time tomorrow to get a sense for how rapidly users are updating their drivers to affected versions.

Comment 30

[Pascal Chevrel:pascalc]

[Tracking Requested - why for this release]:
Potentially a dot release driver

Comment 31

[Norisz Fay [:noriszfay]]

https://hg.mozilla.org/mozilla-central/rev/806873368d4c

Comment 32

[GMA]

https://www.intel.com/content/www/us/en/download/19344/intel-graphics-windows-dch-drivers.html

Mozilla should test their Intel driver version detection code on the latest Intel 30.0.101.1660 graphics driver or later versions.

https://www.intel.com/content/www/us/en/download/726609/intel-arc-graphics-windows-dch-driver.html

This will also affect Intel Arc discrete GPUs which uses the 30.0.101.1xxx driver version schema also, although Intel Arc driver is currently 300 build number version behind. In the future the driver version will also probably roll over to 102.xxxx driver version schema.

This bug needs to be fixed before Firefox 100.0 and ESR 102.0 ships.

Comment 33

[BugBot [:suhaib / :marco/ :calixte]]

The patch landed in nightly and beta is affected.
:jrmuizel, is this bug important enough to require an uplift?
If not please set status_beta to wontfix.

For more information, please visit auto_nag documentation.

Comment 34

[Jeff Muizelaar [:jrmuizel]]

Here's a graph in problem over time: https://sql.telemetry.mozilla.org/embed/query/85240/visualization/211044?api_key=jwBQpKHV7DM6mpNQotFOQXLvLZZpHvvsfXntiN1O&

Comment 35

[Jeff Muizelaar [:jrmuizel]]

Attachment: Bug 1762125. Allow DXVA on newer Intel drivers.

Newer Intel drivers break our assumptions about the bottom four digits
being the build id and we end up blocking newer drivers with build ids
like 11404. This reverts the change in bug 1295902 which changed this
blocklist rule to only look at the build number. I think bug 1295902 was
just trying to be more correct and I don't know that it actually blocks
important crashes. Decoding now mostly happens in the GPU process
so the impact of these crashes is reduced from what it originally was.

The information on how to interpret Intel driver version is from:
https://www.intel.ca/content/www/ca/en/support/articles/000005654/graphics.html

The proper fix is to have Intel specific driver version parsing.

This is a more conservative fix that also adds blocking for drivers
earlier or equal to 8.15.10.2849.

Comment 36

[Jeff Muizelaar [:jrmuizel]]

Comment on attachment 9271689 [details]
Bug 1762125. Allow DXVA on newer Intel drivers.

Beta/Release Uplift Approval Request

• User impact if declined: Intel users on Windows with newer video drivers will not get hardware accelerated video decoding
• Is this code covered by automated tests?: No
• Has the fix been verified in Nightly?: No
• Needs manual test from QE?: Yes
• If yes, steps to reproduce: Get the newest Intel driver (something with the last set of digits of the version number < 2849), go to Twitch and start a video. Confirm that the "Video Decoding" graph in Process Manager under the GPU pane has 0% without this change and some non-zero % with it.
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): This removes an accidental driver block. If we need to add it back we can use a downloadable blocklist entry to block it without having to spin a new dot release.
• String changes made/needed:

Comment 37

[Donal Meehan [:dmeehan]]

Comment on attachment 9271689 [details]
Bug 1762125. Allow DXVA on newer Intel drivers.

Approved for 99.0.1

Comment 38

[Donal Meehan [:dmeehan]]

https://hg.mozilla.org/releases/mozilla-release/rev/7bd0f12e4810

Comment 39

[Dianna Smith [:diannaS] - on Leave, back on August 9th]

Comment on attachment 9271689 [details]
Bug 1762125. Allow DXVA on newer Intel drivers.

Approved for 100.0b5

Comment 40

[Dianna Smith [:diannaS] - on Leave, back on August 9th]

https://hg.mozilla.org/releases/mozilla-beta/rev/2f6cc1354b9c

Comment 41

[dragos.slash]

Attachment: Untitled.png

Trying the latest Nightly, 101.0.0.8136, 2022-04-11, using the latest Intel driver, 30.0.101.1660, I get no HW acceleration for VP9 or AV1. Only h264 seems to work.

Comment 42

[Alastor Wu [:alwu]]

Would you mind to capture the debug log like what comment 19 described again?
Thank you.

Comment 43

[dragos.slash]

Attachment: Untitled.png

I will do it again in one moment. One more thing, this laptop can disable the iGPU and completely bypass it, usinng the dedicated GPU, which in this case is a Nvidia 3080, for both processing and output.
It can also only decode h264.

Comment 44

[dragos.slash]

Attachment: firefox_log.child-1.zip

Nightly 101 2022-04-11

Comment 45

[dragos.slash]

Attachment: nvidia-only_firefox_log.child-1.zip

Nightly 101 2022-04-11 NVIDIA only

Comment 46

[Alastor Wu [:alwu]]

Per your log, it showed that we couldn't find the correct MFT on your computer for VPX (MF_E_TOPO_CODEC_NOT_FOUND, 0xC00D5212) and couldn't find the correct component for AV1 (WINCODEC_ERR_COMPONENTNOTFOUND, 0x88982F50).

I have tested Firefox ESR, Firefox Stable and the current Nightly, they behave.

Did you say on ESR and Release, you also couldn't get the hw decoding, right? But I suppose Chromium also uses MFT for VPX decoding, we would need to figure out why we couldn't find MFT on your system.

Comment 47

[dragos.slash]

Indeed, it was a misspell on my part. ESR and Stanble behave the same way as Nightly 100 at the time of writing the initial report.

Comment 48

[Alastor Wu [:alwu]]

Let's track this issue on bug 1764200. Use this bug for gfx blocklist error.

Comment 49

[Mihai Boldan, Desktop QA [:mboldan]]

Hello,
Since we don't have the necessary hardware in order to verify this issue, could you please take a look and see if the issue was fixed on the latest available builds: 99.0.1 RC, 100.0b4, Nightly 101?
Ty!

Comment 50

[dragos.slash]

Well, this bug was indeed solved, and my driver is no longer blocked ny Firefox.
The second part, described here in comments https://bugzilla.mozilla.org/show_bug.cgi?id=1764200 was on my end. My install was lacking certain codecs. After installing them everything works fine. Chromium seems to work around this issue.

Comment 51

[dragos.slash]

100.0b4 still has this problem. No HW dec on this build.

Comment 52

[dragos.slash]

99.0.1 RC is working fine. Both h264 and VP9 use HW decoding.

Comment 53

[dragos.slash]

Latest 101 build also working properly. Uses HW decoding on all h264, VP9 and AV1.

Comment 54

[Jeff Muizelaar [:jrmuizel]]

Comment on attachment 9271689 [details]
Bug 1762125. Allow DXVA on newer Intel drivers.

ESR Uplift Approval Request

• If this is not a sec:{high,crit} bug, please state case for ESR consideration: 4% of our Intel users are not getting hardware video decoding because their drivers are too new.
• User impact if declined: Intel users on Windows with newer video drivers will not get hardware accelerated video decoding
• Fix Landed on Version: 99
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): This removes an accidental driver block. If we need to add it back we can use a downloadable blocklist entry to block it without having to spin a new dot release.

Comment 55

[BugBot [:suhaib / :marco/ :calixte]]

A patch has been attached on this bug, which was already closed. Filing a separate bug will ensure better tracking. If this was not by mistake and further action is needed, please alert the appropriate party.

Comment 56

[Marco Castelluccio [:marco]]

(In reply to Release mgmt bot [:suhaib / :marco/ :calixte] from comment #55)

A patch has been attached on this bug, which was already closed. Filing a separate bug will ensure better tracking. If this was not by mistake and further action is needed, please alert the appropriate party.

Sorry about the noise, we didn't consider the case of patches to uplift. We are temporarily disabling this tool until we fix the problem.

Comment 57

[Dianna Smith [:diannaS] - on Leave, back on August 9th]

Backed out changeset 2f6cc1354b9c (bug 1762125) to uplift different patch on ticket
Backout link: https://hg.mozilla.org/releases/mozilla-beta/rev/c39a2cdfd2d2718c36b1fdec5a4187cade15559a

D143362 will go out in 100.0b6

Comment 58

[Dianna Smith [:diannaS] - on Leave, back on August 9th]

https://hg.mozilla.org/releases/mozilla-beta/rev/63b4ec3eb651

Comment 60

[Dianna Smith [:diannaS] - on Leave, back on August 9th]

Comment on attachment 9271689 [details]
Bug 1762125. Allow DXVA on newer Intel drivers.

Approved for 91.9esr

Comment 61

[Dianna Smith [:diannaS] - on Leave, back on August 9th]

https://hg.mozilla.org/releases/mozilla-esr91/rev/fb4046e17433

Comment 62

[Camelia Badau [:cbadau], Desktop QA]

Hello,
Could you please verify that the issue is also fixed on Firefox 91.9ESR (https://archive.mozilla.org/pub/firefox/candidates/91.9.0esr-candidates/build1/)?
Thank you!

Comment 63

[dragos.slash]

Yes, the issue is fixed on ESR 91.9.0 as well as on 100.0b9,.

Comment 65

[Brindusa Tot, Desktop QA]

Based on comments 52, 53 and comment 63, marking this as verified.