https://bugs.kde.org/show_bug.cgi?id=521239
--- Comment #3 from Kael Drevorn <[email protected]> --- (In reply to Kael Drevorn from comment #2) > (In reply to Zamundaaa from comment #1) > > > The compositor struggling with its own event queue should not cause GPU > > > load to collapse and the entire display stack to stall. > > That's just not how computers work. > > > > > systemctl --user restart plasma-plasmashell > > If plasmashell is triggering this somehow, does it also have high CPU usage > > when this happens? > > > > Also, if you have a second device, could you get the backtrace of > > kwin_wayland when it's lagging like that? > > Note: I am not a professional developer. Much of this analysis and data > collection was done with the assistance of AI tools. I have tried to ensure > accuracy, but please correct me if any conclusions are wrong. > System: > > OS: CachyOS (Arch-based, rolling) > KWin: 6.7.0-3.1 / Plasma: 6.7.0-1.1 > Kernel: linux-cachyos 7.0.12-1 > GPU: AMD Radeon RX 9070 XT (RDNA4, Navi 48, amdgpu/Mesa 26.1.2-arch3.1, radv) > CPU: AMD Ryzen 7 5800X3D > Mesa: 3:26.1.2-1 / Gamescope: 3.16.24-1 / Proton: proton-cachyos-native > 11.0.20260602 > Display: 3 monitors — 2× 2560×1440@144Hz + 1× 3440×1440@144Hz (Ultrawide, > primary gaming monitor), KDE Wayland session > > Same symptom as reported: GPU drops from full load to near-idle during > active PoE2 gameplay via Proton, recovers on manual window switch. Confirmed > via LACT: throttle reason shows "Power (PPT0)" during normal gameplay, > collapses to "None" + idle clocks during the stall. The stall only occurs > during active gameplay, never while AFK in the menu — consistent with the > original report. > Additional data point — KWin window focus monitored live via KWin script: > Using workspace.windowActivated.connect() via the KWin scripting API, every > focus change was logged with timestamp, PID, and window class. During a > 21-minute session with documented GPU stalls (confirmed via LACT), zero KWin > window focus changes occurred — the gamescope window held KWin focus > continuously throughout. The GPU was stalling without any window focus > change at the KWin level. > This might suggest that the root cause lies below KWin's window management > layer, possibly in the DRM/compositing path between KWin and the amdgpu > driver — but I leave that interpretation to people who actually understand > the internals. > Tested workarounds and their observed effects: > > KWIN_DRM_NO_DIRECT_SCANOUT=1 — no reliable improvement observed on RDNA4 > (unlike the partial improvement reported on RDNA2 above) > Running under gamescope (nested compositor) — stall still occurs, but > recovery seemed somewhat more reliable in practice; GPU did not get > permanently stuck as often. Whether this is meaningful or coincidence is > unclear to me > Masking plasma-foreground-booster.service — marginal improvement in stall > frequency observed. One possible explanation might be that it reduces > cgroup-related event load on an already stressed compositor, but this is > speculation > DPM set to manual + 3D_FULL_SCREEN profile — no improvement observed > DPM stays auto during normal operation, collapse behavior looks identical to > the manual case — possibly relevant, possibly not > Tested both Vulkan and DX12 render paths in PoE2 — equally affected in my > testing > > Regarding Zamundaaa's questions: > > plasmashell CPU during stall: Not measured during an active stall — no > second device available for SSH monitoring without triggering a focus change > that appears to resolve the stall > kwin_wayland backtrace: Same limitation — no second device available. Happy > to try if there is a way to capture it from the same machine without > inadvertently resolving the stall > > Pattern observed: After a fresh session start, the game tends to run cleanly > for approximately 30–45 minutes before stalls begin occurring with > increasing frequency. This could suggest some form of resource or state > accumulation over the session, but I am not sure what that would be. Additional observation — stall appears to reset on loading screens: After a zone transition (loading screen), the game reliably runs stall-free again for a period before GPU drops resume. The duration of the stable period varies and is not consistent. This might suggest that the loading screen resets some accumulated state — possibly in KWin's DRM/compositing path — rather than shader compilation itself being the stabilizing factor. The stall appears to build up during active 3D rendering and clears when the game enters a non-rendering state (loading screen). Again, I am not a developer — these are observations, not conclusions. Happy to be corrected. -- You are receiving this mail because: You are watching all bug changes.
