1766684 - Twitter animations flash green visual artifacts when looping with SWGL

Status: VERIFIED FIXED

(Core :: Graphics: WebRender, defect)

Description

[Chris Peterson [:cpeterson]]

[Tracking Requested - why for this release]:

@ Jeff or Glenn, I suspect this regression in Firefox 100 was caused bug 1762125 to change the Intel GPU blocklist. I bisected this regression to this pushlog:

https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=9286536a7dbe063e054bc786960c976463d691a7&tochange=ed124d06d67623a6227a41ecffd8533733755976

Twitter's "GIF" animations are actually videos, but this bug only happens with SWGL enabled (gfx.webrender.software = true), so I don't know if this is a video bug or a SWGL bug. It only happens with D3D11 SWGL (gfx.webrender.software.d3d11 = true), not full SWGL (gfx.webrender.software.d3d11 = false).

Steps to reproduce:

1. In Firefox 100 or later, enable gfx.webrender.software and leave gfx.webrender.software.d3d11 = true.
2. Load a Twitter "GIF" animation, such as:

https://twitter.com/claviska/status/1519085364069244932

Expected result

The animation should loop without flash green visual artifacts like Firefox 99 and Chrome.

Actual result

The animation flashes green visual artifacts when looping in Firefox 100 and 101. Unfortunately, I wasn't able to capture a screenshot.

Comment 1

[Chris Peterson [:cpeterson]]

Attachment: about-support.txt

Comment 2

[Jeff Muizelaar [:jrmuizel]]

Chris, can you try downgrading your driver to something with the last digits > 2849, see if it's still broken and try to get a regression range?

Comment 3

[Chris Peterson [:cpeterson]]

