https://bugs.kde.org/show_bug.cgi?id=521208
Bug ID: 521208
Summary: Fall Apart effect gets stuck in an infinite repaint
loop after closing a window, pinning the GPU at ~100%
(KWin Wayland)
Classification: Plasma
Product: kwin
Version First 6.6.5
Reported In:
Platform: Arch Linux
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: effects-various
Assignee: [email protected]
Reporter: [email protected]
Target Milestone: ---
> **Disclaimer:** This report was written by an LLM that collected the
> diagnostic data on
> my machine. I'm not an expert — all I noticed myself is that the problem is
> related to
> the Fall Apart effect. I don't know what exactly triggers it or what the root
> cause is.
**Product:** kwin
**Component:** effects-various
**Version:** 6.6.5
**Severity:** normal (performance/power regression)
**Platform:** Arch Linux
## Summary
With the **Fall Apart** desktop effect enabled, using system as normal
eventually leaves KWin in a permanent full-rate repaint loop. The compositor
keeps
recompositing at the full display refresh rate (165 Hz here) even though the
desktop is
idle and **no client is producing any damage**. The GPU sits at ~100%
utilization
indefinitely until the effect is reloaded or compositing is toggled.
It is not visually obvious — there is no on-screen glitch, just constant
repainting — so
it goes unnoticed except for fan noise and elevated power draw, until a game or
a heavy
web page has to share an already-saturated GPU.
## Steps to reproduce
1. Plasma/Wayland session, Fall Apart effect enabled (default).
2. Use the system normally, maybe use some electron apps, play games.
3. Leave the desktop idle and observe GPU utilization.
## Observed result
- `cat /sys/class/drm/cardN/device/gpu_busy_percent` (AMD iGPU) reads a steady
**100%**
while the desktop is idle.
- KWin's own AMD DRM client (`drm-engine-gfx` in `/proc/$(pidof
kwin_wayland)/fdinfo/*`,
single client-id) advances by **~860 ms per wall-clock second ≈ 86% of one
GPU-second**
— i.e. KWin alone is saturating the GPU compositing at full refresh.
- No application shows any meaningful `drm-engine-gfx` delta; there is no
visible damage
source. Closing the app that was last closed (the one that "fell apart") does
**not**
clear it.
- **CPU usage is normal** — kwin_wayland sits at ~10% of a single core, the
system load is
idle. This is purely a GPU-side repaint loop, not a CPU spin.
- **`nvtop` without `sudo` does not show this load** — the GPU utilization /
per-process
attribution only became visible with root (or by reading `gpu_busy_percent`
and the
kwin process's own `fdinfo` directly). This is part of why the problem is so
easy to
miss: a casual `nvtop` glance looks fine.
- `org.kde.kwin.Effects.activeEffects` shows the close-animation effects
lingering as if
the animation never completed.
## Recovery (workarounds that clear it instantly)
- Reload the effect;
- Restart KWin;
- Disabling Fall Apart entirely prevents the problem from recurring.
## Expected result
The fall-apart close animation should signal completion and KWin should return
to
damage-driven (on-demand) repainting once the animation ends. Idle GPU
utilization should
drop back to near 0%.
## Diagnostic evidence
```
# AMD iGPU busy while desktop idle, Fall Apart active:
$ cat /sys/class/drm/card1/device/gpu_busy_percent
100 100 100 100 100
# KWin's single amdgpu DRM client, gfx-engine delta over 1 s:
delta = ~860 ms/s (~86% of one GPU-second)
# Active effects while stuck:
showpaint, blur, fadingpopups # close/popup animations not terminating
# After unload+load fallapart (or compositor toggle):
$ cat /sys/class/drm/card1/device/gpu_busy_percent
0 0 0
```
## System information
- KWin / Plasma: **6.6.5**
- Qt: **6.11.1**
- Session: **Wayland**, DRM backend
- Compositing: OpenGL / EGL
- GPU (compositing): **AMD Radeon 680M (Rembrandt, radeonsi, ACO)** integrated
- Secondary GPU: **NVIDIA GeForce RTX 3050 Mobile** (driver 595.71.05) — hybrid
laptop
- Mesa: **26.1.2-arch1.1**
- Display: External MSI Optix MAG274QRF-QD **165 Hz**, Adaptive Sync =
automatic, allowTearing = true
- Kernel: **6.17.10** (custom "nitrous" build, not relevant, happens on any
kernel)
- Distro: Arch Linux
## Notes
- Reproduced on a hybrid AMD iGPU + NVIDIA dGPU laptop; the compositor renders
on the AMD
iGPU. High refresh rate (165 Hz) makes the wasted full-rate compositing
especially
expensive on the integrated GPU.
- The lack of any client-side damage source while KWin keeps repainting at full
rate
strongly suggests the Fall Apart effect's animation is not being torn down on
completion, keeping the render loop permanently active.
## Since when / possible regression
I'm not sure when this started — pretty much since 6.0.0, or maybe even
5.something. This
bug doesn't trigger every day, and I don't play games every day, so it took a
while to
notice that the GPU was being pinned and even more to point why. So "introduced
in" version
is pretty unknown.
## Possibly related but distinct bugs
I searched the tracker; the following look related but do **not** describe this
exact
issue (GPU-bound silent repaint loop after closing windows, desktop staying
responsive):
- **Bug 493797** — "After dragging windows to screen edge, KWin sometimes
freezes in an
infinite loop" (RESOLVED FIXED, 6.3.3). Different: that is a **CPU-bound hard
freeze**
(kwin spinning at 100% CPU in `nextInteractiveMoveGeometry()`, desktop fully
unresponsive), triggered by dragging a window to a screen edge — not by
closing
windows, and the GPU is not the bottleneck.
- **Bug 498849** — "Whole Plasma session freezes with 'Fall Apart' effect
enabled"
(RESOLVED DUPLICATE of 493797). Same hard-freeze-on-drag case, not this one.
Never happened to me.
- **Bug 498848 / 499978 / 444166 / 501410** — Fall Apart effect being
*triggered too
frequently* (e.g. on login, tiling, snapping). These are about **when** the
effect
fires, not about it leaving the compositor stuck repainting afterwards.
- **Bug 409182** — Fall Apart causing a kwin **crash** on virtual-desktop
switch. A crash,
not a stuck render loop.
- **Bug 454518** — "Fall Apart effect flashes at the end." A visual artifact at
animation
end; possibly adjacent to an animation-teardown problem, but not the
GPU-pinning loop.
This report is GPU-bound and the session stays usable, which is what
distinguishes it from all of the above.
--
You are receiving this mail because:
You are watching all bug changes.
