| Summary: | Multi/hybrid GPU double copy | ||
|---|---|---|---|
| Product: | [Plasma] kwin | Reporter: | ctj9512 |
| Component: | platform-drm | Assignee: | KWin default assignee <kwin-bugs-null> |
| Status: | REPORTED --- | ||
| Severity: | wishlist | CC: | nate, ngoquang2708, uwu, xaver.hugl |
| Priority: | NOR | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Other | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
ctj9512
2022-05-04 13:27:17 UTC
Plasma would crash immediately if `KWIN_DRM_DEVICES` is used to select the primary GPU. > Ideally, the compositor would run separately on each GPU Technically speaking it is possible, but practically speaking it would be a multi-year effort. It will not happen in the foreseeable future. What can be done though is that KWin is smarter with choosing the compositing GPU, and that it can switch between GPUs at runtime. The former could maybe still be done for 5.25, the latter is planned for 5.26. > Plasma would crash immediately if `KWIN_DRM_DEVICES` is used to select the primary GPU That can probably be fixed. Can you provide the backtrace for kwin_wayland? > Can you provide the backtrace for kwin_wayland?
Ah. I checked the logs, and it said:
kwin_wayland_drm: failed to open drm device at "/dev/dri/by-name/pci-0000"
kwin_wayland_drm: failed to open drm device at "03"
kwin_wayland_drm: failed to open drm device at "00.0-card"
kwin_wayland_drm: failed to open drm device at "/dev/dri/by-name/pci-0000"
kwin_wayland_drm: failed to open drm device at "07"
kwin_wayland_drm: failed to open drm device at "00.0-card"
kwin_wayland_drm: No suitable DRM devices have been found
Looks like I was being stupid when setting this up. I wanted to avoid using `card0` and `card1`, since they are not consistent across reboots.
Is there a way to reference the cards consistently?
Ah. That is very unfortunate. A different separator would probably be good... https://invent.kde.org/plasma/kwin/-/merge_requests/2355 should fix that I tested using `card0` on a laptop. The discrete card runs the compositor, but the built in display dos not display anything. The Display Configuration settings only show the external monitor. What environment variable did you use exactly? If you only specify one card, then KWin will only use that one card and ignore all others (In reply to Zamundaaa from comment #7) > What environment variable did you use exactly? If you only specify one card, > then KWin will only use that one card and ignore all others I only had one card listed. I will test it with 2 cards listed. I tested with 2 cards listed. Plasma does not crash if the external monitor is unplugged. However, the double copy is still occurring. Git commit a110aabbccf56019bdc324b3c751112f35ec3f6c by Vlad Zahorodnii, on behalf of Xaver Hugl. Committed on 09/05/2022 at 08:16. Pushed by vladz into branch 'master'. backends/drm: consider escaped separators KWIN_DRM_DEVICES ':' conflicts with the file names in /dev/dri/by-path, so allow it to be escaped with '\' M +23 -1 src/backends/drm/drm_backend.cpp https://invent.kde.org/plasma/kwin/commit/a110aabbccf56019bdc324b3c751112f35ec3f6c Git commit 3b58fe4bde0722b352e4114adb992a2ed2c96423 by Vlad Zahorodnii, on behalf of Xaver Hugl. Committed on 09/05/2022 at 08:30. Pushed by vladz into branch 'Plasma/5.24'. backends/drm: consider escaped separators KWIN_DRM_DEVICES ':' conflicts with the file names in /dev/dri/by-path, so allow it to be escaped with '\' (cherry picked from commit a110aabbccf56019bdc324b3c751112f35ec3f6c) M +23 -1 src/backends/drm/drm_backend.cpp https://invent.kde.org/plasma/kwin/commit/3b58fe4bde0722b352e4114adb992a2ed2c96423 Would double copy be affected by direct scanout? I attempted using Sway and an application running fullscreen with direct scanout would not be affected by performance loss. However, only Weston supports direct scanout with an application that is windowed (not fullscreen). Sorry for the late reply; to answer your question: Direct scanout avoids copies and does indeed prevent performance losses |