stuttery hardware cursor under high GPU load

[aufkrawall]

When playing games that trigger high GPU load, the hardware cursor visibly skips frames when moving it. The hardware cursor is smooth on Xorg in the games.

It doesn't seem to matter if native Wayland or XWayland. Tested with Shadow of the Tomb Raider (native Linux Wayland Vulkan fullscreen window) and Heroes of the Storm (Wine XWayland Vulkan fullscreen window).

sway version 1.2-1a579780 (Nov 27 2019, branch 'master') (also tested latest stable from Arch repo with same result)

Log:
sway.txt

Config:
config.txt

RX 570, mesa-git 20, radv

Afair the cursor doesn't stutter on Plasma Wayland.

[aufkrawall]

This doesn't happen with amdgpu.dc=0, which is the legacy non-atomic display controller.
Though I retested with Plasma and it definitely doesn't show the cursor stutter with new atomic amdgpu.dc=1.

[emersion]

I don't think Plasma uses the DRM atomic interface.

Can you report this bug to AMD? https://gitlab.freedesktop.org/drm/amd/issues

[ascent12]

This probably isn't an AMD bug. With the atomic interface, cursor updates are synchronized with the primary plane update.
If that is stalled because of slow render times, the cursor is stalled too.
It doesn't affect legacy DRM, because the cursor update is unsynchronized.

If you run https://github.com/ascent12/compositor-killer/ and get the same symptoms, it's the issue I think it is.
Mess with the arguments to make it REALLY slow: ./compositor-killer -a 4 -i 10000 -f 1000x1000 -l 20

[emersion]

Could also be due to our atomic test-only commits for cursor updates.

[aufkrawall]

The cursor is hardly moveable with compositor-killer and the given arguments, yes.

I could identify my custom kernel with PDS scheduler as culprit for the stuttery cursor in Heroes of the Storm XWayland. With mainline 5.4 kernel, it runs fine.

Though Shadow of the Tomb Raider (native Wayland) is unchanged. It runs with much lower fps (way below refresh rate) than the other game, if that makes a difference.

[aufkrawall]

When starting Sway with -Dnoatomic, the mouse cursor stuttering in Shadow of the Tomb Raider is gone.

[kennylevinsen]

I see this increasingly often on my Intel setup. compositor-killer renders the machine unusable, but I don't think that's the issue. Moving the cursor around on this github page, it stalls rather often, and I will sometimes see text cursor blink before the mouse starts moving again.

[aufkrawall]

@emersion Can the missing stutter with -Dnoatomic be seen as a clue that the DRM atomic interface likely is at fault and not Sway? I'd include this information in the bug report to AMD then.

[aufkrawall]

@ascent12

With the atomic interface, cursor updates are synchronized with the primary plane update.

I suppose this is also the reason why the cursor has more input latency than without amdgpu.dc=0?
It's very noticeable with floating windows: Without amdgpu.dc=0, the window doesn't lag behind the cursor when moving because the drawing of cursor updates is delayed.

This makes me wonder why it was designed that way in the kernel. It totally defeats the purpose of a hardware cursor and basically turns it into a software one. How utterly dumb.

[ascent12]

You can just use WLR_DRM_NO_ATOMIC=1 instead of needing to mess around with the kernel command line.

This makes me wonder why it was designed that way in the kernel. It totally defeats the purpose of a hardware cursor and basically turns it into a software one. How utterly dumb.

It's working as intended. Atomic updates are required for 'frame perfect' presentation if we're using hardware overlays, and the cursor counts as one. Without it, we can get tearing. It also saves us from some of the nightmare of partial-state updates that are all too easy to get into the the legacy interface.

But yes, everyone agrees that it doesn't lead to the best user experience for cursors in heavy-load situations. From what I'm aware, there are 3 ways this can be fixed:

• Use the legacy cursor interface while using atomic for everything else.
• Use an AMEND atomic commit. This was specifically intended for this cursor case, and has not been upstreamed yet, and I don't know if it will be.
• Perform userspace "scheduling" of buffers, so we never submit an atomic commit which will block in the first place.

My preference is towards the third, and what swaywm/wlroots#894 is about.

[aufkrawall]

Thanks a lot for your explanation!
Could variant three also help with blocking of gamma adjustments? Currently, the compositor always misses the subsequent vblank interval if a gamma adjustment happens, e.g. Redshift.

[yurkobb]

I'm seeing the same behavior on Intel graphics, so it's probably not AMD-specific. My use case - rendening a clip in Blender using the EEVEE renderer.