(In reply to Jeff Muizelaar [:jrmuizel] from comment #2)

Chris, can you try downgrading your driver to something with the last digits > 2849, see if it's still broken and try to get a regression range?

My current Intel driver version is 30.0.101.1405 according to both about:support and the Windows Device Manager. AFAICT, I don't have a driver version that would match the blocklist rule for versions 8.15.10.2849 or 9.17.10.2849. Or am I misunderstanding?

I wasn't able to roll back or install a new driver version. The Device Manager's "Roll Back Driver" button is disabled for my Intel driver. So I went looking for older drivers on https://www.intel.com/content/www/us/en/download/19344/intel-graphics-windows-dch-drivers.html. I downloaded more recent versions (30.0.101.1631 and 30.0.101.1660), but the installers failed.

What do you recommend I do to help test?

Comment 4

[Jeff Muizelaar [:jrmuizel]]

Prior to bug 1762125 your driver would've been blocklisted because it's < 2849. Can you try installing 30.0.100.9955 from the Intel website? or if that doesn't work try a driver from: https://www.catalog.update.microsoft.com/Search.aspx?q=subsys_0a611028%20%2030.0.100.9864%20

Comment 5

[Chris Peterson [:cpeterson]]

(In reply to Jeff Muizelaar [:jrmuizel] from comment #4)

Prior to bug 1762125 your driver would've been blocklisted because it's < 2849. Can you try installing 30.0.100.9955 from the Intel website? or if that doesn't work try a driver from: https://www.catalog.update.microsoft.com/Search.aspx?q=subsys_0a611028%20%2030.0.100.9864%20

I couldn't find version 30.0.100.9955, so I downloaded and installed 30.0.100.9864 from that Microsoft website. I still able to reproduce the green flashes with 30.0.100.9864.

Correction: I now see 30.0.100.9955 on the Intel website. If you'd like me to test that version, just let me know.

Comment 6

[Jeff Muizelaar [:jrmuizel]]

9864 is great. Can you get a new regression window with that driver?

Comment 7

[Chris Peterson [:cpeterson]]

(In reply to Jeff Muizelaar [:jrmuizel] from comment #6)

9864 is great. Can you get a new regression window with that driver?

Using version 30.0.100.9955 (not 9864), I bisected the regression to this new Firefox 97 pushlog with your reuse-decoder-device fix for bug 1745976:

https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=266622315f357daae531747868b1766e765b18ad&tochange=a87211c8eedde447aec9e270172948f51b8b510e

In summary:

• With driver version 30.0.100.9955 (the latest 30.0.100.* from Intel's website), I first see the green flashes after bug 1745976.
• With driver versions 30.0.101.1405 (the version installed by Windows Update for Windows 11 Beta) and 30.0.101.1660 (the latest 30.0.101.* from Intel's website), I first see the green flashes after the driver blocklist changes in bug 1762125.

Comment 8

[Jeff Muizelaar [:jrmuizel]]

Sotaro, can you reproduce this?

Comment 9

[GMA]

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

Does this happen on Intel 30.0.101.1934 BETA graphics driver? I think Intel is gonna release a 30.0.101.19xx production non beta driver soon.

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

If it does, then this should be reported to Mozilla's Intel contacts to get the Intel driver bug fixed.

Comment 10

[Sotaro Ikeda [:sotaro]]

(In reply to Jeff Muizelaar [:jrmuizel] from comment #8)

Sotaro, can you reproduce this?

I could not reproduce the problem on my 6 Win PCs.

Comment 11

[Chris Peterson [:cpeterson]]

Windows Update installed a new Windows 11 Beta version (10.0.22610 Build 22610) today and now I can no longer reproduce this bug, even using the same Intel driver version 30.0.101.1405 I used in comment 0. So maybe this was a Windows bug and not an Intel driver bug?

I'll close this bug as WORKSFORME.

Comment 12

[Chris Peterson [:cpeterson]]

Reopening this bug because I can reproduce it again.

I don't know why I couldn't repro two days ago in comment 11. Maybe I had still had gfx.webrender.software temporarily disabled. To make sure I'm not seeing a new regression now, I retested those same builds and can now reproduce the bug.

I can repro with Intel driver version 30.0.101.1405 and 30.0.101.1660.

Comment 13

[NVD]

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

Intel released new 30.0.101.1960 graphics driver, does it still happen?

Comment 14

[BugBot [:suhaib / :marco]]

The severity field is not set for this bug.
:gw, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 15

[Sotaro Ikeda [:sotaro]]

(In reply to Chris Peterson [:cpeterson] from comment #0)

1. In Firefox 100 or later, enable gfx.webrender.software and leave gfx.webrender.software.d3d11 = true.
2. Load a Twitter "GIF" animation, such as:

https://twitter.com/claviska/status/1519085364069244932

It seemed that gif animation was actually mp4 video.

• https://video.twimg.com/tweet_video/FRTgFcYXsAA1cyN.mp4

Comment 16

[Sotaro Ikeda [:sotaro]]

I wonder if we need to wait video frame copy end in D3D11DXVA2Manager::CopyToImage().

Comment 17

[Sotaro Ikeda [:sotaro]]

Attachment: WIP: Bug 1766684 - Wait video frame copy end in D3D11DXVA2Manager::CopyToImage()

Comment 18

[Sotaro Ikeda [:sotaro]]

I wonder if D146877 might work as a workaround.

::cpeterson, can you check if the following build could address the problem? And can you take Firefox profiler result when the problem happens?

• https://treeherder.mozilla.org/jobs?repo=try&revision=a984828b76895647a91a6554117f7b53cdec11f0
• https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/drej-RtuTjO-Ihy5JZcZBQ/runs/0/artifacts/public%2Fbuild%2Ftarget.zip

Comment 19

[Chris Peterson [:cpeterson]]

(In reply to Sotaro Ikeda [:sotaro] from comment #18)

I wonder if D146877 might work as a workaround.

::cpeterson, can you check if the following build could address the problem? And can you take Firefox profiler result when the problem happens?

Success! I can't reproduce the bug with your build.

Do you still need me to take a Firefox profile of the animation playing correctly in your build? Or of the bug happening in my regular Nightly build?

My current Intel driver version is 30.0.101.1340. I haven't tested the new 30.0.101.1960.

Comment 20

[Sotaro Ikeda [:sotaro]]

(In reply to Chris Peterson [:cpeterson] from comment #19)

(In reply to Sotaro Ikeda [:sotaro] from comment #18)

I wonder if D146877 might work as a workaround.

::cpeterson, can you check if the following build could address the problem? And can you take Firefox profiler result when the problem happens?

Success! I can't reproduce the bug with your build.

Do you still need me to take a Firefox profile of the animation playing correctly in your build? Or of the bug happening in my regular Nightly build?

Great! Can you take a Firefox profile with regular Nightly build? I want to check which functions are called on Renderer thread when the problem happen on your PC.

Comment 21

[Chris Peterson [:cpeterson]]

(In reply to Sotaro Ikeda [:sotaro] from comment #20)

Great! Can you take a Firefox profile with regular Nightly build? I want to check which functions are called on Renderer thread when the problem happen on your PC.

Here's a Firefox profile of the bug happening. I used the Firefox Profiler's "Graphics" setting.

https://share.firefox.dev/39Hgbji

Comment 22

[Sotaro Ikeda [:sotaro]]

Thank you. RenderDXGITextureHost::MapPlane() was called. Then RenderDXGITextureHost data was readbacked to cpu.

Then the readback seemed to happen before video frame copy complete.

For hardware decoded video, keyed mutex does not work. Then SyncObjectD3D11Client::Synchronize() was called in D3D11DXVA2Manager::CopyToImage(). But the Synchronize() is not called when compositor device is used for hardware decoding.

---

wr_renderer_lock_external_image()
->RenderTextureHostSWGL::LockSWGL()
->RenderTextureHostSWGL::UpdatePlanes()
->RenderDXGITextureHost::MapPlane()

Comment 23

[Sotaro Ikeda [:sotaro]]

D146877 could be one workaround. It waits a video frame copy complete.

And calling the Synchronize() without using compositor device for video decoding might be another workaround. It seems less risky than D146877.

Comment 24

[Sotaro Ikeda [:sotaro]]

Attachment: Bug 1766684 - Use compositor device for hardware video decoding only with hardware WebRender

Comment 25

[Sotaro Ikeda [:sotaro]]

:cpeterson, can you check if the following build of D147049 could address the problem?

https://treeherder.mozilla.org/jobs?repo=try&revision=773f9a0e634a2d56c343302c7e5ee7e2624a3358
https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/YQLlOAaoSIqkf5t32hdF_w/runs/0/artifacts/public%2Fbuild%2Ftarget.zip

Comment 26

[Chris Peterson [:cpeterson]]

(In reply to Sotaro Ikeda [:sotaro] from comment #25)

:cpeterson, can you check if the following build of D147049 could address the problem?

I can't reproduce the bug with that build, so that fix seems to work.

Comment 27

[Sotaro Ikeda [:sotaro]]

Thank you for the confirmation! Then D147049 is better approach for now.

Comment 28

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/1b1a27a14740
Use compositor device for hardware video decoding only with hardware WebRender r=jrmuizel,gfx-reviewers

Comment 29

[Norisz Fay [:noriszfay]]

https://hg.mozilla.org/mozilla-central/rev/1b1a27a14740

Comment 30

[Ardelean Oana, Desktop Test Engineering [:oardelean]]

I couldn't reproduce this issue on Firefox 100/101 on Win10/11 x64. Would you be so kind as to verify the fix on beta and/or nightly?
Thank you.

Comment 31

[Sotaro Ikeda [:sotaro]]

No problem, I am going to check it.

Comment 32

[Sotaro Ikeda [:sotaro]]

On my PCs, the problem did not happen:(

:cpeterson, can you check if the problem is addressed on beta and/or nightly?

Comment 33

[Chris Peterson [:cpeterson]]

Verified fixed in Beta 102 and Nightly 103.

Comment 34

[Ardelean Oana, Desktop Test Engineering [:oardelean]]

Marked as verified based on Comment 33. Removing qa-verify flag.