1883225 - Significant performance regressions (from 5ms to 105ms) in WebGL texSubImage2D and Canvas2D drawImage video to canvas copy paths in Firefox 123

Status: VERIFIED FIXED

(Core :: Graphics: CanvasWebGL, defect, P1)

Description

[Wessel Kroos]

Attachment: Graphics performance profile comparison.png

Steps to reproduce:

On Firefox 123:

1. Install https://addons.mozilla.org/nl/firefox/addon/ambient-light-for-youtube/
2. Go to https://www.youtube.com/watch?v=LXb3EKWsInQ
3. Set the video to 4K
4. The WebGL framerate is stuck at ~12fps

On Firefox 122:

1. Follow the same steps from 1 till 3.
2. The WebGL framerate easily reaches 60fps

Actual results:

Firefox 123 is stuck at ~12fps.

Expected results:

Firefox 123 should easily reach 60fps, just as Firefox 122 did.

Deducting from the graphics performance profile, it looks like there are performance regressions in the calls "CanvasRenderingContext2D.drawImage" and "WebGL2RenderingContext.texSubImage2D" and in the GPU Processes "CanvasRenderer" and "Renderer".

This bug was reported by a user of this extension/add-on. And here is a link to the original bugreport:
https://github.com/WesselKroos/youtube-ambilight/issues/224

The user is using a NVidia 4090 GPU and I was able to reproduce this bug with a NVidia 2070 Super GPU.

Comment 1

[Wessel Kroos]

Attachment: Framerate stats.png

Comment 2

[Wessel Kroos]

Attachment: Firefox 122 - 2024-03-03 profile.json.gz

Comment 3

[Wessel Kroos]

Attachment: Firefox 123 - 2024-03-03 profile.json.gz

Comment 4

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

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

Comment 5

[Mayank Bansal]

I can confirm this bug.

Bisection:
Bug 1655101 - Padded<T,PaddedSize> to paper over mingw-32's smaller sizeof(std::string). r=gfx-reviewers,aosmond
Differential Revision: https://phabricator.services.mozilla.com/D197543

Release 122 (Good): https://share.firefox.dev/48Dc8NB
Nightly 3Mar2024 D2d-canvas (Bad): https://share.firefox.dev/3wDpigB
Nightly 3mar2024 gpu-canvas (Bad): https://share.firefox.dev/3uUgfqV

Comment 6

[Mayank Bansal]

Attachment: about:support

Comment 7

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

Set release status flags based on info from the regressing bug 1655101

Comment 8

[Pascal Chevrel:pascalc]

This is too late to fix in the 123 cycle, could we get a priority and severity set on this one? Thanks

Comment 9

[Kelsey Gilbert [:jgilbert]]

Bug 1655101 disabled gpu-blits for texSubImage, and included a warning that I expected to show up: "Fast uploads not supported for TexSubImage. Use TexImage.".
However, that warning is a EnqueuePerfWarning, so is not shown by default, unless the pref webgl.perf.max-warnings is -1 or >=1.

Workaround: Use texImage instead of texSubImage for videos.

I can't remember any reason for this disabling besides simplicity, so we can probably just allow fast texSubImage again, if the tests pass.

Comment 10

[Kelsey Gilbert [:jgilbert]]

This is probably bad enough for an S2.
I honestly didn't think people would be using texSubImage much for this kind of thing.

Comment 11

[Kelsey Gilbert [:jgilbert]]

The reason texSubImage was disabled is because BlitPreventReason needs to know the internal-format of the teximage, and texSubImage calls don't have that data.
Without knowing on the client side what the internal-format of the teximage is, the client can't be sure it can rely on the host side being able to do the gpu-blit. If the client side sends a texSubImage call with a source e.g. video that the host side cannot gpu-blit, then the host side has no good way of being able to get the data back over to the cpu for slowpath upload.

We do know the unpack format and type though, and there are limited valid possibilities of internal-format for unpack-format-and-type:

• unpack-format-and-type: RGBA,UNSIGNED_BYTE: https://searchfox.org/mozilla-central/rev/172e503b01303c153b0dfe39827acb2bc9ede1b9/dom/canvas/WebGLFormats.cpp#896-902
  • internal-format: RGBA8 (colorRenderable: always true)
  • internal-format: RGBA4 (colorRenderable: always true)
  • internal-format: RGB5_A1 (colorRenderable: always true)
  • internal-format: SRGB8_ALPHA8 (colorRenderable: always true)
• unpack-format-and-type: RGB,UNSIGNED_BYTE: https://searchfox.org/mozilla-central/rev/172e503b01303c153b0dfe39827acb2bc9ede1b9/dom/canvas/WebGLFormats.cpp#919-922
  • internal-format: RGB8 (colorRenderable: true iff our webgl-startup test says it works)
  • internal-format: SRGB8 (colorRenderable: always false, but we don't test it right now)
  • internal-format: RGB565 (colorRenderable: always true)

We can expand our RGB8-renderability test to include SRGB8 as well. Hopefully everyone who supports RGB8 renderability also supports SRGB8 renderability, in which case we're safe to allow texSubImage uploads again.

Comment 12

[Kelsey Gilbert [:jgilbert]]

Attachment: Bug 1883225 - webgl.texSubImage(video): re-enable gpu-blit for RGBA, and RGB iff RGB8+SRGB8 renderable.

Comment 13

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/efb6c465b7de
webgl.texSubImage(video): re-enable gpu-blit for RGBA, and RGB iff RGB8+SRGB8 renderable. r=gfx-reviewers,lsalzman

Comment 14

[Sandor Molnar[:smolnar]]

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

Comment 15

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

The patch landed in nightly and beta is affected.
:jgilbert, is this bug important enough to require an uplift?

• If yes, please nominate the patch for beta approval.
• If no, please set status-firefox124 to wontfix.

For more information, please visit BugBot documentation.

Comment 16

[Alexandru Trif, Desktop QA [:atrif]]

Reproduced the issue with Firefox 125.0a1 (2024-03-02) on Windows 10x64 by using steps from comment 0. A maximum of ~12 fps is displayed when running the video with an AMD RX 7800XT video card.
The issue is verified fixed with Firefox 125.0b5 on Windows 10x64 and 11. 60 FPS is achieved after following the steps from comment 0.