SUMMARY Several problems when combining 2 gpu's usage in fullscreen mode on external screens (plasmashell always reports running on integrated GPU (iGPU), while games / apps run on dedicated GPU (dGPU) for maximum performance). My laptop have 2 video output ports, one connected to iGPU and second to dGPU. If external screen is connected to iGPU, then fullscreen Vulkan games running on dGPU show just black screen with flashes of gameplay when changing volume (when plasma volume bar shows up). If external screen is connected to dGPU, then these games work fine, but if volume bar shows up (or something else from shell on top of the window) game freezes completely. Problems occur only for Vulkan apps / games, only for external monitor and only when in fullscreen mode (using KWin window rules to disable fullscreen, set manually size to fill the screen and keep the window on top mitigates the issue). Tested only on Wayland, because something is bugged and the whole system runs at 1FPS on X11 (not related issue). STEPS TO REPRODUCE 1. Connect external monitor to a laptop using iGPU + dGPU 2. Run Vulkan game in fullscreen mode on dGPU 3. Change system volume and let the volume bar disappear OBSERVED RESULT Game freezes or black screen EXPECTED RESULT Game working fine SOFTWARE/OS VERSIONS Linux: EndeavourOS 6.0.5-arch1-g14-1 KDE Plasma Version: 5.26.3 KDE Frameworks Version: 5.99.0 Qt Version: 5.15.7 Graphics Platform: Wayland ADDITIONAL INFORMATION My laptop is Asus G14 RK402RJ (iGPU: Ryzen 7 6800HS + dGPU: AMD RX 6700S)
That sounds like the problem only happens with cross-gpu direct scanout. To verify, can you put KWIN_DRM_NO_DIRECT_SCANOUT=1 into /etc/environment, reboot and check if the problem still happens?
The flag KWIN_DRM_NO_DIRECT_SCANOUT=1 worked for both cases, games no longer freeze on dGPU and show even on iGPU connection.
thanks, that should narrow down the possible causes. With that environment variable removed again and QT_LOGGING_RULES="kwin_wayland_*.debug=true" set instead, please cause the problem again and afterwards upload the outputs of > journalctl --user-unit plasma-kwin_wayland --boot 0 and > sudo dmesg If you can cause the issue on one screen while being able to still use the other screen, the output of drm_info (https://gitlab.freedesktop.org/emersion/drm_info) once when you just show the desktop and once when the fullscreen image is stuck could be useful as well.
Created attachment 153765 [details] Diagnostic_logs Here are my diagnostic logs (dmesg, journalctl, drm_info for desktop and fullscreen) compressed in .tar.gz
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
Hello, I believe my system is affected by the same bug: - happens when the iGPU is the main gpu and dGPU is secondary (display is attached to the secondary GPU) - does not happen when the iGPU is disabled - game freezes when direct rendering is used after being indirect (alt-tab, notifications, etc) - games renders correctly afterwards if rendering is kept indirect (e.g. by using the kwin FPS effect) Tested with: iGPU + dGPU (bugged) iGPU + usb-to-hdmi (bugged) dGPU + usb-to-hdmi (working) as the latter is working, perhaps mesa bug? while bugged journalctl prints lots of ``` kwin_wayland_drm: Atomic commit failed! Invalid argument kwin_wayland_drm: Presentation failed! Invalid argument ``` System: 5800H+6600M
> Tested with: > iGPU + dGPU (bugged) > iGPU + usb-to-hdmi (bugged) > dGPU + usb-to-hdmi (working) > > as the latter is working, perhaps mesa bug? Nvm, actually it's just that 3rd case is the other way around, the usb-to-hdmi adapter doesn't do the 3D acceleration XD
dmesg is flooded by `[drm:dm_plane_helper_prepare_fb [amdgpu]] *ERROR* Failed to pin framebuffer with error -22` nothing else to see there...
Created attachment 154409 [details] drm info with vulkan fullscreen on external monitor
(In reply to Minik from comment #4) > Created attachment 153765 [details] > Diagnostic_logs > > Here are my diagnostic logs (dmesg, journalctl, drm_info for desktop and > fullscreen) compressed in .tar.gz I see no relevant warnings in dmesg or journalctl. From the drm_info contents though I can see that you do get direct scanout with fullscreen, and the game provides a XRGB8888 buffer, while KWin uses the ARGB2101010 format when it does compositing. It's possible that switching between these formats triggers some bug in the kernel. To check if it's relevant you can put KWIN_DRM_PREFER_COLOR_DEPTH=24 into /etc/environment, reboot, and see if the problem can still be caused. No matter if that works or not, it might be useful to get more detailed logging for the broken setup from the kernel, which you can do by following the instructions at https://invent.kde.org/plasma/kwin/-/wikis/Debugging-DRM-issues. Keep in mind that it's very verbose, so the time you record dmesg should be as short as possible. (In reply to raffarti from comment #8) > dmesg is flooded by > `[drm:dm_plane_helper_prepare_fb [amdgpu]] *ERROR* Failed to pin framebuffer > with error -22` > nothing else to see there... Sounds exactly like https://gitlab.freedesktop.org/drm/amd/-/issues/2075. Please add a comment to that, to show you're affected as well, and to hopefully make someone at AMD attempt to fix the problem. Putting KWIN_DRM_NO_DIRECT_SCANOUT=1 into /etc/environment should be a usable workaround for you.
> (In reply to raffarti from comment #8) > > dmesg is flooded by > > `[drm:dm_plane_helper_prepare_fb [amdgpu]] *ERROR* Failed to pin framebuffer > > with error -22` > > nothing else to see there... > Sounds exactly like https://gitlab.freedesktop.org/drm/amd/-/issues/2075. > Please add a comment to that, to show you're affected as well, and to > hopefully make someone at AMD attempt to fix the problem. Putting > KWIN_DRM_NO_DIRECT_SCANOUT=1 into /etc/environment should be a usable > workaround for you. Done so, thanks.
What fixes this?
"Resolved upstream" doesn't mean that it's fixed, it means that this is a problem outside of our software. In this case the bug is in the GPU driver, so there's nothing that can be done about it in KDE
(In reply to Zamundaaa from comment #13) > "Resolved upstream" doesn't mean that it's fixed, it means that this is a > problem outside of our software. In this case the bug is in the GPU driver, > so there's nothing that can be done about it in KDE Oh I see. I though it meant the external problem was fixed. Thanks.