Bug 109332

Summary: xf86-video-amdgpu - commit 0d60233d introduced stuttering with mouse cursor operations
Product: DRI Reporter: tempel.julian
Component: DRM/AMDgpuAssignee: Default DRI bug account <dri-devel>
Status: RESOLVED FIXED QA Contact:
Severity: normal    
Priority: medium CC: alexander, harry.wentland, me, nicholas.kazlauskas
Version: unspecified   
Hardware: x86-64 (AMD64)   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:

Description tempel.julian 2019-01-12 19:00:11 UTC 
Originally reported inside this ticket:
https://bugs.freedesktop.org/show_bug.cgi?id=106175#add_comment

---

There is stuttering caused by certain mouse cursor operations. To reproduce, e.g. do this:

-disable Plasma compositing with Ctr + Alt + F12 (or in the compositor settings and log out and in again)
-get the latest Compton release by yshui: https://github.com/yshui/compton
-start Compton (Mesa still enables vsync automatically in the latest release, this has changed with compton-git)
-open a Dolphin window and www.vsynctester.com in webbrowser
-now click Dolphin's title bar, move it a bit, release it and repeat the procedure several times in a row
-there should be stutter happening in the vsynctester.com browser window

-now quit Compton and start it with "vblank_mode=0 compton" to enable GLX compositing without vsync
-now the repeatedly moving Dolphin's window procedure described above shouldn't lead to any stutter
-when booting with amdgpu.dc=0, there also shouldn't be any stutter when vsync is kept enabled

This bug was introduced with this commit:
https://gitlab.freedesktop.org/xorg/driver/xf86-video-amdgpu/commit/0d60233d26ec70d4e1faa343b438e33829c6d5e4
Comment 1 Michel Dänzer 2019-01-14 11:07:15 UTC 
Still a DC issue. This is perfectly normal usage of the cursor UAPI, Wayland compositors such as gnome-shell use it similarly.
Comment 2 Nicholas Kazlauskas 2019-01-14 13:33:45 UTC 
In this case it's not actually the mouse operations themselves causing the stuttering but the framebuffer change. This is a known limitation with the async plane updates API in DRM and not something we can really fix in DC until there's a better API for async updates.

The page-flip IOCTL advertises itself as non-blocking but in reality it's not - if there's any commit work touching the plane it's going to be blocked until that finishes and that'll be any non asynchronous cursor update, gamma update, property update, or anything else that occurs. This is what the stuttering comes from.

So while it's a valid use of the cursor UAPI to double buffer cursors it's not something I'd really recommend doing for an atomic driver with how DRM is currently setup. Maybe this can be a configurable option in the meantime? I'm not sure how much work that would be to add and maintain, though.
Comment 3 Michel Dänzer 2019-01-14 15:21:37 UTC 
(In reply to Nicholas Kazlauskas from comment #2)
> Maybe this can be a configurable option in the meantime?
> I'm not sure how much work that would be to add and maintain, though.

Yeah, I'm afraid I'm not really hot on adding an option for this. We can't ask Wayland compositors to work around this, either.
Comment 4 tempel.julian 2019-10-20 11:20:54 UTC 
This was fixed in kernel with "Allow cursor async updates for framebuffer swaps".

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.