https://bugs.kde.org/show_bug.cgi?id=523480
Bug ID: 523480
Summary: Night colors incur very large frame compositing
overhead
Classification: Plasma
Product: kwin
Version First 6.7.3
Reported In:
Platform: Arch Linux
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: night color
Assignee: [email protected]
Reporter: [email protected]
Target Milestone: ---
Night colors incur very large frame compositing overhead
Overhead for night colors is major. Latency for compositing a single
100x100 frame grows from 2 million cycles to about 3.5 million
cycles. Enough to slow the system down noticeably when playing video,
for instance.
According to the bots, tryKmsColorOffloading in drm_output.cpp
probably sets m_needsShadowBuffer=true, forcing KWin to use the slow
shadow-buffer fallback for all compositing.
1. Most users are probably not aware of how large the night color
overhead is. To me it was quite unexpected.
2. Output of inxi -G:
Graphics:
Device-1: Intel Meteor Lake-P [Intel Arc Graphics] driver: xe v: kernel
Device-2: Shinetech USB2.0 FHD UVC WebCam driver: uvcvideo type: USB
Display: wayland server: X.org v: 1.21.1.24 with: Xwayland v: 24.1.13
compositor: kwin_wayland driver: X: loaded: modesetting dri: iris gpu: xe
resolution: 2880x1800~120Hz
API: EGL Message: EGL data requires eglinfo. Check --recommends.
Info: Tools: api: clinfo de: kscreen-console,kscreen-doctor gpu: gputop,
intel_gpu_top, lsgpu x11: xprop,xrandr
I think my hardware is so recent that it should support any color
pipeline knightcolors throws at it. I don't understand why KWin takes
the fallback path.
--
You are receiving this mail because:
You are watching all bug changes.
