| Bug ID | 106175 |
|---|---|
| Summary | amdgpu.dc=3D1 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-devel@lists.freedesktop.org |
| Reporter | tempel.julian@gmail.com |
Created attachment 138987 [details]<=
/span>
dmesg
When amdgpu.dc=3D1 and an Xorg compositor are enabled at the same time, the=
re is
stuttering when moving windows.
It's most visible with Compton (which is completely stutter-free when
amdgpu.dc=3D0), 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=3D1 and an Xorg compositor are enabled and the hardware mouse cur=
sor
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
Created attachment 138988 [detai=
ls]
xorg log
| What | Removed | Added |
|---|---|---|
| Attachment #138988 mime type | text/x-log | text/plain |
| What | Removed | Added |
|---|---|---|
| CC | harry.wentland@amd.com |
Does this also happen without overriding the EDID of the DVI-D= output?
Yes, then it also occurs with the monitor's resolution/refresh= rate 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.
I found out that it's still related to the hardware cursor. When I set Option "SWCursor" "true" in Xorg config, mov= ing 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 t= urns more yellow/orange than the rest of the screen. Using software cursor works around this problem as well.
amdgpu.dc=3D1 also causes performance issue with 2 games I own: "Rise = of the Tomb Raider" and "Helium Rain" (UE4 game with sources public= ly available on=20 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=3D0 everything is fine. 2. With amdgpu.dc=3D1: The issue was showing up only in menus when cursor was visible and was in t= he 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=20 responding and Xorg server was producing messages like below in Xorg.0.log: (II) event5 - USB Gaming Mouse: SYN_DROPPED event - some input events h= ave been lost. (EE) client bug: timer event5 debounce short: offset negative (-7ms)=20= =20=20=20=20 When I moved mouse to the 1st monitor the messages were not produced and mo= use 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= =3D0 which fixed the issue. With amdgpu.dc=3D1 latencytop was showing that drm_modeset_backoff was taki= ng ~20ms. I was using kernel 4.17.0-rc1 and 4.17.0-rc2, Mesa 18.2.0-devel=20 (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.
I forgot about - I have Radeon Fury X graphics card.
Does your kernel tree have the following patches? 90fef6476917 Revert "drm/amd/display: disable CRTCs with NULL FB on th= eir primary plane (V2)" c7bd22893408 Revert "drm/amd/display: fix dereferencing possible ERR_P= TR()" If not can you grab the latest drm-next-4.18-wip and check again? Those rev= erts should have fixed problems where mouse movement would slow the system down.=
I had these patches in the kernel tree - mine is from 22nd Apr= il, while these patches were committed on 12th April. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds= /linux.git/log/?ofs=3D350
I got them too. Before those commits, my issue was way more se= vere. It's still really nasty stutter though.
I have the same issue. For me amdgpu.dc=3D0 does not really fi= x it either. I have a 3840x1600 monitor running at 75 Hz. This is the different behavior I noti= ced when toggling the DC setting: amdgpu.dc=3D0 Moving windows smooth most of the time but cursor frequently skips frames amdgpu.dc=3D1 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.
I noticed that this issue also exists apart from Xorg composit= ors. When I run Serious Sam: Fusion (both OpenGL and Vulkan) in fullscreen (no X= org 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 vsyn= c in the game, its movement becomes stuttery. Again no problem with amdgpu.dc=3D= 0.
Latest drm-next-4.18-wip aa1bce17d841a362d40da940487e13affe4c7= b3b 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.
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?
(In reply to tempel.julian from comment #13) > So there might be an actual connection to pagefl= ipping? 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"
I just tried that option with the xf86 amdgpu DDX driver and a= s 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 us= ers really worried me that I'd have to live forever with it.
I have this issue too, disabling page flipping fixes it for me= on my vega10. It started with 4.16rc1 IIRC
ht= tps://patchwork.freedesktop.org/patch/227925/ might provide inspiration= for how this could be solved.
My hypothesis is that has something to do with the mouse polli= ng rate.=20=20 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
(In reply to David Francis from comment #18) > My hypothesis is that has something to do with t= he 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 iss= ue 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.
Note that the ioctls don't literally run "in parallel&quo= t;; both ioctls are called by the Xorg main thread, so they can't preempt each other. What I mean is t= hat any number of cursor ioctls can happen while a page flip is pending.
Don't want to nag at anyone, but this bug still makes DC unusa= ble for me and thus is a real dealbreaker. Does implementing a fix for it require lots of efforts?