There are a lot of synchronisation issues being discussed right now, but I think I have singled this one out. STEPS TO REPRODUCE: 1. Aquire a system with an NVIDIA GPU (RTX 2080 Ti in this case) 2. Aquire a high refresh rate monitor, like 144 Hz (may be optional) 2. Install the beta driver version 555.42.02 3. Install Plasma 6.1 beta with KWin 6.0.90 4. Set System Settings → Display & Monitor → Adaptive sync to `Never` in order to filter out possible issues with adaptive sync. 5. Set `KWIN_DRM_DISABLE_TRIPLE_BUFFERING=1` in order to filter out possible side effects with triple buffering. 6. Use the computer. Open windows, move windows, close windows, and pay attention to the mouse cursor movement. It takes a bit of a trained eye. OBSERVED RESULT: 7. Observe the following behavior(s) of the mouse cursor: - Skipping frames: The mouse cursor jumps over short distances. - Frame rate drops: The mouse cursor appears to be rendered at a lower frame rate for short (~1 second) periods. NOTE: This behavior is also observable in the 6.0.5 branch with explicit sync: https://invent.kde.org/plasma/kwin/-/commits/work/zamundaaa/cherry-pick-explicit-sync EXPECTED RESULT The mouse cursor movement should be rendered smoothly at all times, just like in Plasma 6.0 without explicit sync. SOFTWARE/OS VERSIONS Operating System: Arch Linux KDE Plasma Version: 6.0.90 KDE Frameworks Version: 6.2.0 Qt Version: 6.7.1 Kernel Version: 6.9.2-zen1-1.1-zen (64-bit) Graphics Platform: Wayland Processors: 24 × AMD Ryzen 9 3900X 12-Core Processor Memory: 31.3 GiB of RAM Graphics Processor: NVIDIA GeForce RTX 2080 Ti/PCIe/SSE2 ADDITIONAL INFORMATION NVIDIA Driver Version: 555.42.02 ENVIRONMENT: # Native KDE dialogs in Firefox GTK_USE_PORTAL=1 # Wayland support in Thunderbird MOZ_ENABLE_WAYLAND=1 # Get other things to use Wayland SDL_VIDEODRIVER=wayland,x11 QT_QPA_PLATFORM=wayland ELECTRON_OZONE_PLATFORM_HINT=auto CLUTTER_BACKEND=wayland # Maybe fix KDE stutter? KWIN_DRM_DISABLE_TRIPLE_BUFFERING=1
Are you using the proprietary kernel modules, or the open ones? > This behavior is also observable in the 6.0.5 branch with explicit sync If you phrase it like that, not with 6.0.5? The cursor is completely independent of these protocol bits, so I don't understand how that would be possible
I am using the proprietary modules. I can confirm the problem also exists with driver version 555.52. I have not noticed this issue while using 6.0.5. And definitely not in 6.0.4. I noticed that it usually happens when the system is under load and most often *while* an animation is playing. Like when I am opening/closing/minimising/restoring windows. Disabling all animations makes the problem almost completely disappear. Maybe it is related to GPU load? The cursor "hiccups" never last longer than a second. Not only the cursor is affected. The rest of the screen also misses/skips frames, it's just much less noticeable. Maybe try this to reproduce it: 1. Enable animations (Default setting of Plasma) 2. Move the cursor in a circle and keep moving 3. Press the super key to open/close the application launcher repeatedly. 4. Observe the cursor
Can confirm, the cursor is basically unusable with how stuttery it is on the new update. Disabling adaptive sync helps but does not solve the issue.
(In reply to hedibi6542 from comment #3) > Can confirm, the cursor is basically unusable with how stuttery it is on the > new update. Disabling adaptive sync helps but does not solve the issue. I think enabling adaptive sync causes another problem to mix in with the one I described. When adaptive sync is enabled, the frame rate seems to drop from 144 to 48 at all sorts of inappropriate times. However, this report means the cursor (or general) stuttering with adaptive sync disabled. (set to "never")
(In reply to Zamundaaa from comment #1) > Are you using the proprietary kernel modules, or the open ones? > > > This behavior is also observable in the 6.0.5 branch with explicit sync > If you phrase it like that, not with 6.0.5? The cursor is completely > independent of these protocol bits, so I don't understand how that would be > possible Actually, I reverted back to the regular 6.0.5 stable release and also observed dropped/skipped frames when the system is under high CPU load. What I did, for example: 1. Configure `kdesrc-build` to use all 24 available CPU threads. 2. Run `nice -n 20 kdesrc-build plasma-workspace` to let it compile Plasma in the background. 3. Use the system normally or do the circular cursor motion while pressing the super key like I described before. Please excuse the confusion and loose bits of information, but attempting to get to the root of the problem seems to reveal multiple problems. In my case, even setting kwin_wayland to a niceness of -20 and the compilation task to 19 seems to cause stutters of multiple seconds. I'm wondering if this might be a CPU scheduling issue. Setting the CPU govenor to `performance` didn't seem to help.
If it "stutters" for multiple seconds, then that means the main thread is hanging somewhere and not processing input events anymore. Could you ssh in from a different device and check with a debugger where that hang is happening?
I haven't managed to attach a debugger yet, but I'm still planning to do that. It's hard to catch because it's so short. However now that 6.1 is released, I can definitely confirm that: - The problem still exists as described in 6.1. And it definitely wasn't there in 6.0.5. Same driver version 555.52.04. The cursor stutters/skips frames*. It seems to be worse when system is under any load, like loading a browser page. It could be related to GPU load. - I have not experienced those multi-second hangs in 6.1 yet, this one might've been a beta issue. - VRR is disabled and has been disabled for a while, so this specific issue is not related to VRR. (Although, I do still use a VRR-capable monitor, but the monitor's own FPS overlay shows a constant 144 Hz) * I'll try to record a video later, but for now here's a more detailed description of what I see: The cursor moves smoothly at 144 Hz for about 30-60 seconds and then seems to drop the refresh rate to something like 10 Hz for a period of about 1 or 2 seconds before returning to normal. It looks like it's skipping frames because it "skips" across the screen for a second, and the low refresh rate looks really irregular. I also noticed something strange: when I run `drm_info | grep -C 3 =\ Cursor` to verify if the hardware cursor is in use, the framebuffer ID is always 0. But when I run `watch "drm_info | grep -C 3 =\ Cursor"`, I can see the framebuffer ID of the cursor plane oscillate between zero and a different values like 112 or 113. So it goes 0, then 112, then 0 again, then 113. It looks like the cursor plane is being recreated constantly. Does that help?
Additional info for the sake of record keeping: The FB_ID is changing every time the cursor image changes, which seems to be expected. The FB_ID changes to zero every time the cursor is hidden. (Konsole hides the cursor when typing.) I have the "Shake cursor" effect disabled and still experience the stutters.
I do experience this issue on my system with an AMD GPU (Radeon 7800 XT) as well. KDE Plasma 6.1.1 KDE Frameworks 6.3.0 Kernel 6.9.6 Mesa 24.1.2
For the NVidia 555 driver, I've seen other people report the same problem, and it only happens with the GSP firmware in use. Does the kernel boot argument nvidia.NVreg_EnableGpuFirmware=0 change anything? (In reply to Keno from comment #9) > I do experience this issue on my system with an AMD GPU (Radeon 7800 XT) as > well. Please provide the output of drm_info while the cursor is visible (for example with "sleep 3; drm_info" + then move the cursor to make it visible again)
At least for me, this problem seemlingly disappeared somewhere around 6.1 or 6.1.1, if I had to guess. The compositor (and cursor) still freezes when there is a lot of CPU load (Ryzen 3900X) but otherwise it's smooth now. I disabled VRR entirely. I haven't tried it again with VRR enabled. It's really strange. I've had some other smoothness/synchronisation issues with Games as well. It might actually be a hardware issue.
Thanks for following up!