SUMMARY *** NOTE: If you are reporting a crash, please try to attach a backtrace with debug symbols. See https://community.kde.org/Guidelines_and_HOWTOs/Debugging/How_to_create_useful_crash_reports *** Launching Steam via the Plasma Applications menu ("start menu") or via KRunner and then running a game (tested games: Dark Souls 3, Elden Ring, Baldur's Gate 3) using Gamescope causes the game to run with substantially reduced performance compared to without Gamescope. Closing Steam and then restarting it by typing `steam` into Konsole resolves the issue with Gamescope. Related issue on the Gamescope bugtracker: https://github.com/ValveSoftware/gamescope/issues/1115 STEPS TO REPRODUCE 1. Launch Steam using KRunner or from the Application Launcher 2. Set launch options similar to this for a game: gamescope -e -w 2560 -h 1440 -W 2560 -H 1440 -f -r 144 -- mangohud %command% 3. The game will run poorly 4. Close Steam, then open Konsole and re-launch Steam from the command line and start the game again. It will run normally. OBSERVED RESULT Gamescope has a large performance impact EXPECTED RESULT Gamescope next to no performance impact SOFTWARE/OS VERSIONS Linux/KDE Plasma: Fedora 39, kernel 6.6.13-200, Wayland session (bug also happens in X11 session) (available in About System) KDE Plasma Version: 5.27.10 KDE Frameworks Version: 5.113.0 Qt Version: 5.15.12 ADDITIONAL INFORMATION GPU: AMD Radeon 6700XT, Mesa 23.3.3
After looking at the difference in the environment between the two methods of launching Steam, I have isolated this issue to the KRunner/startmenu launch method setting DRI_PRIME=pci-0000_00_02_0, which is my integrated GPU instead of my dedicated GPU. Steam seems to be smart enough to use my dedicated GPU for rendering the actual game (or else the performance would be even worse), but Gamescope seems to be using the iGPU for some of its business which causes the performance issue. Where might I find the correct lever to pull to stop KRunner from setting DRI_PRIME to my iGPU?
If you edit Steam's .desktop file in KMenuEdit, you can check the checkbox next to "Prefers dedicated GPU". Let me know if that fixes it. If it does, that this is a change that Steam itself should make in its .desktop file.
The problem is that that checkbox is already checked, and KDE thinks my iGPU is my dedicated GPU.
I should add that unchecking that actually *solves* the issue. When that option is not checked, DRI_PRIME is not set to anything.
Fascinating. In that case it's a more general issue with the wrong GPU being detected as the beefy powerful one. Moving to KWin. Any chance you can try Plasma 6 RC2 to see if this issue is already fixed there?
The source of this issue is that there isn't actually any .desktop file key for hinting that something should run on a dedicated GPU, there's only "PrefersNonDefaultGPU". That one is being applied correctly... though its purpose is indeed questionable. We should probably ignore the name and just do what the value is actually used for - running it on a dedicated GPU.
Agreed; "PrefersNonDefaultGPU" is flawed because it contains the implicit assumption that the more powerful and power-hungry GPU is always non-default, which can't be guaranteed to be true. I'd be in favor of interpreting this to mean "Prefers the more powerful GPU".
Can you check whether the order is also broken with switcherooctl as well, since https://invent.kde.org/frameworks/kio/-/merge_requests/1332 plasma should just be probing the same thing AFAIS, so it might not be a kio bug at all. To add up, the upstream might push that to the next upstream (kernel) https://gitlab.freedesktop.org/hadess/switcheroo-control/-/issues/19 as "wrong boot_vga", i.e. the linked https://bugzilla.kernel.org/show_bug.cgi?id=211189 ... It's a little messy, but can you check your HDMI ports like the reporter: "I put the HDMI output on the motherboard and now the cards are well identified." as well?
I have my monitors plugged into the AMD card. The Intel iGPU is only enabled for hardware video encoding with QuickSync and running VMs with its IO-MMU capabilities. No monitors are connected to it. $ switcherooctl list Device: 0 Name: Advanced Micro Devices, Inc. [AMD®/ATI] Navi 22 [Radeon RX 6700/6700 XT/6750 XT / 6800M/6850M XT] (Radeon RX 6700 XT Mech 2X 12G [MSI]) Default: yes Environment: DRI_PRIME=pci-0000_03_00_0 Device: 1 Name: Intel Corporation AlderLake-S GT1 Default: no Environment: DRI_PRIME=pci-0000_00_02_0
So it's technically correct, and not caused by plasma as well To set intel as the default gpu, you should connect to the motherboard display out, but then your purpose of using your amd card for desktop rendering doesn't apply. Maybe there can be an "ignore non-default gpu" global toggle in plasma to support such use cases, though; which would stick with the default gpu, i.e. your amd one here. Adding that as && pre conditional for KIO::hasDiscreteGpu() bool might be the easiest solution?
Sorry, what I mentioned before was wrong. The "PrefersNonDefaultGPU" key is just very badly named, it's intended to be "PrefersPowerfulGPU" per the spec. See https://invent.kde.org/frameworks/kio/-/merge_requests/1556 for a proper fix For being able to correct the "default gpu" being wrong if your firmware messes up, that's a different issue / feature request, and one to take care of in KWin.
Mine would probably be the most common use-case on desktop PCs that use both dedicated and integrated graphics. How this has managed to fly under the radar this far I can only guess; possibly a combination of: - Most Linux gamers currently using setups without dual graphics (i.e. no iGPU) - People with dual graphics disabling their unneeded iGPU -- though this is not the default on such systems, it's a BIOS setting one has to go out of their way to change - Steam being smart enough to ignore this setting in most use-cases -- I've only had this cause issues with Lutris in past, and there it is likely attributed to a poorly named "Use discrete graphics" option in the Lutris settings which in reality should be "Prefer non-default graphics": https://github.com/lutris/lutris/issues/4416
Don't forget hybrid laptops, which as far as I'm aware has more dev attention and those are intentionally using iGPU as default and dGPU is offloaded to save battery life, but the Lutris issue is right on the PC main reversal you're currently experiencing.