cursor skipping (AMD related?)

[flood]

edit: see https://gitlab.freedesktop.org/drm/amd/issues/1001

i just built a new pc. graphics card is amd rx 5700 xt.
i'm on windows 10, although i suspect that doesn't matter.

guess what i see

video:
https://youtu.be/1HPUPG8BpTU?t=21

pictures:
60Hz

165Hz


cursor drops frames a lot (like every 2 seconds or so). this is quite ridiculous...

clues so far:
0. if i swap out the 5700xt for an old nvidia gtx460, then everything is normal (i.e. cursor motion is perfect)
1. it only affects the "hardware cursor". (cursor rendered on top of the composited desktop with position updated during the latest vblank.
"software cursor" is rendered together with the desktop).
for example in windows, if you drag around around a window, there will be a switch from a hardware to a software cursor. in this case, the software cursor motion does not skip
2. if i uninstall graphics drivers, such "microsoft basic rendering driver" or whatever is used, there is no issue. in this case, a software cursor is used always and it is smooth
3. happens in linux when using Xorg (only tested a live usb)
4. bios options/disabling cpu idle states, windows power settings, etc don't affect this
5. downgrading amd drivers doesn't change anything

[Chief Blur Buster]

Fascinating hardware-vs-software cursor observation!

What's your mouse poll Hz?

Have you tried different poll rates?

Have you tried different mice?

We've observed beat-frequency effects between poll rate and mouse Hz. And sometimes it's different even for the same poll Hz because of different internal sensor Hz and its internal smoothing algorithm, as well as rawmode (or not).

I'm wondering if a different poll sync is used for hardware cursor versus software cursor. And why that occurs -- differences in pollrate-compositingrate (Hz-vs-Hz) haromics / beat frequencies / aliasing effects.

The mouse can return different cursor-position behavors based on a low poll rate (e.g. read once per VSYNC) versus continuous polling (e.g. read every 1ms). This can create different aliasing effects, especially with different brands of mice that use different smoothing algorithms for its internal sensor rate (6000Hz). So that offset polls (e.g. polls 1.5ms later) might create different results than a poll 1ms and 2ms later after a previous poll. This can theoretically affect Hz-vs-Hz aliasing effects (beat frequencies, harmonics, etc)

I wonder if Windows polling behaviour might be dynamically changing depending on what you're doing and the system GPU load (e.g. graphics drawing).

As we approach higher Hz, the limit of 1000Hz mice becomes more visible. I am imagining that 360 Hz monitors may force the need for 2000 Hz mice eventually, in the Vicious Cycle Effect -- of bigger displays, higher resolutions, more pixels, wider FOV, higher refresh rates, creating more situations where limitations become human visible. 1000 Hz poll rate limitations will begin to show more visible limitations with future 360Hz and 480Hz monitors in keeping high-DPI mouseturns TestUFO-smooth without needing filtering. (Blur reduction & ultra-Hz requires a high mouse DPI setting to prevent mouseturns from being rough, and tiny mouse microstutters from pollrate limitations begin to be one of these new weak links). I can confirm that these poll rate issues are more visible at 240Hz 0.5ms GtG than it is at 165Hz 3ms GtG.

You've seen the old images already from the Blur Busters Mouse Guide

[flood]

eh, fascinating? more like really sad and disappointing tbh

1000hz. it's not a beat thing. look how the cursor before the skip is twice as bright in the picture. that means the cursor is being held for an extra frame. also it doesn't really happen periodically or anything

happens to the windows cursor in csgo too, in the main menu where the framerate is very high

afaik the way things are done is that the hardware cursor position is updated at the end of vblank before the top of the framebuffer is scanned. so cursor movement at the top of the screen has 0 lag. and cursor movement at the bottom has (display period - vblank) amount of lag

just tried an hdmi cable, also same thing.
might plug in my gtx460(lol) to test

[flood]

here's a (slow motion) video
https://youtu.be/1HPUPG8BpTU?t=21

i found some related things here:
https://community.amd.com/thread/231030
https://www.reddit.com/r/Amd/comments/9 ... t_drivers/
but disabling hdcp didn't do anything for me.

[Chief Blur Buster]

1000hz. it's not a beat thing. look how the cursor before the skip is twice as bright in the picture. that means the cursor is being held for an extra frame. also it doesn't really happen periodically or anything

No periodicity? Hmmm.

There must be many ways the polltime:photontime can diverge...

Trying to brainstorm:
- Compositing jitter misaligning the poll time. Since a delay in compositing may not show up as stutter as long as there's already VSYNC ON framebuffers to smooth things out.
- Sync technology setting (GSYNC windowed mode versus non-GSYNC mode); this can create lagfeel changes but potentially also compositing queue depth changes. This can be tested on an NVIDIA card, but you're using an AMD card...

Programming observation, might be related, might not be related:
I've seen some graphics drivers screw up VSYNC ON badly by erratically adding/dropping a frame in the queue, with zero visible stutters. Meaning the framebuffer backpressure isn't constant. There are times where I've seen VSYNC ON setting in some graphics drivers in some engines, suddenly accept 2 buffers instantaneously with no Present() blocking after being continually framebuffer backpressured. Basically in some continual Present() loops to continually backpressure VSYNC ON at 60 Hz -- I've occasionally seen behaviours of 16.7ms-16.7ms-16.7ms-0ms-33.3ms-16.7ms-16.7ms. Meaning suddenly, one frame presentation suddenly goes through instantly (doesn't block for a VBLANK), adds an extra frame buffer to the frame queue (2 waiting frames beyond front buffer), and the next call blocks twice as long. No stutters show up (because it's VSYNC ON and the buffer queue filters it) but a forced a inputtime:photontime divergence occured because the input reads being linked to Present() blockage time. Creating an erratic inputread latency (combined with an inputread-related stutter, like cursor jump, mouseturn jump, panning jump, or other artifact). I wonder if this behaviour is a graphics driver bug of some kind.

Then no mouse Hz or dpi settings will ever be able to fix that because it would be the graphics drivers quirk. Theoretically this can be fixed by present-time-monitoring or use waitable swapchains (and know the presentation time more accurately), if it is implemented correctly.

I don't know if the Windows desktop is prone to this 'quirk' or not, or if I am chasing wild geese and red herrings here -- but this is an observation that I have made.

I wonder if this is related?

[flood]

so i plugged in my old dusty gtx 460, installed nvidia drivers, and...

cursor motion is completely normal (i.e. perfect)

so this is almost certainly, as i suspected, related to amd drivers and/or the 5700xt card

that's some interesting phenomena about vsync that i didnt know about.
the hardware cursor, which is what i'm having issues with, does not deal with any sort of buffering though. as i understand, it's simply slapped onto the next frame at the end of every vblank.

one thing that is promising is that the skips seem to happen on linux (tried a few live distros) more than on windows. which suggests that it should be something fixable in firmware

[flood]

here's a video of the cursor skipping on linux (fedora lxde live usb. Xorg desktop with no composition)
60Hz screen, 240fps video. on youtube, you can use the , and . keys to step back and forth individual frames.
https://www.youtube.com/watch?v=4eL-rtNRHhY
i'm just dragging around a window. you can see how the window is always updated, even when the cursor skips and hangs behind a frame

[flood]

possibly very relevant:
https://gitlab.freedesktop.org/drm/amd/issues/1001

i'm reading through it right now
edit: yea apparently they have a patch for it now for the linux driver, search for 0001-drm-amd-display-Defer-cursor-lock-until-after-VUPDAT.patch

also:
https://www.reddit.com/r/Amd/comments/e ... on_is_one/