| What | Removed | Added |
|---|---|---|
| CC | harry.wentland@amd.com | |
| Assignee | xorg-driver-ati@lists.x.org | dri-devel@lists.freedesktop.org |
| Product | xorg | DRI |
| QA Contact | xorg-team@lists.x.org | |
| Version | git | unspecified |
| Component | Driver/AMDgpu | DRM/AMDgpu |
(In reply to txtsd from comment #0) > The stuttering is caused by enabling TearFree vi= a xrandr. > When on `auto`, there is no stuttering, but when enabled by setting it= to > `on`, there is intense stuttering noticeable when dragging windows aro= und, > 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 ther= e 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-0= 7. Is that just when you enabled TearFree for the first time, or did this actu= ally not happen with older kernels?
(In reply to Michel D=C3=A4nzer 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 setti= ng it to > > `on`, there is intense stuttering noticeable when dragging window= s around, > > but it's also very noticeable when just moving the mouse around o= n the > > desktop with no windows open. >=20 > 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 see= ms > like a kernel (DC?) issue. >=20 > 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 wh= en 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=20
CPU: AMD A10-7860K Radeon R7, 12 Compute Cores 4C+8G @ 4x 3.9GHz [32.0=
=C2=B0C]
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 ker= nel or in xf86-video-amdgpu, and ideally bisect?
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 record= ed 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=3Dquebec.jpg&= ;pps=3D960&pursuit=3D0&height=3D0 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 amdgp= u.dc=3D0 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 wi= th amdgpu.dc=3D0 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 dro= pping 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 degradat= ion 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 witho= ut 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 implementi= ng it. Anyway, that's a separate issue from the stuttering and should be track= ed 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 i= t 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 he= re https://bugs.freedesktop.org/show_bug.= cgi?id=3D106175 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 o= nly exists for me in a PRIME > configuration. Perhaps the additional GPU copy at full load is too muc= h 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=C3=A4nzer 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 to= o much for > > the system to handle, and it starts dropping frames instead. >=20 > Hmm, frame drops should only happen if the GPU connected to the displa= y 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. Whi= ch 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 d= oesn't happen with R7 250E or Firepro W5100 which are GCN2 cards using radeon. Seems to b= e 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=3D0 does not work for me.=20 Anything I can do to help with the diagnose, please let me know.
| What | Removed | Added |
|---|---|---|
| Status | NEW | RESOLVED |
| Resolution | --- | MOVED |
-- 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.
![https://testufo.com/photo#photo=3Dquebec.jpg&= ;pps=3D960&pursuit=3D0&height=3D0](3D"https://testufo.com/photo#photo=3Dquebec.jpg&pps=3D960&p=){kind=link}