[Bug 106175] amdgpu.dc=1 shows performance issues with Xorg compositors when moving windows

[b***@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=106175

Bug ID: 106175
Summary: amdgpu.dc=1 shows performance issues with Xorg
compositors when moving windows
Product: DRI
Version: unspecified
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
Severity: normal
Priority: medium
Component: DRM/AMDgpu
Assignee: dri-***@lists.freedesktop.org
Reporter: ***@gmail.com

Created attachment 138987
--> https://bugs.freedesktop.org/attachment.cgi?id=138987&action=edit
dmesg

When amdgpu.dc=1 and an Xorg compositor are enabled at the same time, there is
stuttering when moving windows.
It's most visible with Compton (which is completely stutter-free when
amdgpu.dc=0), but also KWin and to a lesser extent also Gnome-Mutter.
It happens also with GPU clocks forced to maximum, so it doesn't seem to be a
powersaving issue.
In the recent past, there was an issue with performance degrading when
amdgpu.dc=1 and an Xorg compositor are enabled and the hardware mouse cursor
was used, maybe it's still related (just guessing though)?

Tested with Linux 4.17 RC1 and drm-next-4.18-wip (4.16.1.52132fd03)
xorg-server 1.19.6+13+gd0d1a694f (amdgpu DDX & modesetting)
RX 560

