Bug 510579

Created attachment 185744 [details]
Overwatch showcase video 2 - KDE

Created attachment 185745 [details]
Overwatch showcase video 3 - KDE

Created attachment 185746 [details]
Overwatch showcase video 4 - KDE

Created attachment 185747 [details]
Overwatch showcase video 1 - GNOME

Created attachment 185748 [details]
Overwatch showcase video 2 - GNOME

Created attachment 185749 [details]
Overwatch showcase video 3 - GNOME

Created attachment 185750 [details]
Overwatch showcase video 4 - GNOME

I've attached various videos comparing KDE to Gnome (xwayland)
- Number 1: game menu
- Number 2-3: character selection
- Number 4: in game (practice-range, where FPS is smooth 270FPS)
  - This is the main video where we see a huge difference

Please put
QT_LOGGING_RULES=kwin_wayland_*.debug=true
into /etc/environment, reboot and then attach the output of
> journalctl --user-unit plasma-kwin_wayland --boot 0
and
> drm_info
here

Hey,

Thanks for your quick input !

journalctl --user-unit plasma-kwin_wayland --boot 0

Did not output anything, so I am attaching instead

journalctl --boot 0 --grep kwin

Created attachment 185774 [details]
kwin journal logs

Created attachment 185775 [details]
drm_info

Alright, KWin is running on the integrated GPU, so the driver is doing multi GPU copies under the hood. I would assume that if these copies were too slow, the game would be throttled as well.

Does anything change if you put
KWIN_DRM_NO_DIRECT_SCANOUT=1
into /etc/environment and reboot?

Also, without the direct scanout environment variable, does
KWIN_DRM_DEVICES="/dev/dri/card0:/dev/dri/card1"
make a difference?

Also, without any environment variables, does connecting the screen to the dedicated GPU and rebooting help?

> Alright, KWin is running on the integrated GPU, so the driver is doing multi GPU copies under the hood. I would assume that if these copies were too slow, the game would be throttled as well.

Somehow, with the same configuration (monitor connected to iGPU), on GNOME the iGPU utilization is 0% while the game takes the full screen, as if it switches entirely to the dGPU (the CPU utilization remains the same, so I am assuming that it doesn't go through RAM instead), but the moment I press Win key, which triggers the overview animation, utilization on iGPU goes up (because composition is happening instead I assume): GNOME seems to be doing something better than KDE.

Let me try your suggestions then come back to you

Created attachment 185811 [details]
monitor=iGPU env=KWIN_DRM_DEVICES="/dev/dri/card0:/dev/dri/card1"

Created attachment 185812 [details]
monitor=iGPU env=KWIN_DRM_NO_DIRECT_SCANOUT=1

Created attachment 185813 [details]
monitor=dGPU env=

Summary:

monitor=iGPU env=KWIN_DRM_DEVICES="/dev/dri/card0:/dev/dri/card1"
-> Made things worse: max FPS dropped, VRR-FPS all over the place

monitor=iGPU env=KWIN_DRM_NO_DIRECT_SCANOUT=1
-> No noticeable difference

monitor=dGPU env=
-> No issues anymore. So as we both guessed, it has something to do with having the monitor connected to the iGPU but using the dGPU for the game

Maybe Gnome happens to hit direct scanout? If you have any of
- a color profile
- hdr
- night light
- non-default kwin effects
enabled, you don't get direct scanout in KWin. Other driver specific things can prevent it from working too.

In general that's a setup that's bound to hit problems to be honest. The integrated GPU is probably just not always fast enough to provide consistent results for compositing at those refresh rates when any other load is involved on top - the iGPU in your case only has two cores after all.

Created attachment 185818 [details]
Capture without color profile

> In general that's a setup that's bound to hit problems to be honest. The integrated GPU is probably just not always fast enough to provide consistent results for compositing at those refresh rates when any other load is involved on top - the iGPU in your case only has two cores after all.

Yeah I know, but it saves 40W of power (according to my wall powermeter 120W vs 160W), and I use my computer 8h a day, I thought it'd be a useless waste.

Thanks for you input! Turns out I was using a color profile (entirely forgot about it), removing that fixes the issue: the VRR FPS is smooth 270. But the iGPU usage is however still high, so there's probably something Kwin could take from Mutter :D

If performance is good, I don't think KWin can be using the iGPU for compositing.
With that in mind though, I don't think there's really anything we can do here, except hoping that AMD will make their small iGPUs in normal CPUs more performant in future generations.

As for power usage, in the not so far future, we'll be able to do dynamic GPU switching in KWin, so you could then use a KVM to switch between iGPU and dGPU depending on the situation.

> As for power usage, in the not so far future, we'll be able to do dynamic GPU switching in KWin, so you could then use a KVM to switch between iGPU and dGPU depending on the situation.

Is that what Mutter is doing automatically, by achieving 0% iGPU usage when fullscreen in-game, while the monitor is still connected to the iGPU ?

> With that in mind though, I don't think there's really anything we can do here

If the answer to the above question is no, then Kwin could definitely do something right ?

Thanks !

@Zamundaaa Mutter seems to indeed be doing something smart: "accelerated iGPU/dGPU framebuffer sharing"

Look at this
https://gitlab.gnome.org/GNOME/mutter/-/blob/main/src/backends/native/meta-renderer-native.c?ref_type=heads#L2031

I opened a separate bug report on the matter: 510847. Thanks again!

see bug 510847