Open Bug 1756429 Opened 2 years ago Updated 5 months ago

GPU process eating CPU while idle on Linux

Categories

(Core :: Graphics, defect)

Firefox 97
defect

Tracking

()

Tracking Status
firefox-esr91 --- disabled
firefox97 --- disabled
firefox98 --- disabled
firefox99 --- disabled

People

(Reporter: lamka02sk, Unassigned)

References

(Blocks 1 open bug)

Details

Attachments

(1 file)

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:97.0) Gecko/20100101 Firefox/97.0

Steps to reproduce:

  1. Start Firefox
  2. Use it for a while, or put computer to sleep
  3. Wake computer up, or after a few hours check idle CPU usage

Actual results:

GPU process is eating ~40% CPU while idle. Overall Firefox performance is affected (feels like 50% performance decrease) and of course battery life gets very bad when this happens.
Closing all tabs doesn't help, it is eating resources while showing about:newtab anyway.
This was a problem also in earlier Firefox versions (roughly versions 70-85), but I didn't have time to report it back then. Then it disappeared until Firefox 96 came out.
Restart is the only temporary solution for now.
From the profiler report, it looks like compositor is stuck doing something strange: https://share.firefox.dev/3BzpT17

Expected results:

GPU process does nothing when idle.

I forgot to mention that I have webrender enabled and this is information about my GPU:

GPU #1
Active	Yes
Description	AMD RENOIR (DRM 3.42.0, 5.15.11, LLVM 13.0.0)
Vendor ID	0x1002
Device ID	0x1636
Driver Vendor	mesa/radeonsi
Driver Version	21.3.6.0
RAM	0

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

Component: Untriaged → Graphics
Product: Firefox → Core

Thanks for the report! Please open about:support, click on "Copy text to clipboard" and paste it here.

Attached file about:support

Attaching output from about:support.

Which Gtk and KDE versions do you have? (bug 1616894)
$ dpkg -l | grep "libgtk-3-common\|kwin-wayland"

The profile contains mozilla::widget::WaylandDispatchDisplays although about:support is KDE/X11.

Please reset the following prefs back to their defaults and restart Firefox. Does the problem still occur after that?
gfx.webrender.compositor
gfx.webrender.compositor.force-enabled
gfx.webrender.enabled
gfx.x11-egl.force-disabled
layers.acceleration.force-enabled
layers.gpu-process.enabled
layers.mlgpu.enabled
layout.frame_rate
media.ffvpx.enabled
media.gpu-process-decoder
media.rdd-process.enabled
media.rdd-vpx.enabled
widget.wayland_vsync.enabled
widget.wayland.opaque-region.enabled

(For VAAPI you only need gfx.webrender.all=true, gfx.x11-egl.force-enabled=true, media.ffmpeg.vaapi.enabled=true, media.rdd-ffmpeg.enabled=true and maybe MOZ_DISABLE_RDD_SANDBOX=1 environment variable. (bug 1751363))

These are the versions of the libraries:

$ dpkg -l | grep "libgtk-3-common\|kwin-wayland"
ii  kwin-wayland                                                4:5.23.1-0ubuntu1~ubuntu21.10~ppa1                                 amd64        KDE window manager, wayland version, PREVIEW release
ii  kwin-wayland-backend-drm                                    4:5.23.1-0ubuntu1~ubuntu21.10~ppa1                                 amd64        KDE window manager drm plugin
ii  libgtk-3-common                                             3.24.30-1ubuntu1                                                   all          common files for the GTK graphical user interface library

Meanwhile I will try changing configuration you recommended and I will get back in a few days with the results. Thank you

Flags: needinfo?(lamka02sk)

Interestingly we are spending most of our time in the Compositor thread blocked on getting the system time WebRenderBridgeParent::MaybeGenerateFrame. We appear to sample the time multiple times in that function, I'm not sure if that is related or not (perhaps there is some caching / invalidation happening on the kernel side??).

Severity: -- → S3
Status: UNCONFIRMED → NEW
Ever confirmed: true

layout.frame_rate:0 certainly caused high CPU usage. (=we could close this bug as INVALID/expected)
Maybe it wanted to do even more work after suspend&resume or catch up with work. (likely wontfix if it only affects layout.frame_rate:0)

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 BugBot documentation.

Flags: needinfo?(lamka02sk)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: