Bug 513593

Here's how to temporally max the iGPU clocks:

On Intel:
cat /sys/class/drm/card*/gt_RP0_freq_mhz | sudo tee /sys/class/drm/card*/gt_min_freq_mhz

On AMD:
echo performance | sudo tee /sys/class/drm/card*/device/power_dpm_force_performance_level

Related discussion:
https://forums.developer.nvidia.com/t/frequent-lags-and-loss-of-smoothness-in-kde-plasma-with-dual-monitors-on-nvidia-3070-ti-wayland-x11/311888/31

Still I don't know if this shall be fixed in kwin, or in the nvidia-persistenced daemon in nvidia-open.

For the time being I have worked-around the bug on optimus-manager:
https://github.com/Askannz/optimus-manager/commit/d3376ef0a2fc2f5a9901790a8ee358125fc63951

Unfortunately, the stuttering (along with increased input latency) occurs not only on the desktop, but also in games.

This partially mitigates the issue (it improves the situation, but does not fully solve it): for KDE Plasma, you can force kwin_wayland to explicitly use the NVIDIA GPU for rendering by setting the KWIN_DRM_DEVICES environment variable in /etc/environment.

When `nvidia-smi` shows that `kwin_wayland` is run on the NVIDIA GPU, lag still occurs.

Most likely the cursor isn't drawn by `kwin` itself.

> 2. Run it with: __GLX_VENDOR_LIBRARY_NAME="nvidia" ./thedarkmod.x64
Does the issue go away if you run it with `prime-run` or also add the __NV_PRIME_RENDER_OFFLOAD=1 and __VK_LAYER_NV_optimus=1 environment variables?

No.

Setting `__NV_PRIME_RENDER_OFFLOAD=1` on Wayland has exactly the same effect as setting `__GLX_VENDOR_LIBRARY_NAME="nvidia" __VK_LAYER_NV_optimus="NVIDIA_only"`. While the Dark Mod only uses GLX.

If in `/etc/profile.d/optimus-manager.sh` I also set `export __EGL_VENDOR_LIBRARY_FILENAMES="/usr/share/glvnd/egl_vendor.d/50_mesa.json"` performance further improves. As the window manager runs on the iGPU, liberating the dGPU from such task.

Otherwise `kwin_wayland` runs on the dGPU by default. Which seems the smart thing to do on non Optimus computers, but probably on Optimus is the other way around.

The source code of `optimus-manager.sh` is here: https://github.com/Askannz/optimus-manager/blob/master/profile.d/optimus-manager.sh

Thanks. Does any of this still happen if you stop using optimus-manager and make sure that none of these environment variables are set at a global level, e.g. in /etc/profile.d/optimus-manager.sh?

Basically I think we need to get confirmation that the problem happens on a stock system with your hardware, and that it isn't being accidentally *caused* by this 3rd-party management tool you're using.

Created attachment 188092 [details]
10-optimus-manager.conf

The problem is that without `optimus-manager` I can't confidently tell, because the external monitor doesn't work. Which is the only one with high frame-rate, while the built-in one just runs at 60Hz.

But I can show you how `optimus-manager` configures `/etc/X11/xorg.conf.d/10-optimus-manager.conf`. I'm attaching it.

Probably the most relevant part is that it sets the iGPU `AccelMethod` to `none`. But without that the dual monitor setup just gets corrupted, probably due to the way frames are copied between the iGPU and the dGPU to support dual monitor setups.

This is because the integrated display circuitry is attached to the iGPU, and the HDMI port to the dGPU. So they need to exchange frames.

(In reply to Alberto Salvia Novella from comment #9)
> Created attachment 188092 [details]
> 10-optimus-manager.conf
> 
> The problem is that without `optimus-manager` I can't confidently tell,
> because the external monitor doesn't work. 

Aha, I think we've finally found the true issue. This is the thing that needs to be reported to KWin so it can be fixed, because it absolutely *should* be working out of the box, without you having to install optimus-manager.

Can you open a new bug report about that?

Once that issue is fixed or at least investigated, we can return to this one and see if it's a KWin issue or just an optimus-manager bug.

Okay 👍

Hello,
I am not using optimus-manager, however the issue described above is still relevant for me.

There are no problems with displaying the image on an external monitor via HDMI or DisplayPort. The issue is limited to severe input lag and an overall drop in performance, as described here: https://github.com/NVIDIA/open-gpu-kernel-modules/issues/650

Using prime-run does not have any effect on this behavior.

In this case, would it be possible to reopen the bug report?

The external monitor bug:
https://bugs.kde.org/show_bug.cgi?id=514808

Alberto, now that Bug 514808 is resolved, Can you see if the original issue still reproduces without Optimus Manager active?

These commands control the integrated graphics frequency:

CURRENT
watch -n 0.1 cat /sys/class/drm/card*/gt_cur_freq_mhz

MAX
cat /sys/class/drm/card*/gt_RP0_freq_mhz | sudo tee /sys/class/drm/card*/gt_min_freq_mhz

MIN
cat /sys/class/drm/card*/gt_RPn_freq_mhz | sudo tee /sys/class/drm/card*/gt_min_freq_mhz


I'm getting inconsistent results. It looks pretty much fixed, for an unknown reason, with and without Optimus Manager.

But sometimes, after boot, the mouse will exhibit lag while in-game. Like while moving the cursor around in "The Dark Mod".

Moving the cursor with the external display connected briefly rises the integrated card frequency. With only the integrated display connected, the effect is less pronounced.

Changing the frequencies from maximum to minimum and vice-versa no longer shows a difference in most boots.

But on a few boots, under unknown situations, moving the cursor around will exhibit notorious lag. As if the cursor clearly stops moving way later than the mouse. Yet the integrated card frequency raises as usual.

It may be related with when the external screen has been connected or disconnected, if during boot or while using the computer. But I can't really tell.


Also the desktop animations are kind of inconsistent, which may be related. Nothing horrible, but nothing smooth either.

Sometimes opening the panels will be smooth, other times slightly choppy.

This doesn't happen with Nouveau and Nova, which are butter smooth. Only with Nvidia Open. But that may be due to this driver being the only to show output on the external screen, and Kwin being able to show both cards on the Info Center.


My guess is that the Nvidia Utils code is kind of cranky, not very well tuned, due to it being proprietary. "nvidia-persistenced" and "nvidia-powerd" being the most likely culprits. Vendored libraries a la 2000s.

Do you think I can provide any more useful info or testing, or even if this still falls within KDE to optimize?

Yeah, I was going to ask whether you think there's anything KWin can do here. And it was going to be a rhetorical question because the answer is no — especially since you've traced it to one driver but not the other two. :)

I'd recommend you report this to the NVIDIA devs, either by sending an email to linux-bugs@nvidia.com or making a post at https://forums.developer.nvidia.com/c/gpu-graphics/linux, and also attaching the output of nvidia-bug-report.sh.

Thanks!

I reported it a few weeks ago, and it seems gone now for some reason.

Also I have to mention that the Nvidia Open drivers are kind of... messy. To say the least.

The components are quite segregated, and there is no reliable way to check if something is missing or misconfigured.

Everything is somehow hacky. Lacks proper standardization.

I don't know if my desktop performance being inconsistent on Wayland is normal, or there is something not properly packaged.