https://bugs.kde.org/show_bug.cgi?id=525658
Bug ID: 525658
Summary: kwin 6.7.5 regression: native Wayland video playback
uses ~2.4x more GPU render time than XWayland
(--vo=x11) for identical content
Classification: Plasma
Product: kwin
Version First 6.7.4
Reported In:
Platform: Other
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: compositing
Assignee: [email protected]
Reporter: [email protected]
Target Milestone: ---
Created attachment 196094
--> https://bugs.kde.org/attachment.cgi?id=196094&action=edit
journalctl -b | grep -iE 'kwin|drm' output captured during reproduction
After upgrading kwin from 6.7.4-7.1 to 6.7.5-1.1 (alongside kwindowsystem and
an unrelated nvidia-open/nvidia-utils bump on the same day), hardware-decoded
video playback under native Wayland began pegging the Intel iGPU's Render/3D
engine near 100%, causing visible lag in any application playing video
(confirmed in both Brave and mpv). The same content played via XWayland (mpv
--vo=x11) uses roughly 40% Render/3D instead — less than half the GPU cost for
identical decode+display work. VA-API decode capability itself is confirmed
healthy (vainfo shows full profile/entrypoint list), so this isolates the
regression to KWin's native Wayland presentation/compositing path for
hardware-decoded video, not decode itself.
ENVIRONMENT:
- Distro: CachyOS Linux (Arch-based)
- KWin: 6.7.4-7.1 (working) -> 6.7.5-1.1 (regressed)
- kwindowsystem: 6.29.0-1.1 -> 6.30.0-1.1 (upgraded same day)
- Kernel: linux-cachyos 7.2.4-3
- GPU: hybrid/Optimus laptop — Intel Raptor Lake-S iGPU (active, driving the
display) + Nvidia RTX 5050 (idle, GB207M)
- Session: KDE Plasma, Wayland
- Note: nvidia-utils/nvidia-open/nvidia-settings were also upgraded in the same
update batch (610.57.04 -> 615.71.09). Included for completeness, but the
native-vs-XWayland comparison below points specifically at KWin rather than the
Nvidia driver, since the Nvidia GPU is not even the active renderer in this
setup.
STEPS TO REPRODUCE:
1. Generate a native-resolution test video (no scaling involved):
ffmpeg -f lavfi -i testsrc=size=1920x1200:rate=30 -t 30 -c:v libx264
-pix_fmt yuv420p test.mp4
(substitute your own display's native resolution)
2. Play it under native Wayland:
mpv --hwdec=vaapi --geometry=100%x100% test.mp4
Watch Render/3D usage in intel_gpu_top (or sudo intel_gpu_top).
3. Close mpv, then play the same file forced through XWayland:
mpv --hwdec=vaapi --vo=x11 --geometry=100%x100% test.mp4
Watch Render/3D usage again.
4. Compare the two.
OBSERVED:
- Native Wayland: Render/3D ~99.78% busy, GPU pegged at max clock
(1453/1455MHz), 0% RC6 (never idles), ~34.76W peak.
- XWayland (--vo=x11): Render/3D ~41.31% busy, GPU at lower clock, 40% RC6
(idles regularly), ~13.35W peak.
- Same result reproduces in Brave with hardware acceleration enabled
(fullscreen and windowed), and is resolved in Brave by disabling hardware
acceleration entirely — consistent with the GPU cost being in the presentation
path rather than page content.
EXPECTED:
Native Wayland video presentation should not cost meaningfully more GPU render
time than the XWayland fallback path for identical decoded content.
ADDITIONAL NOTES:
See also Bug 525187 (KWin full-scene animations become extremely slow with many
visible windows) — possibly related root cause in KWin's Wayland rendering
pipeline, though that report predates this regression (filed against 6.7.4) and
involves a different trigger (many windows animating vs. a single video
surface), so I don't believe it's a duplicate.
--
You are receiving this mail because:
You are watching all bug changes.
