Open Bug 1721702 Opened 3 years ago Updated 1 month ago

twitch uses more GPU in Firefox than Chrome

Categories

(Core :: Graphics: WebRender, defect)

defect

Tracking

()

People

(Reporter: jrmuizel, Unassigned)

References

(Blocks 2 open bugs)

Details

Attachments

(3 files)

On https://www.twitch.tv/alanzoka I see 43% usage of the 3D pipeline vs Chrome's 27%. This is running 1080p60 video on a 2560x1440 screen on a Intel HD 530

This was inspired by https://www.reddit.com/r/firefox/comments/onjc4n/twitch_sucks_in_firefox/

Blocks: wr-perf

From GPA System Analyzer:
GTI Read and Write Throughput seems similar with Firefox vs Chrome. EU Active % is noticeably higher with Firefox (11% vs 24%)

PS FPU0, and FPU1 Pipe active is also higher (15% vs 7%), as well as Send Pipeline (5% vs 3%)
Samplers Texels is also higher (300 vs 175) as is Samplers Busy (33% vs 17%)

I'm surprised that the Sampler stuff is higher but GTI Throughput is not. Maybe the texture format that we're using is different from Chrome?

Seems a bit worrying

Severity: -- → S3
Blocks: video-perf

FWIW, the original reporter is using a haswell GPU

I am also experiencing this bug. I'm running Firefox 91.0 on macOS 11.5.1

djbystedt, what hardware do you have? Can you run Intel Power Gadget and compare the power usage in Chrome, Safari, and Firefox and report the package wattage here?

Flags: needinfo?(djbystedt)
No longer blocks: wr-perf
Blocks: twitch

Clear a needinfo that is pending on an inactive user.

Inactive users most likely will not respond; if the missing information is essential and cannot be collected another way, the bug maybe should be closed as INCOMPLETE.

For more information, please visit auto_nag documentation.

Flags: needinfo?(djbystedt)

This is still happening to me, both on Release and Nightly versions Firefox. OS: Windows 11 Pro 22631, GPU: AMD 680m
Chrome with zero-raster uses 1% of the GPU while Firefox uses 20%. This brings the total system power usage while streaming from ~10W (Chrome) to ~18W (Firefox) which is obviously affecting battery life and heat on a portable device like my laptop.

Tried to dig into it a bit and found this stale bug along with this line in about:support:
HW_DECODED_VIDEO_ZERO_COPY
default blocked Blocklisted by gfxInfo

Looking at gfxInfo: I can't immediately understand why I'm this is blocked for me on Windows - the macros seem to add Linux scenarios to the blocklist:
https://searchfox.org/mozilla-release/source/widget/gtk/GfxInfo.cpp#1124-1137
I also don't know if this is the only issue here or if there is a whole can of worms to be uncovered by enabling FEATURE_HW_DECODED_VIDEO_ZERO_COPY

Andrei, can you attach a copy of your about:support?

Flags: needinfo?(andrei_ancuta)

Sure, here it is!

Flags: needinfo?(andrei_ancuta)

Sotaro, why do you think zero copy video is being blocked here?

Flags: needinfo?(sotaro.ikeda.g)

(In reply to Andrei Ancuta from comment #8)

Looking at gfxInfo: I can't immediately understand why I'm this is blocked for me on Windows - the macros seem to add Linux scenarios to the blocklist:
https://searchfox.org/mozilla-release/source/widget/gtk/GfxInfo.cpp#1124-1137
I also don't know if this is the only issue here or if there is a whole can of worms to be uncovered by enabling FEATURE_HW_DECODED_VIDEO_ZERO_COPY

Fwiw the relevant Blocklist for windows is here: https://searchfox.org/mozilla-central/rev/d87ac4f189d6c1ad068bc3d1cdf50d2f871028c2/widget/windows/GfxInfo.cpp#1762, the code you linked is for Linux.

I see, thank you so much Emilio! Indeed that must be it.
However, the plot thickens:
I don't see any mention of disable_dxgi_zero_copy_video in my chrome://gpu/ but the entry in https://chromium.googlesource.com/chromium/src/+/HEAD/gpu/config/gpu_driver_bug_list.json is still there (search by "26.20.15000.37").
dxdiag shows my amd driver version as 31.0.24002.92 which is obviously higher than 26.20.15000.37. Something's still fishy here, right? I'll attach my dxdiag and chrome://gpu shortly.

Attached file DxDiag.txt

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

Sotaro, why do you think zero copy video is being blocked here?

zero copy video is disabled for now for enabling video overlay without ZeroCopyNV12Texture.

Since video overlay with non-Inten GPU was backed out 2 times from Firefox release on Windows. Video overlay is in the process of being gradually enabled like the following.
[1] Split video overlay to hardware "decoded video overlay" and "software decoded video overlay"(Bug 1829063)
[2] Enable "software decoded video overlay" with all GPUs until release. (Bug 1816026)
[3] Enable "hw decoded video overlay without ZeroCopyNV12Texture" with NVIDIA GPUs until release (Bug 1851625)
[4] Enable "hw decoded video overlay without ZeroCopyNV12Texture" with AMD GPUs until release (Bug 1851630)
[5] Re-enable zero copy video with NVIDIA GPUs until early beta on Windows(Bug 1882001)
[6] Re-enable zero copy video with AMD GPUs until early beta on Windows(Bug 1882002)
[6] Enable "hw decoded video overlay with ZeroCopyNV12Texture" with NVIDIA GPUs until release (Bug 1769643)
[7] Enable "hw decoded video overlay with ZeroCopyNV12Texture" with AMD GPUs until release (Bug 1769643)

For now, [3] was completed. With AMD GPUs, "hw decoded video overlay without ZeroCopyNV12Texture" is enabled until early beta. It seems OK to try [4] and [5] now.

The process of enabling overlay is slow, since bug reporting could take time like Bug 1817617.

zero copy video could be forced enabled by pref "media.wmf.zero-copy-nv12-textures-force-enabled = true" with restarting Firefox.

Flags: needinfo?(sotaro.ikeda.g)

Thanks, Sotaro!
Things seem to work fine for me with "media.wmf.zero-copy-nv12-textures-force-enabled = true" and the flag does reduce the GPU usage from ~20% to ~16%.
I think there's a good chance the rest of the GPU usage is covered by https://bugzilla.mozilla.org/show_bug.cgi?id=1724949

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: