https://bugs.kde.org/show_bug.cgi?id=521239
[email protected] changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #2 from [email protected] --- (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. -- You are receiving this mail because: You are watching all bug changes.
