Summary

After entering and then exiting Big Picture mode, the desktop Steam client leaves
the CEF GPU process continuously compositing at ~50-65% GPU utilization with the
GPU memory clock pinned to 100%, even though the client is idle on the library
page. It stays pinned for well over a minute and then self-decays over a few
minutes. Opening and closing the controller-configuration screen (Settings ->
Controller) clears it instantly, dropping GPU back to ~6%. Before ever opening
Big Picture, idle GPU is ~2%.

This is a compositing/browser-view lifecycle leak, not application-level content:
there is no animation, video, or canvas running in any client page when it is in
the hot state (verified via CEF remote debugging, details below).

Related issues (same subsystem, but a different exact symptom — this one appears
to be unreported):

• #9270 — steamwebhelper crash on exiting Big Picture mode.
• #8372 — VRAM leak from repeatedly opening/closing the controller-config screen
  or entering/exiting Big Picture (AMD/amdgpu). Same browser-view lifecycle and
  same two triggers, but that symptom is VRAM growth, not sustained GPU utilization.
• #6715 — VRAM leak with GPU-accelerated web views. Same web-view GPU subsystem.
• #9207 — "abnormal high GPU/CPU usage"; resolved for that reporter by the kernel
  parameter amdgpu.aspm=0 because their GPU's PCIe link was down-training to
  Gen1 x1. This is NOT that case — see the PCIe link measurement below.

Environment

• CPU/GPU: AMD Ryzen AI (Strix) APU, integrated Radeon 880M/890M (RDNA 3.5)
• OS: Kubuntu / KDE Plasma, Wayland session (KWin)
• Kernel: 7.0.0-28-generic
• CEF/Chromium: Chrome 126.0.6478.183 (per the client's remote-debugging version string)
• Steam: stable client, buildid 1784778118 (steam-launcher 1:1.0.0.85)
• Display: single internal panel, HiDPI (device scale factor ~2.0)
• GPU meter used: radeontop

Steps to reproduce

1. Launch the Steam desktop client and note idle GPU usage (~2%).
2. Enter Big Picture mode; wait for it to fully load.
3. Exit Big Picture mode back to the desktop client.
4. Observe GPU utilization (e.g. with radeontop) — it is now pinned at ~50-65%
   with the GPU memory clock at 100%, with the client sitting idle on the
   library page.

Expected vs actual

• Expected: after exiting Big Picture, GPU usage returns to the idle baseline
  (~2%), as it was before Big Picture was opened.
• Actual: GPU stays at ~50-65% (memory clock pinned to 100%) for over a minute,
  then slowly self-decays over a few minutes. It can be cleared immediately by
  opening and closing the controller-configuration screen.

Working-vs-broken differential (radeontop)

Idle, before ever opening Big Picture:

gpu 1.67%   ... mclk 87.13% 0.816ghz, sclk 25.01% 0.725ghz

Immediately after exiting Big Picture ("hot"), held steady across many seconds:

gpu 48.33% ... mclk 99.99% 0.937ghz, sclk 71.18% 2.064ghz
gpu 48.33% ... mclk 99.99% 0.937ghz, sclk 71.18% 2.064ghz
gpu 49.17% ... mclk 100.00% 0.937ghz, sclk 70.67% 2.049ghz

~35 seconds later, still pinned (not decaying):

gpu 48.33% ... mclk 100.00% 0.937ghz, sclk 71.00% 2.059ghz
gpu 52.50% ... mclk 100.00% 0.937ghz, sclk 70.76% 2.052ghz

After opening and closing the controller-configuration screen:

gpu 5.83%  ... mclk 87.33% 0.818ghz, sclk 30.67% 0.890ghz
gpu 10.00% ... mclk 88.48% 0.829ghz, sclk 32.20% 0.934ghz

The excess load is on the GPU side: while hot, no steamwebhelper renderer shows
significant CPU usage; the continuously accumulating GPU engine time
(drm-engine-gfx in /proc/<pid>/fdinfo) belongs to the CEF GPU process.

Investigation / what was ruled out

Investigated via Steam's CEF remote debugging port
(~/.steam/steam/.cef-enable-remote-debugging, localhost:8080):

• No animation/video/canvas is running in any of the 14 client page targets while
  hot: document.getAnimations() returns 0 running, and there are no <video> or
  <canvas> elements. So this is not an animated-background / DOM content issue.
• Target.getTargets (browser-level) shows only those same 14 page targets — the
  orphaned surface is not a separate/hidden browser target.
• The PCIe link is healthy under load, so this is not the #9207 link-starvation
  case: while hot at ~56% GPU, current_link_speed stays at 16.0 GT/s (Gen4) and
  current_link_width at 16 (verified across repeated reads). L1 ASPM is already
  disabled on this device (l1_aspm=0), so amdgpu.aspm=0 is not expected to help.

Things tried that did NOT fix it:

• Launch option -cef-disable-gpu-compositing: made it worse — Big Picture itself
  dropped to ~3 fps (software compositing) and the post-exit spike remained.
• "Disable GPU Blocklist" (Big Picture -> Settings -> Display -> Advanced): no effect.
• Internal client calls, tested while hot:
  SteamClient.Overlay.DestroyGamePadUIDesktopConfiguratorWindow(),
  SteamClient.Input.OpenDesktopConfigurator()/CloseDesktopConfigurator(),
  SteamClient.Input.ShowControllerSettings() — none had any effect.
  SteamClient.Browser.RestartJSContext() only reduced it partially (~55% -> ~27%)
  and did not reach baseline, which suggests the residual load is a compositor
  layer that survives a full JS-context reload.

The only reliable clear is opening + closing the controller-configuration screen,
which creates and then destroys a separate gamepad-UI browser view. This points to
the leak being an orphaned compositor context for the Big Picture browser view that
is not torn down on Big Picture exit, and is only released when a browser view is
explicitly destroyed.

Workaround

Open Settings -> Controller (or any controller-configuration screen) and close it;
GPU returns to idle immediately. Otherwise it self-decays after a few minutes.

Impact

On a battery-powered APU laptop this is a meaningful, silent power/thermal drain
after every Big Picture session (GPU memory clock pinned to 100% for minutes),
until manually cleared.