[b***@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=106175

--- Comment #1 from ***@gmail.com ---
Created attachment 138988
--> https://bugs.freedesktop.org/attachment.cgi?id=138988&action=edit
xorg log

[b***@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=106175

Michel DÀnzer <***@daenzer.net> changed:

What |Removed |Added
----------------------------------------------------------------------------
Attachment #138988|text/x-log |text/plain
mime type| |

[b***@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=106175

Michel DÀnzer <***@daenzer.net> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@amd.com

--- Comment #2 from Michel DÀnzer <***@daenzer.net> ---
Does this also happen without overriding the EDID of the DVI-D output?

[b***@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=106175

--- Comment #3 from ***@gmail.com ---
Yes, then it also occurs with the monitor's resolution/refreshrate provided by
its own edid (2560x1440 59.95Hz). Sorry, should have mentioned that.

Without compositor, moving of windows looks smooth. I also tried all vsync
settings provided by Compton, but all show the stuttery behavior with
amdgpu.dc.

[b***@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=106175

--- Comment #4 from ***@gmail.com ---
I found out that it's still related to the hardware cursor.
When I set Option "SWCursor" "true" in Xorg config, moving windows is smooth.

The mouse uses 1000Hz polling rate, if that makes any difference.
To spot the stuttering best, set acceleration profile to flat for libinput.

Btw: There is also a little problem with Redshift and hardware cursor, it turns
more yellow/orange than the rest of the screen. Using software cursor works
around this problem as well.

[b***@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=106175

--- Comment #5 from Mariusz Ceier <mceier+***@gmail.com> ---

amdgpu.dc=1 also causes performance issue with 2 games I own: "Rise of the
Tomb Raider" and "Helium Rain" (UE4 game with sources publicly available on
github).

I have 2 monitors (1st is 60Hz, 2nd in 144Hz). During tests I was using
1920x1080 resolution in both games which is 60Hz on both monitors.

1. With amdgpu.dc=0 everything is fine.

2. With amdgpu.dc=1:

The issue was showing up only in menus when cursor was visible and was in the
game window e.g. when Helium Rain was running on 2nd monitor (fullscreen)
and I was moving mouse over its window - mouse was lagging/stuttering/not
responding and Xorg server was producing messages like below in Xorg.0.log:

(II) event5 - USB Gaming Mouse: SYN_DROPPED event - some input events have
been lost.
(EE) client bug: timer event5 debounce short: offset negative (-7ms)


When I moved mouse to the 1st monitor the messages were not produced and mouse
was not lagging.

I tried few things (including switching from full dyntick system to idle
dyntick) until finally MrCooper at #xorg-devel suggested trying amdgpu.dc=0
which fixed the issue.

With amdgpu.dc=1 latencytop was showing that drm_modeset_backoff was taking
~20ms.

I was using kernel 4.17.0-rc1 and 4.17.0-rc2, Mesa 18.2.0-devel
(git-d136a5fad9) and X.Org X Server 1.19.99.904 (1.20.0 RC 4) with
xf86-video-amdgpu and radeonsi.

I'm using 1000Hz gaming mouse.

[b***@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=106175

--- Comment #6 from Mariusz Ceier <mceier+***@gmail.com> ---
I forgot about - I have Radeon Fury X graphics card.

[b***@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=106175

--- Comment #7 from Harry Wentland <***@amd.com> ---
Does your kernel tree have the following patches?

90fef6476917 Revert "drm/amd/display: disable CRTCs with NULL FB on their
primary plane (V2)"
c7bd22893408 Revert "drm/amd/display: fix dereferencing possible ERR_PTR()"

If not can you grab the latest drm-next-4.18-wip and check again? Those reverts
should have fixed problems where mouse movement would slow the system down.

[b***@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=106175

--- Comment #8 from Mariusz Ceier <mceier+***@gmail.com> ---
I had these patches in the kernel tree - mine is from 22nd April, while these
patches were committed on 12th April.

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?ofs=350

[b***@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=106175

--- Comment #9 from ***@gmail.com ---
I got them too. Before those commits, my issue was way more severe. It's still
really nasty stutter though.

[b***@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=106175

--- Comment #10 from Mike Bendel <***@exophase.com> ---
I have the same issue. For me amdgpu.dc=0 does not really fix it either. I have
a 3840x1600 monitor running at 75 Hz. This is the different behavior I noticed
when toggling the DC setting:

amdgpu.dc=0

Moving windows smooth most of the time but cursor frequently skips frames

amdgpu.dc=1

There is stutter/tearing in the movement of windows but the cursor is
completely smooth otherwise.

Running 4.16.2 kernel here with a Radeon Pro WX 7100.

[b***@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=106175

--- Comment #11 from ***@gmail.com ---
I noticed that this issue also exists apart from Xorg compositors.
When I run Serious Sam: Fusion (both OpenGL and Vulkan) in fullscreen (no Xorg
compositor enabled in the background), the mouse cursor (hardware cursor) in
the main menu can be moved without stuttering. But as soon as I enable vsync in
the game, its movement becomes stuttery. Again no problem with amdgpu.dc=0.

[b***@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=106175

--- Comment #12 from ***@gmail.com ---
Latest drm-next-4.18-wip aa1bce17d841a362d40da940487e13affe4c7b3b still shows
the same behavior.
I'd be happy if more users would comment on this, since it makes use of
amdgpu.dc totally impossible for me.

[b***@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=106175

--- Comment #13 from ***@gmail.com ---
When I use modesetting driver with Option "PageFlip" "false", the stuttering is
gone (however, as expected tearing is not fully prevented anymore).
So there might be an actual connection to pageflipping?

[b***@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=106175

--- Comment #14 from Michel DÀnzer <***@daenzer.net> ---
(In reply to tempel.julian from comment #13)

Post by b***@freedesktop.org
So there might be an actual connection to pageflipping?

Yeah, the problem seems to be a bad interaction between page flipping and
cursor updates.

FWIW, page flipping can be disabled with xf86-video-amdgpu as well, with

Option "EnablePageFlip" "false"

[b***@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=106175

--- Comment #15 from ***@gmail.com ---
I just tried that option with the xf86 amdgpu DDX driver and as expected,
stuttering disappears in exchange for tearing close to the very top of the
screen.

I'm really glad you could confirm the issue, the absent reports of other users
really worried me that I'd have to live forever with it.

[b***@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=106175

--- Comment #16 from ***@gmail.com ---
I have this issue too, disabling page flipping fixes it for me on my vega10. It
started with 4.16rc1 IIRC

[b***@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=106175

--- Comment #17 from Michel DÀnzer <***@daenzer.net> ---
https://patchwork.freedesktop.org/patch/227925/ might provide inspiration for
how this could be solved.

[b***@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=106175

--- Comment #18 from David Francis <***@amd.com> ---
My hypothesis is that has something to do with the mouse polling rate.

Could you set the polling rate to 125 Hz (8 ms) and see if the problem
persists?

This information will help us troubleshoot the problem.

Set mouse polling rate:
https://wiki.archlinux.org/index.php/mouse_polling_rate

[b***@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=106175

--- Comment #19 from Michel DÀnzer <***@daenzer.net> ---
(In reply to David Francis from comment #18)

Post by b***@freedesktop.org
My hypothesis is that has something to do with the mouse polling rate.

What is that hypothesis based on?

The kernel is supposed to be able to process any number of
DRM_IOCTL_MODE_CURSOR(2) ioctls in parallel with a DRM_IOCTL_MODE_PAGE_FLIP
ioctl, without them interfering with each other. Most likely there's an issue
in the DC code interfering this. See the patch I referenced in comment 17 for
an example of what might need to be done to solve this.

[b***@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=106175

--- Comment #20 from Michel DÀnzer <***@daenzer.net> ---
Note that the ioctls don't literally run "in parallel"; both ioctls are called
by the Xorg main thread, so they can't preempt each other. What I mean is that
any number of cursor ioctls can happen while a page flip is pending.

[b***@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=106175

--- Comment #21 from ***@gmail.com ---
Don't want to nag at anyone, but this bug still makes DC unusable for me and
thus is a real dealbreaker. Does implementing a fix for it require lots of
efforts?

[b***@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=106175

***@sub.red changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@sub.red

--- Comment #22 from ***@sub.red ---
Created attachment 140858
--> https://bugs.freedesktop.org/attachment.cgi?id=140858&action=edit
GALLIUM_HUD showing stuttering

I can confirm the issue.

Having a Radeon R9 290X (Hawaii XT), DC introduces heavy stuttering on a
composited X desktop while interacting with the window manager. This stuttering
can't be resolved by forcing high power states.

Attached is a screenshot to give an impression of the stuttering.
Top left is the GALLIUM_HUD with the compositor's frame rate and frame time
graph. On the right, there is Firefox with the page
Loading Image...&pps=960&pursuit=0&height=0 having
hardware acceleration force-enabled and also showing fps/frametime graphs. The
web page has continuous movement, ensures that there is a screen update every
frame and makes it easy to detect stutter.
This looks perfectly fine and the graphs represent that as well.
On the bottom there is the same setup but while changing window focus or moving
a third window around. Firefox stutters as hell (suspecting vsync stuttering)
and the graphs show that as well.

Disabling DC resolves the issue completely and the bottom scenario would look
and feel the same as the upper one with DC.

In this current situation, I could disable DC and have a smooth desktop at the
cost of several dozens of watts idle power or save power and use a stuttering
desktop with DC enabled.

[b***@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=106175

--- Comment #23 from ***@gmail.com ---
If I bought Vega, Raven Ridge or, in the future, Navi, I'd be really annoyed by
this bug because I had to turn off page flipping, resulting in unacceptable
tearing. :(

Could we please get an update?

[b***@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=106175

--- Comment #24 from Jordan L <***@amd.com> ---
The challenge here is that we still can't seem to reproduce this internally on
any of our setups. Can anyone identify a commonality in setup to help isolate
the reproducing behaviour?

[b***@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=106175

--- Comment #25 from ***@gmail.com ---
It doesn't seem to be related to a certain GCN generation, as there are exactly
matching reports of at least Hawaii, Polaris 10/11 and Vega 10 (probably also
Fiji).

It probably neither is related to the type of display output, as I am using
DL-DVI and grmat afaik uses Display Port.
And I suppose we all tried standard refreshrate of 60Hz without success.

So, unfortunately, I am rather clueless.

But I just noticed we haven't yet followed David's idea of setting a low
"standard" mouse polling rate of 125Hz.
I currently don't have my Radeon installed, so I can't give this a quick try
(but can do so in the future).

Does anybody have this issue with a native resolution of 1920x1080 60Hz? I
haven't tested such a display yet.

[b***@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=106175

--- Comment #26 from ***@sub.red ---
Yes, I'm using DP (required for 144 Hz with WQHD).

However, I just reproduced the issue on a 19" monitor with 1280x1024 at 60 Hz
and with a cheap old mouse with a 100 Hz polling rate. The issue is no *that*
bad with the low polling rate but still very much noticeable.

[b***@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=106175

--- Comment #27 from ***@gmail.com ---
Is this commit related to it?
https://lists.freedesktop.org/archives/amd-gfx/2018-October/027726.html

[b***@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=106175

--- Comment #28 from Nicholas Kazlauskas <***@amd.com> ---
(In reply to tempel.julian from comment #27)

Post by b***@freedesktop.org
Is this commit related to it?
https://lists.freedesktop.org/archives/amd-gfx/2018-October/027726.html

It shouldn't be. You would likely be experiencing a driver hang in this case
because of the fault.

[b***@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=106175

--- Comment #29 from ***@gmail.com ---
I gave it a try again: Unfortunately, there are no improvements to report with
latest 4.21-wip vs. the status of some months ago.
I really wonder how you can have trouble reproducing. This is not meant as a
reproach, but it's really frustrating.

[b***@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=106175

--- Comment #30 from ***@gmail.com ---
https://github.com/yshui/compton/issues/25 - related to this issue

Some tests me and others did in compton shows there is some relation with vsync
issues and the HW cursor. When I turn swcursor on in xorg config both kwin
compositor and compton get significantly smoother.
Similar behavior is noticeable in some games for me, game stays smooth when
playing with keyboard or gamepad then you move the mouse and it starts
stuttering hard. With swcursor I get a bit of input lag but smoother
performance overall.

[b***@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=106175

--- Comment #31 from Michel DÀnzer <***@daenzer.net> ---
Note that SWcursor completely disables page flipping, at least with
xf86-video-amdgpu, because the two things are fundamentally incompatible with
each other. Does only disabling page flipping also avoid the problem?

[b***@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=106175

--- Comment #32 from ***@sub.red ---
(In reply to Michel DÀnzer from comment #31)

Post by b***@freedesktop.org
Does only disabling page flipping also avoid the problem?

Not from what I can tell.

Post by b***@freedesktop.org
Option "EnablePageFlip" "off"

results in

Post by b***@freedesktop.org
[ 35496.178] (II) AMDGPU(0): KMS Pageflipping: disabled

obvious stuttering is still present with TearFree on.

[b***@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=106175

--- Comment #33 from ***@gmail.com ---
I suppose TearFree forces pageflipping regardless, as we don't see any tearing
with that configuration.

[b***@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=106175

--- Comment #34 from Michel DÀnzer <***@daenzer.net> ---
(In reply to tempel.julian from comment #33)

Post by b***@freedesktop.org
I suppose TearFree forces pageflipping regardless, as we don't see any
tearing with that configuration.

Right, you'd have to disable TearFree as well. Can be done at runtime with

xrandr --output <output name> --set TearFree off

[b***@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=106175

--- Comment #35 from ***@gmail.com ---
(In reply to Michel DÀnzer from comment #31)

Post by b***@freedesktop.org
Note that SWcursor completely disables page flipping, at least with
xf86-video-amdgpu, because the two things are fundamentally incompatible
with each other. Does only disabling page flipping also avoid the problem?

Justed tested it and yes, disabling pageflip also gets rid of stutter for me.

[b***@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=106175

--- Comment #36 from ***@gmail.com ---
So, to help find the origin of the issue, there are a few options that get rid
of stutter when compositing:

1 - amdgpu.dc=0 - The old DC seems unaffected by the bug.
2 - SWcursor on - Unaffected by bug because it disables pageflipping
3 - Pageflipping off

[b***@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=106175

--- Comment #37 from ***@gmail.com ---
I think software cursor would also be unusable even if it left pageflipping on.
It causes nasty issues like flickering cursor or other visual corruption.

[b***@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=106175

--- Comment #38 from ***@gmail.com ---
(In reply to tempel.julian from comment #37)

Post by b***@freedesktop.org
I think software cursor would also be unusable even if it left pageflipping
on. It causes nasty issues like flickering cursor or other visual corruption.

Yes I also noticed those, I think we can open another issue for that.

[b***@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=106175

--- Comment #39 from ***@sub.red ---
(In reply to Michel DÀnzer from comment #34)

Post by b***@freedesktop.org
Right, you'd have to disable TearFree as well.

Then I think the logs should represent that, even when the manpage tells me
that tearfree is using page flipping. If i set explicitly to off, and the log
says so, I expect it to be off.

And yes, disabling page flipping "resolves" the issue, but that's not new
knowledge.

[b***@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=106175

Michel DÀnzer <***@daenzer.net> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@amd.com

--- Comment #40 from Michel DÀnzer <***@daenzer.net> ---
For the DC guys: We've now confirmed that the problem is due to some bad
interaction between page flips and HW cursor updates.


(In reply to tempel.julian from comment #37)

Post by b***@freedesktop.org
I think software cursor would also be unusable even if it left pageflipping
on. It causes nasty issues like flickering cursor or other visual corruption.

Yeah, that's why xf86-video-amdgpu disables DRI page flipping while there's an
SW cursor, as I said in comment 31. Note that the modesetting driver doesn't do
this, allowing users to run into those issues.


(In reply to grmat from comment #39)

Post by b***@freedesktop.org
(In reply to Michel DÀnzer from comment #34)

Post by b***@freedesktop.org
Right, you'd have to disable TearFree as well.

Then I think the logs should represent that, even when the manpage tells me
that tearfree is using page flipping. If i set explicitly to off, and the
log says so, I expect it to be off.

Patches or at least specific suggestions welcome, but I'm afraid it's tricky to
describe all possible interactions concisely and clearly. DRI page flipping and
TearFree are mostly separate things, but they use the same kernel page flipping
mechanism, which is what matters for this issue.

[b***@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=106175

--- Comment #41 from ***@gmail.com ---
Guys, please take a closer look at this, its actually a lot worse than what OP
describes and affect a lot of other use cases, vsync is a vital feature for any
kind of PC activity, literally everything you do on a computer sucks with
tearing.


amdgpu.dc=1 has been default for a few kernels, has been updated almost daily
with features and various other fixes but basic vital stuff like vsync and
higher frequencies (flickering and screen glitches) have been broken for many
people with all ranges of cards for a while now.


BTW, TearFree is slow and stuttery even with old dc for me. I'd love to provide
more info about any of those issues and help testing as I'm sure does others
users, we just need a bit more attention from you devs.

Features are awesome, I love to wake up everyday with new mesa/drm features but
what I love even more is wake up with an annoying bug fixed.

[b***@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=106175

--- Comment #42 from Brandon Wright <***@gmail.com> ---
This is pretty serious. Just moving the mouse cursor around while something
slightly GPU-heavy is running at 60hz can produce frame-skipping.

I switched the display core off with amdgpu.dc=0 and everything got
significantly smoother and chromium doesn't chug on heavy pages any more.

I'm using 4.19.x. I haven't tried the drm-next-4.21-wip tree yet.

[b***@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=106175

--- Comment #43 from ***@gmail.com ---
(In reply to Brandon Wright from comment #42)

Post by b***@freedesktop.org
This is pretty serious. Just moving the mouse cursor around while something
slightly GPU-heavy is running at 60hz can produce frame-skipping.
I switched the display core off with amdgpu.dc=0 and everything got
significantly smoother and chromium doesn't chug on heavy pages any more.
I'm using 4.19.x. I haven't tried the drm-next-4.21-wip tree yet.

Dont need to try drm-next-4.21-wip, just did and it still has the issue

If devs want an easy test case, use these links for reproducing it in chromium:

https://www.vsynctester.com/
https://www.testufo.com/photo
https://www.slither.io

move the cursor around, move/resize some windows. you will notice it

the vsync/cursor stutters and frame-skips are pretty noticeable with dc=1 on
all three links

KWin, compton, TearFree, mutter, xfwm4 all have the same problems.

[b***@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=106175

--- Comment #44 from Brandon Wright <***@gmail.com> ---
You're too late, I already tried it. But as you say, there's no improvement.

[b***@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=106175

--- Comment #45 from ***@gmail.com ---
(In reply to bmilreu from comment #43)

Post by b***@freedesktop.org
If devs want an easy test case, use these links for reproducing it in
https://www.vsynctester.com/
https://www.testufo.com/photo
https://www.slither.io
move the cursor around, move/resize some windows. you will notice it
the vsync/cursor stutters and frame-skips are pretty noticeable with dc=1 on
all three links
KWin, compton, TearFree, mutter, xfwm4 all have the same problems.

I just tried dc=1 and I only seem to have a problem if I use TearFree. Things
are totally fine without TearFree.

To be clear about what I'm doing here right now:

I made sure DC is enabled:

$ systool -vm amdgpu | grep dc
dc = "1"
$ dmesg | grep -i display
[ 1.014297] [drm] Display Core initialized with v3.1.59!

I removed TearFree from my X config:

$ cat /etc/X11/xorg.conf.d/20-amdgpu.conf
Section "OutputClass"
Identifier "my amdgpu settings"
MatchDriver "amdgpu"
Option "DRI" "3"
EndSection

And I started Compton like this to make sure it's a clean config:

$ compton --config /dev/null --backend glx --vsync opengl

With this setup, I don't seem to have any stutter. I visited the websites you
mention in a Chromium window, then opened another window and tried moving
things around and resizing. It behaves fine, same as what I know from normally
using dc=0.

Kernel is 4.19.2, Mesa 18.2.4, Xorg 1.20.3, the GPU is a RX480, monitor is 60
Hz.

After I had typed this, I have now added TearFree to the X config and restarted
X:

$ cat /etc/X11/xorg.conf.d/20-amdgpu.conf
Section "OutputClass"
Identifier "my amdgpu settings"
MatchDriver "amdgpu"
Option "TearFree" "true"
Option "DRI" "3"
EndSection

Now, with TearFree enabled, things are super terrible. Trying to move a window
around has extreme stutter, it seems to drop frames. If I restart Compton with
"GALLIUM_HUD=fps" and then try moving a window around in circles, I can see it
stays below 40 fps instead of hitting the 60 fps that it should be running at.

[b***@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=106175

--- Comment #46 from Brandon Wright <***@gmail.com> ---
I've never run TearFree, so that's not the case here. My Xorg config is similar
to yours, just amdgpu and DRI 3. I did have an extra section to use evdev
instead of libinput, but I tried removing that and there's still no change.

[b***@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=106175

--- Comment #47 from Michel DÀnzer <***@daenzer.net> ---
FWIW, note that TearFree can be toggled at runtime using the RandR output
property of the same name. At its default value "auto", TearFree is
automatically enabled for an output using rotation / scaling / other
transformations.

(In reply to bmilreu from comment #41)

Post by b***@freedesktop.org
BTW, TearFree is slow and stuttery even with old dc for me.

Sounds like the issue you're seeing with TearFree might be different from the
one this report is about.

[b***@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=106175

--- Comment #48 from ***@gmail.com ---
With amdgpu.dc=0, TearFree works as expected for me (no tearing without
compositor, scrolling in Firefox windowed is free of stutter, no issues with
compositor vsync either).

I think we should leave TearFree out of this as it's entirely unrelated, apart
from the fact that it forces pageflipping.

Regarding the original issue with amdgpu.dc=1:
Still totally unchanged for me with latest stable versions and also 4.21-wip,
llvm-svn, mesa-git, libdrm-git, xorg-server 1.20.3 and modesetting /
xf86-video-amdgpu-git on Arch.

I'm getting an Asus Vega 56 Strix card tomorrow, which I will try instead of my
current MSI Aero RX 560 card. But since there were already reports for Vega,
I'm not hopeful.

[b***@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=106175

--- Comment #49 from Brandon Wright <***@gmail.com> ---
I'm going to speculate that maybe the hardware cursor updates are triggering an
update to the vsync timestamp counter or msc that's incorrect and throwing off
the timing.

[b***@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=106175

I have this issue too, disabling page flipping fixes it for me on my vega10. It started with 4.16rc1 IIRC

Negative. I checked back as far as the DC/DAL was integrated (4.15) and it's
been there from the start.

It's in the kernel somewhere, in the DC DRM layer above the device specific
stuff. I looked in and couldn't see anything that's grossly problematic. I
suspect Michel's suggestion for async cursor updates might be the fix, but I
can't help wondering why the legacy DRM code is unaffected.

[b***@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=106175

--- Comment #51 from Alex Deucher <***@gmail.com> ---
DC uses the atomic KMS interface, the old code uses the legacy KMS interface.

[b***@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=106175

--- Comment #52 from Brandon Wright <***@gmail.com> ---
Ok, I think I understand what's going on. Forgive me if this sounds stupid, I'm
looking at the DRM code for the first time.

The old KMS interface uses what's flagged as "legacy" cursor updates. These are
"asynchronous" in that they're handled and passed to the hardware as they come
in. On the vertical retrace interrupt, it uses whatever the last data passed in
was.

My theory is the DC interface isn't passing these on to the hardware
immediately. It's aggregating them until the next sync, when they're all
handled at once. And that is what's causing the disturbance at page-flip time.
High-report-rate mice might exacerbate it.

Intel's driver hasn't merged that async code yet. It's still using legacy
cursor updates and working around this.

The DC code seems to have a TODO comment in amdgpu_dm.c that suggests something
about the legacy_cursor_update flag, but it doesn't do anything with it.

[b***@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=106175

--- Comment #53 from ***@gmail.com ---
(In reply to rropid from comment #45)

Post by b***@freedesktop.org
(In reply to bmilreu from comment #43)

Post by b***@freedesktop.org
If devs want an easy test case, use these links for reproducing it in
https://www.vsynctester.com/
https://www.testufo.com/photo
https://www.slither.io
move the cursor around, move/resize some windows. you will notice it
the vsync/cursor stutters and frame-skips are pretty noticeable with dc=1 on
all three links
KWin, compton, TearFree, mutter, xfwm4 all have the same problems.

I just tried dc=1 and I only seem to have a problem if I use TearFree.
Things are totally fine without TearFree.
$ systool -vm amdgpu | grep dc
dc = "1"
$ dmesg | grep -i display
[ 1.014297] [drm] Display Core initialized with v3.1.59!
$ cat /etc/X11/xorg.conf.d/20-amdgpu.conf
Section "OutputClass"
Identifier "my amdgpu settings"
MatchDriver "amdgpu"
Option "DRI" "3"
EndSection
$ compton --config /dev/null --backend glx --vsync opengl
With this setup, I don't seem to have any stutter. I visited the websites
you mention in a Chromium window, then opened another window and tried
moving things around and resizing. It behaves fine, same as what I know from
normally using dc=0.
Kernel is 4.19.2, Mesa 18.2.4, Xorg 1.20.3, the GPU is a RX480, monitor is
60 Hz.
After I had typed this, I have now added TearFree to the X config and
$ cat /etc/X11/xorg.conf.d/20-amdgpu.conf
Section "OutputClass"
Identifier "my amdgpu settings"
MatchDriver "amdgpu"
Option "TearFree" "true"
Option "DRI" "3"
EndSection
Now, with TearFree enabled, things are super terrible. Trying to move a
window around has extreme stutter, it seems to drop frames. If I restart
Compton with "GALLIUM_HUD=fps" and then try moving a window around in
circles, I can see it stays below 40 fps instead of hitting the 60 fps that
it should be running at.

"compton --vsync opengl" is a case less/not affected by this in my setup, try
--vsync opengl-swc, --vsync opengl-oml or --vsync opengl-mswc

Also try other compositors. Kwin, mutter, xfwm4

[b***@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=106175

--- Comment #54 from ***@gmail.com ---
You should btw. also set CPU clock governor to either acpi-cpufreq performance
or intel_pstate performance, since governors like powersave, ondemand or
schedutil can already cause severe stuttering at vsynctester.com, even without
a compositor.

The result should be 100% stutter free, at least that's the case for me with
amdgpu.dc=0. This way you should be able to be absolutely sure if the result is
badly affected by amdgpu.dc=1.

[b***@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=106175

--- Comment #55 from Brandon Wright <***@gmail.com> ---
Created attachment 142558
--> https://bugs.freedesktop.org/attachment.cgi?id=142558&action=edit
Patch that "fixes" the problem.

I've attached a patch that fixes the problem for me. It copies parts from the
intel patch and uses the existing async infrastructure for the cursor.

It's really tiny, so I hope this is helpful enough to get this problem fixed
quick.

[b***@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=106175

--- Comment #56 from ***@gmail.com ---
(In reply to Brandon Wright from comment #55)

Created attachment 142558 [details] [review]
Patch that "fixes" the problem.
I've attached a patch that fixes the problem for me. It copies parts from
the intel patch and uses the existing async infrastructure for the cursor.
It's really tiny, so I hope this is helpful enough to get this problem fixed
quick.

Tested and solved for me on Polaris RX580. This also solves my stuttering with
TearFree, which makes possible to avoid using a compositor only for vsync.
Games that stuttered with mouse movement also fixed.

Review and push this asap as a fix, you are a hero.

[b***@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=106175

--- Comment #57 from ***@gmail.com ---
@Brandon Wright
Sorry for double posting, but I think if you send the patch to amd-gfx
mailing-list directly it might get reviewed faster.

[b***@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=106175

--- Comment #58 from Nicholas Kazlauskas <***@amd.com> ---
(In reply to Brandon Wright from comment #55)

Created attachment 142558 [details] [review]
Patch that "fixes" the problem.
I've attached a patch that fixes the problem for me. It copies parts from
the intel patch and uses the existing async infrastructure for the cursor.
It's really tiny, so I hope this is helpful enough to get this problem fixed
quick.

This is a nice attempt but it only resolves the problem because it relies on
the blocking behavior in atomic check that amdgpu_dm currently does (and
shouldn't be doing).

Asynchronous updates can and will occur in parallel with other commits on
worker threads. Without the wait in atomic_check you'll see the IGT legacy
cursor tests break with this patch (and there will probably be system faults as
well).

There are larger problems within amdgpu_dm's commit tail that if addressed
should resolve this issue for compton I'd imagine.

[b***@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=106175

--- Comment #59 from ***@gmail.com ---
(In reply to Nicholas Kazlauskas from comment #58)

Post by b***@freedesktop.org
(In reply to Brandon Wright from comment #55)

Created attachment 142558 [details] [review] [review]
Patch that "fixes" the problem.
I've attached a patch that fixes the problem for me. It copies parts from
the intel patch and uses the existing async infrastructure for the cursor.
It's really tiny, so I hope this is helpful enough to get this problem fixed
quick.

This is a nice attempt but it only resolves the problem because it relies on
the blocking behavior in atomic check that amdgpu_dm currently does (and
shouldn't be doing).
Asynchronous updates can and will occur in parallel with other commits on
worker threads. Without the wait in atomic_check you'll see the IGT legacy
cursor tests break with this patch (and there will probably be system faults
as well).
There are larger problems within amdgpu_dm's commit tail that if addressed
should resolve this issue for compton I'd imagine.

Since you've been working on Freesync, you should know your patches are also
affected by this bug on some wine games. Any chance you could you kindly try to
tackle this?

btw, I don't have igt on my system atm, nor got any system fault yet with the
patch. I really need dc for the extra headphone jack, mine is broken atm :(

[b***@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=106175

Post by b***@freedesktop.org
There are larger problems within amdgpu_dm's commit tail that if addressed
should resolve this issue for compton I'd imagine.

Honestly, I don't care about compton. I don't think you realize the effects of
this issue. It seriously affects performance when the cursor is in motion with
any page-flipping application. GNOME and KDE, while the window motion is less
affected, stutter in composited client applications.

Post by b***@freedesktop.org
This is a nice attempt but it only resolves the problem because it relies on
the blocking behavior in atomic check that amdgpu_dm currently does
(and shouldn't be doing).
Asynchronous updates can and will occur in parallel with other commits on
worker threads. Without the wait in atomic_check you'll see the IGT legacy
cursor tests break with this patch (and there will probably be system faults
as well).

You'd have to point this out to me, because I didn't see anything that would
obviously block, unless it's buried in dc_validate_plane.

Since, as you say, atomic_check is blocking for now, why not work around this
issue with a tiny change. If someone ever gets around to doing things the
correct way it's no big deal to remove.

[b***@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=106175

--- Comment #61 from ***@gmail.com ---
Thanks a lot @ Brandon Wright, your patch really does the trick. I also totally
agree on your opinion that it should be mainlined as at least a temporary
solution (and also get backported to older kernels).

I just noticed that it works fine with xf86-video-amdgpu driver, but with
modesetting driver, xorg or the driver freezes when starting/logging in. Not
sure if this is related to latest 4.21-wip-changes or the cursor patch though.

[b***@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=106175

--- Comment #62 from Brandon Wright <***@gmail.com> ---
(In reply to tempel.julian from comment #61)

Post by b***@freedesktop.org
I just noticed that it works fine with xf86-video-amdgpu driver, but with
modesetting driver, xorg or the driver freezes when starting/logging in. Not
sure if this is related to latest 4.21-wip-changes or the cursor patch
though.

I'm getting the modesetting freeze, too, on 4.20-rc3, so it's likely the cursor
patch. I called it a "fix", in quotation marks for a reason. I've barely looked
at the KMS/DRM stuff for an hour, so I have no clue what I'm doing. I just
wanted to show the AMD guys that we have pinpointed the problem, give them
something that we can confirm no longer produces the problem, and hope that
they'd go ahead and do things correctly.

[b***@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=106175

--- Comment #63 from ***@gmail.com ---
(In reply to Brandon Wright from comment #62)

Post by b***@freedesktop.org
(In reply to tempel.julian from comment #61)

Post by b***@freedesktop.org
I just noticed that it works fine with xf86-video-amdgpu driver, but with
modesetting driver, xorg or the driver freezes when starting/logging in. Not
sure if this is related to latest 4.21-wip-changes or the cursor patch
though.

I'm getting the modesetting freeze, too, on 4.20-rc3, so it's likely the
cursor patch. I called it a "fix", in quotation marks for a reason. I've
barely looked at the KMS/DRM stuff for an hour, so I have no clue what I'm
doing. I just wanted to show the AMD guys that we have pinpointed the
problem, give them something that we can confirm no longer produces the
problem, and hope that they'd go ahead and do things correctly.

Probably easy to make the workaround only activate on xf86-video-amdgpu. I
luckily don't need the modesetting driver for anything that I'm aware off, what
do you guys use that driver for ? Is it for GPU switching?

[b***@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=106175

--- Comment #64 from Nicholas Kazlauskas <***@amd.com> ---
Created attachment 142574
--> https://bugs.freedesktop.org/attachment.cgi?id=142574&action=edit
0001-drm-amd-display-Add-fast-path-for-legacy-cursor-plan.patch

This patch is similar to the async_update one but it takes care to lock if
anything is modifying the plane. It's very close to what i915 does with a few
minor differences with framebuffer handling.

I've tested it for compton with Gallium HUD up and I no longer see the issue on
mouse movement (cursor fb changes are still a bit slow, so you'll still
probably see spikes on cursor changes).

You can try this on top of amd-staging-drm-next and I'd imagine it'd fix your
problems.

[b***@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=106175

--- Comment #65 from ***@gmail.com ---
(In reply to Nicholas Kazlauskas from comment #64)

Created attachment 142574 [details] [review]
0001-drm-amd-display-Add-fast-path-for-legacy-cursor-plan.patch
This patch is similar to the async_update one but it takes care to lock if
anything is modifying the plane. It's very close to what i915 does with a
few minor differences with framebuffer handling.
I've tested it for compton with Gallium HUD up and I no longer see the issue
on mouse movement (cursor fb changes are still a bit slow, so you'll still
probably see spikes on cursor changes).
You can try this on top of amd-staging-drm-next and I'd imagine it'd fix
your problems.

Patch does work for me.

Is there an easy way to backport this to 4.19 mainline? Would be very useful to
integrate the fix into stable kernels.

As it is currently it wont work on 4.19 because it uses <drm/drm_atomic_uapi.h>
which isnt mainlined yet. Brandon's hack works on 4.19 just in case it matters.

Last question, is this patch https://patchwork.freedesktop.org/patch/263412/
you just submitted related to this issue?

Thanks a LOT for tackling this Nicholas and Brandon

[b***@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=106175

--- Comment #66 from Brandon Wright <***@gmail.com> ---
(In reply to bmilreu from comment #65)

Post by b***@freedesktop.org
Is there an easy way to backport this to 4.19 mainline? Would be very useful
to integrate the fix into stable kernels.
As it is currently it wont work on 4.19 because it uses
<drm/drm_atomic_uapi.h> which isnt mainlined yet. Brandon's hack works on
4.19 just in case it matters.

Just remove the header include. There was some refactoring, and the functions
needed in that file are in the others included.

Post by b***@freedesktop.org
Last question, is this patch https://patchwork.freedesktop.org/patch/263412/
you just submitted related to this issue?

Looks like it's related. Thanks for taking on our issue, Nicholas.

[b***@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=106175

--- Comment #67 from ***@gmail.com ---
Just wanted to note that applying
[PATCH 1/2] drm/amd/display: Use private obj helpers for dm_atomic_state
[PATCH 2/2] drm/amd/display: Remove wait for hw/flip done in atomic check
does not solve/workaround the issue, unlike Brandon's patch.

[b***@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=106175

--- Comment #68 from ***@gmail.com ---
(In reply to tempel.julian from comment #67)

Post by b***@freedesktop.org
Just wanted to note that applying
[PATCH 1/2] drm/amd/display: Use private obj helpers for dm_atomic_state
[PATCH 2/2] drm/amd/display: Remove wait for hw/flip done in atomic check
does not solve/workaround the issue, unlike Brandon's patch.

try 0001-drm-amd-display-Add-fast-path-for-legacy-cursor-plan.patch

[b***@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=106175

--- Comment #69 from ***@gmail.com ---
(In reply to bmilreu from comment #68)

Post by b***@freedesktop.org
try 0001-drm-amd-display-Add-fast-path-for-legacy-cursor-plan.patch

That one works, also with modesetting driver.

Regarding your question if modesetting driver is any beneficial: I'd say
generally not, as it doesn't offer every feature of the xf86 DDX driver.
But it can be sufficient in many cases, and I also just found a bug with xf86
driver + amdgpu.dc=1 causing stutter in mpv. So I'm lucky to have modesetting
as a fallback in the meantime.

[b***@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=106175

Brandon Wright <***@gmail.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
Attachment #142558|0 |1
is obsolete| |

--- Comment #70 from Brandon Wright <***@gmail.com> ---
Comment on attachment 142558
--> https://bugs.freedesktop.org/attachment.cgi?id=142558
Patch that "fixes" the problem.

Marked my patch obsolete.

[b***@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=106175

--- Comment #71 from ***@gmail.com ---
@Nicholas Kazlauskas
any reason not to push this fix to staging or next?

[b***@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=106175

--- Comment #72 from Brandon Wright <***@gmail.com> ---
(In reply to bmilreu from comment #71)

Post by b***@freedesktop.org
@Nicholas Kazlauskas
any reason not to push this fix to staging or next?

I agree. This will reduce stuttering for everyone, especially those who think
the problem is caused elsewhere and just discount it as bad software or
graphics card performance like I did.

[b***@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=106175

--- Comment #73 from ***@gmail.com ---
Yeah, I'd be extremely disappointing if this wouldn't land before linux 4.21
DRM merging window closes.
Like I already said, I think this is even worth getting backported to older
kernels, as I'd consider it an important fix. Likely every AMD Xorg user has
degraded performance because of this.

[b***@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=106175

--- Comment #74 from Brandon Wright <***@gmail.com> ---
Is anyone from the AMD driver team still following this?

Could we please have a review of Nicholas's patch and try to get it into 4.20?
It's not that disruptive code-wise, but it makes a big smoothness difference. I
can quickly compile a kernel/module for myself pretty easily, but most users
aren't going to be that technical or even know why things are so stuttery.

[b***@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=106175

--- Comment #75 from ***@gmail.com ---
Any update, please?

[b***@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=106175

--- Comment #76 from Brandon Wright <***@gmail.com> ---
https://patchwork.freedesktop.org/series/53589/

A new patch has been submitted. So it's in the pipeline for inclusion now.

[b***@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=106175

--- Comment #77 from ***@gmail.com ---
@Nicholas Kazlauskas
is there anything important in the new patch vs the first one? it fails a hunk
on 4.19 for me
thanks for submiting it to amd-gfx