Created attachment 138142 [details]
dmesg

Created attachment 138143 [details]
xrandr --verbose

→ glxinfo | grep -i "OpenGL"                                                                                                                                                                
OpenGL vendor string: X.Org
OpenGL renderer string: AMD RAVEN (DRM 3.25.0 / 4.16.0-rc1-d2a3d23fa904, LLVM 7.0.0)
OpenGL core profile version string: 4.5 (Core Profile) Mesa 18.1.0-devel (git-5f129c05e6)
OpenGL core profile shading language version string: 4.50
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
OpenGL core profile extensions:
OpenGL version string: 3.1 Mesa 18.1.0-devel (git-5f129c05e6)
OpenGL shading language version string: 1.40
OpenGL context flags: (none)
OpenGL extensions:
OpenGL ES profile version string: OpenGL ES 3.1 Mesa 18.1.0-devel (git-5f129c05e6)
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.10
OpenGL ES profile extensions:

(In reply to txtsd from comment #0)
> The stuttering is caused by enabling TearFree via xrandr.
> When on `auto`, there is no stuttering, but when enabled by setting it to
> `on`, there is intense stuttering noticeable when dragging windows around,
> but it's also very noticeable when just moving the mouse around on the
> desktop with no windows open.

Since HW cursor updates are always supposed to work without delay, and there is no sign of an issue in the attached userspace information, this seems like a kernel (DC?) issue.

In the amd-gfx mailing list thread, you said that this started on 2018-03-07. Is that just when you enabled TearFree for the first time, or did this actually not happen with older kernels?

(In reply to Michel Dänzer from comment #4)
> (In reply to txtsd from comment #0)
> > The stuttering is caused by enabling TearFree via xrandr.
> > When on `auto`, there is no stuttering, but when enabled by setting it to
> > `on`, there is intense stuttering noticeable when dragging windows around,
> > but it's also very noticeable when just moving the mouse around on the
> > desktop with no windows open.
> 
> Since HW cursor updates are always supposed to work without delay, and there
> is no sign of an issue in the attached userspace information, this seems
> like a kernel (DC?) issue.
> 
> In the amd-gfx mailing list thread, you said that this started on
> 2018-03-07. Is that just when you enabled TearFree for the first time, or
> did this actually not happen with older kernels?

Yep. That was the first time I altered the TearFree property, and that's when it first appeared. I hadn't noticed it prior to that.

Also, is there an older kernel I should try? Give me a branch/commit, and I'll compile and see if the issue exists.

This occurs for me on the below Polaris system as well. Timing matches the dates in this thread. I've always had Tearfree option on though and it didn't occur before these last few weeks.

OS: Ubuntu 18.04 bionic
Kernel: x86_64 Linux 4.16.0-rc6+ (M-bab custom kernel with amd-staging-drm-next included)
DE: GNOME 
CPU: AMD A10-7860K Radeon R7, 12 Compute Cores 4C+8G @ 4x 3.9GHz [32.0°C]
GPU: Radeon RX 560 Series (POLARIS11 / DRM 3.25.0 / 4.16.0-rc6+, LLVM 6.0.0)+ Oibaf ppa

Graphics:  Card: Advanced Micro Devices [AMD/ATI] Baffin [Polaris11]
           Display Server: x11 (X.Org 1.19.6 ) driver: amdgpu Resolution: 1920x1080@59.79hz
           OpenGL: renderer: Radeon RX 560 Series (POLARIS11 / DRM 3.25.0 / 4.16.0-rc6+, LLVM 6.0.0)
           version: 4.5 Mesa 18.1.0-devel

(In reply to Mez from comment #7)
> I've always had Tearfree option on though and it didn't occur before these last
> few weeks.

Can you help narrow down whether this was introduced by a change in the kernel or in xf86-video-amdgpu, and ideally bisect?

Can I do anything to expedite the search here?

Appears to affect the RX550 and Vega 56 as well, with kernel 4.18.8. Most obvious symptoms are seen when running fullscreen games, with a high recorded framerate, but FPS feels like it's running at half the rate or less (and stutters quite a bit). Turning TearFree off works around the issue.

I've run some tests using: https://testufo.com/photo#photo=quebec.jpg&pps=960&pursuit=0&height=0

I've found that with TearFree enabled, there is a stutter every 4-5 seconds. This occurs at different refresh rates (60hz and 92hz tested). If I turn TearFree off, no stutter or tearing occurs (the test uses v-sync).

I suspect the bug is related to #106175, since if I turn compton on, the stuttering becomes severe. So perhaps there is some underlying issue that affects both TearFree and compositing managers, but not regular v-sync.

The bug looks to be due to the new display code. Setting amdgpu.dc=0 removes all stuttering in the testufo test, with TearFree enabled. Compton still has stuttering, but that could be a configuration issue, or something to do with the test itself.

I should say that part of the bug seems to be worked around with amdgpu.dc=0 in that the stuttering is gone. But the other issue, that of the output looking like it's running at half the framerate in certain games (only with TearFree enabled), is not.

Perhaps I should open another bug for that issue, though.

Okay, so on the secondary issue of the perceived framerate dropping in some cases, it appears to be related to GPU load. If the GPU usage reaches 100% the perceived framerate drops dramatically, whereas if I lower settings or artificially limit the FPS such that 100% usage isn't reached, the degradation doesn't happen.

Is this expected behaviour? If so, it might be useful to have the ability to disable the feature for fullscreen windows, much like compositing managers have the ability to unredirect fullscreen windows.

(In reply to Andrew Sheldon from comment #14)
> Is this expected behaviour?

I'm afraid it might be at this point, due to TearFree always incurring an additional GPU copy.

> If so, it might be useful to have the ability to disable the feature for
> fullscreen windows, much like compositing managers have the ability to
> unredirect fullscreen windows.

Well, it's not quite the same, since even fullscreen windows can tear without page flipping. But yeah, it's possible to eliminate the additional GPU copy while a DRI3 client is page flipping, just haven't got around to implementing it. Anyway, that's a separate issue from the stuttering and should be tracked in a separate report.

BTW, I don't suppose xf86-video-amdgpu 18.1.0 makes any difference for the stuttering?

Okay, so it turns out the frame dropping issue only exists for me in a PRIME configuration. Perhaps the additional GPU copy at full load is too much for the system to handle, and it starts dropping frames instead. I can workaround it by limiting the framerate at least, although not all games and GPU APIs allow for this.

For the main topic of this bug, there are now patches for the stuttering here https://bugs.freedesktop.org/show_bug.cgi?id=106175 which is likely the same issue that the OP reported.

(In reply to Andrew Sheldon from comment #16)
> Okay, so it turns out the frame dropping issue only exists for me in a PRIME
> configuration. Perhaps the additional GPU copy at full load is too much for
> the system to handle, and it starts dropping frames instead.

Hmm, frame drops should only happen if the GPU connected to the display is overloaded though. What kind of PRIME configuration is this exactly?

(In reply to Michel Dänzer from comment #17)
> (In reply to Andrew Sheldon from comment #16)
> > Okay, so it turns out the frame dropping issue only exists for me in a PRIME
> > configuration. Perhaps the additional GPU copy at full load is too much for
> > the system to handle, and it starts dropping frames instead.
> 
> Hmm, frame drops should only happen if the GPU connected to the display is
> overloaded though. What kind of PRIME configuration is this exactly?

Update: My mistake. There's a specific place I was testing, and I managed to reach my refresh rate so it wasn't actually fully loading the card, giving the impression that PRIME was the cause (rather than the overhead of PRIME resulting in 100% GPU usage).

Nevertheless, the setup is like this:

RX550 connected directly to display

Vega 56 doing the rendering

I've switched back to the V56 as the primary for now, but I can test again if needed.

I will say there didn't seem to be significant GPU usage on the RX550 when connected to the display, even when the frame drop issue was occurring. Which is interesting considering you were saying that should only occur when the GPU connected display is overloaded.

I can confirm the screen stuttering with RX460 and RX550. It doesn't happen with R7 250E or Firepro W5100 which are GCN2 cards using radeon. Seems to be a Polaris/AMDGPU specific problem? This issue did not happen on Linux 4.14 if I recall correctly.

Tested using Manjaro 18.0.2, Linux 4.20.1, Gnome 3.30, KDE Plasma 5.14.

I'm using dual display, Dell U2417H via HDMI, Cintiq Pro 13 via Displayport.
Stuttering happens even when U2417H is disabled using DE's control panel.

amdgpu.dc=0 does not work for me. 

Anything I can do to help with the diagnose, please let me know.

Same issue on VEGA8 and RX560X PRIME configuration.

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/drm/amd/issues/322.