https://bugs.kde.org/show_bug.cgi?id=517954
Bug ID: 517954
Summary: KWin chooses the iGPU as primary on hybrid AMD+NVIDIA
systems when the only active desktop output is on the
dGPU
Classification: Plasma
Product: kwin
Version First 6.6.2
Reported In:
Platform: NixOS
OS: Linux
Status: REPORTED
Severity: major
Priority: NOR
Component: platform-drm
Assignee: [email protected]
Reporter: [email protected]
CC: [email protected]
Target Milestone: ---
SUMMARY
On my hybrid AMD+NVIDIA laptop, KWin on Wayland chooses the AMD iGPU as the
primary DRM/render GPU because it has the internal panel, even when the only
active desktop output is an external HDMI monitor connected to the NVIDIA dGPU.
In that state, any desktop repainting (or perhaps compositing) such as moving
the mouse, dragging windows, or other normal interaction causes continuous
journal spam from kwin_wayland:
0x500: GL_INVALID_ENUM error generated. Invalid <face>.
Invalid framebuffer status: "GL_FRAMEBUFFER_INCOMPLETE_MISSING_ATTACHMENT"
The external monitor also becomes visibly choppy and FPS drops heavily when
repainting (or compositing). I enabled the showfps effect from the debug
console and when moving my mouse, it steadily drops from my monitor's frequency
(100hz) to around 50-60, when I stop it goes back to ~100.
A tested local KWin patch that changes the DRM GPU selection heuristic fixes
the issue completely for me.
STEPS TO REPRODUCE
1. Use a hybrid AMD+NVIDIA laptop where the internal panel is connected to the
AMD iGPU and an external HDMI monitor is connected to the NVIDIA dGPU.
2. Start a Plasma Wayland session with the internal panel connected but
disabled, and the external HDMI monitor enabled as the only active desktop
output.
3. Move the mouse, drag windows, or otherwise cause normal desktop repaints
while watching the journal.
OBSERVED RESULT
Constant error spam when repainting (or compositing, not sure)
0x500: GL_INVALID_ENUM error generated. Invalid <face>.
Invalid framebuffer status: "GL_FRAMEBUFFER_INCOMPLETE_MISSING_ATTACHMENT"
The external monitor becomes choppy and FPS drops significantly during
painting. In my case it would fall to around ~50 FPS on a 100 Hz monitor.
While idle, no such errors are logged and kwin remains at ~100fps.
EXPECTED RESULT
When the only active desktop output is on the NVIDIA dGPU, KWin should
automatically choose the NVIDIA DRM GPU as the primary render/compositor GPU.
In that case:
- no GL_INVALID_ENUM / framebuffer spam should appear
- desktop interaction on the external monitor should remain smooth
SOFTWARE/OS VERSIONS
Linux/KDE Plasma: NixOS Unstable channel, kernel 6.19.8
KDE Plasma Version: 6.6.3
KDE Frameworks Version: 6.24.0
Qt Version: 6.10.2
ADDITIONAL INFORMATION
- NVIDIA GeForce GTX 1650 at PCI 0000:01:00.0
- AMD Renoir iGPU at PCI 0000:05:00.0
- Internal panel is on AMD
- External HDMI monitor is on NVIDIA
KWin output state in the affected docked setup
- eDP-2: connected, disabled
- HDMI-A-1: connected, enabled
This means the only active desktop output is HDMI-A-1 on the NVIDIA GPU.
This appears to happen because KWin is rendering on the AMD iGPU while scanout
for the active external monitor happens on the NVIDIA dGPU. During repainting
(or compositing) every frame has to go through the cross-GPU
render/import/synchronization path, which appears to miss frame deadlines on a
100 Hz monitor, causing large visible FPS drops/choppiness.
I performed a A/B test by starting a separate Plasma Wayland session from a TTY
with KWIN_DRM_DEVICES forcing KWin to prefer the NVIDIA DRM device before the
AMD DRM device.
On my machine:
- NVIDIA dGPU = PCI 0000:01:00.0
- AMD iGPU = PCI 0000:05:00.0
Diagnostic procedure used:
1. Log out of the normal Plasma session
2. Switch to a TTY and log in
3. Start a temporary Plasma Wayland session with the NVIDIA DRM device
preferred:
dbus-run-session env \
KWIN_DRM_DEVICES=/dev/dri/by-path/pci-0000:01:00.0-card:/dev/dri/by-path/pci-0000:05:00.0-card
\
startplasma-wayland
4. Inside that temporary session, verify which GPU KWin is using:
qdbus org.kde.KWin /KWin supportInformation | grep -A20 '^Compositing'
5. Then interact normally (move mouse, drag windows, etc.) and check for
errors:
journalctl -b --since '30 seconds ago' --no-pager | grep -c 'GL_INVALID_ENUM'
In that temporary session:
- KWin compositor GPU became NVIDIA
- OpenGL vendor string changed to NVIDIA Corporation
- GL_INVALID_ENUM count dropped to 0
- desktop smoothness returned
- the external monitor stayed around ~90-95 FPS while painting and 100 FPS
while idle
The current DRM GPU selection heuristic in KWin prefers GPUs with more internal
outputs:
src/backends/drm/drm_backend.cpp
Relevant code in my local KWin 6.6.3 source tree:
- src/backends/drm/drm_backend.cpp:155-169
It currently sorts GPUs by:
1. number of internal outputs
2. then number of desktop outputs
3. then total outputs
KWin then uses the selected first GPU as the primary render GPU:
- src/backends/drm/drm_backend.cpp:358-360
- src/backends/drm/drm_backend.cpp:470-472
- src/backends/drm/drm_egl_backend.cpp:46-60
Also, using output->isEnabled() is too early at this point in startup, because
newly created DRM outputs are initially created with:
- pipeline->setEnable(false)
in:
- src/backends/drm/drm_gpu.cpp:324-326
However, drmOutputs() already reflects connected connectors, because
disconnected connectors are removed and connected ones get outputs created:
- src/backends/drm/drm_gpu.cpp:311-327
--
You are receiving this mail because:
You are watching all bug changes.
