Created attachment 144213 [details]
The jittering is already noticeable in the game's menu. It's most prominent with vsync enabled, but there is also noticeable jittering in the game when vsync is turned off. It seems there is no jittering with just keyboard input instead of mouse.
The issue does not occur when:
-playing the game in windowed mode
-turning off pageflipping in xorg config
-using modesetting driver instead
-using legacy DC via amdgpu.dc=0
I haven't yet encountered this in other games with DXVK.
Created attachment 144214 [details]
Funny, this MR leads to the same behavior with the modesetting driver:
(In reply to tempel.julian from comment #0)
> The issue does not occur when:
> -using legacy DC via amdgpu.dc=0
Probably a DC issue then.
What's the latest commit in your WIP kernel?
I know there was a regression caused by:
that forces full updates on every commit leading to pretty poor performance. I have a patch that fixes this that didn't make into that set of DC patches.
But I also don't think this last set is merged yet into amd-staging-drm-next, so it's likely something other than this - and likely something in the legacy codepath if disabling atomic support in modesetting causes the issue.
Yes, it also happens with Linux 5.1.
It btw. runs fine on xwayland inside a Plasma Wayland session.
Situation is unchanged with 5.3-wip.
It also occurs with amdvlk instead of radv if you turn on pageflipping via UseFlipHint,1 in amdPalSettings.cfg (for incomprehensible reasons it is disabled by default and the amdvlk developers unfortunately seem to ignore user complaints regarding it).
Instead of pageflipping, the issue can also be triggered with amdvlk + TearFree.
Btw: There is a free demo of Hitman 2 on Steam, it might work out of the box with Steam Play/Proton.
I head to re-write this entire comment because freedesktop.org servers are a nightmare. Complete migration to GitLab would be great thing.
Playing Skyrim with Gallium Nine also shows this issue, it makes the games unplayable.
Is it really certain that it's an amdgpu.dc problem when the modesetting DDX doesn't show this issue?
Do you happen to know if this was a regression?
Until I get a new GPU or a FreeSync display, I use amdgpu.dc=1 only for testing purposes. So I can't judge if this is a regression or has always existed.
But I gave Linux 4.19.46 LTS a try and it shows the same behavior.
Hm, maybe no one noticed because pageflipping wasn't working before this commit?
Will retest with latest stable versions of xorg / amdgpu DDX.
It's btw. really not happening in every game, e.g. Elex seems to be fine.
Nope, not related to it. Happens also with stable versions.
Happens also with plain wined3d inside official Steam Proton builds. In case of Skyrim, it is also affects the rendering performance and thus is visible in the frametime graph (unlike Hitman 2 with DXVK):
Those spikes occur by just moving the mouse. Pressing keyboard buttons don't trigger them.
I'm wondering if this is the async cursor update bug again. Maybe something with WINE or the game is trying to swap cursor buffers frequently and it's interacting with the cursor double buffering in xf86-video-amdgpu.
We still can't do fast cursor updates for swapping cursor framebuffers because we'll hit page faults that can kill the driver due to the cursor framebuffer not being properly refcounted.
The fix for this particular bug is still under review in DRM. I plan on removing the restriction I added in amdgpu DM after the fix has been merged.
But for now, whenever the cursor swaps framebuffers we can't perform fast cursor updates so we're forced to wait for the previous flip to finish and the vblank event to be sent back to userspace. This can cause small jitters depending on how often the cursor is updating and when it updates during the vblank interval.
Thanks for letting me know!
Could you please provide me with a loose estimate if those general atomic modesetting performance limitations can be overcome in the next months? Would really put my mind at ease. :)
(In reply to tempel.julian from comment #13)
> Thanks for letting me know!
> Could you please provide me with a loose estimate if those general atomic
> modesetting performance limitations can be overcome in the next months?
> Would really put my mind at ease. :)
The core bits + the bits that affect amdgpu are reviewed. But I think it's still waiting on review from maintainers of the other drivers the patch impacts. I wouldn't expect it to land before 5.3 or even 5.4 at the earliest unfortunately.
I would still need to debug to know for sure if that's the actual bug that's going on here but it seems likely given that it's atomic DC + cursor movement + xf86-video-amdgpu that's causing the issue.
Well, hope on the horizon.
If applying debug patches would be helpful for trying to shed light into this issue, I would of course do it.
Created attachment 144354 [details] [review]
Sure, you can try the patch I've attached on applied after series fixing the problem in DRM:
Not sure if that applies cleanly, however. The important patches from should be:
I applied your patch and patches 1 and 3 of that series on linux 5.2-rc2, but it unfortunately doesn't show any effect:
-There is still the mouse input issue for the games described in this ticket.
-Opening new windows still creates stutter.
-And so do gamma adjustments via RedShift.
Huh, with modesetting driver, those patches eliminate the stutter when new windows are shown. Does the xf86-video-amdgpu driver need adjustments for this?
However, turning on nightlight in Plasma Wayland still causes stutter, which is not there with amdgpu.dc=0.
RedShift btw. is completely broken with amdgpu.dc=1 + modesetting DDX, it simply has no effect anymore (not related to the experimental atomic modesetting patches).
(In reply to tempel.julian from comment #18)
> Huh, with modesetting driver, those patches eliminate the stutter when new
> windows are shown. Does the xf86-video-amdgpu driver need adjustments for
It should eliminate stuttering for that case in xf86-video-amdgpu if it's the problem I think it is (double buffering the cursor).
> However, turning on nightlight in Plasma Wayland still causes stutter, which
> is not there with amdgpu.dc=0.
1. Gamma updates are slow updates that do a lot of register programming. Nightlight and RedShift issue a lot of these updates.
2. Gamma updates, like everything that isn't a cursor update, currently target the next vblank period.
3. If the pageflip is in a separate commit or update than the gamma update, then it'll need to wait for the gamma update to finish and for the next vblank interval. If this takes too long then we might miss the next vblank interval and have to wait for the one after that.
I think it's a combination of these 3 issues. Even though it's Wayland and should be using the full atomic API, I'm not sure if plasma is actually issuing all that state in the same commit or not.
My guess would be no, since you're seeing the stuttering. We do have a bug with (2) for legacy gamma updates, since there isn't really any reason those should be waiting for the next flip / vblank other than to be consistent with the rest of the atomic commit framework.
> RedShift btw. is completely broken with amdgpu.dc=1 + modesetting DDX, it
> simply has no effect anymore (not related to the experimental atomic
> modesetting patches).
Not sure what the issue here would be. Gamma seems to work fine for legacy and atomic on amdgpu (we pass the IGT tests for this) and it works fine in legacy desktops like GNOME on Xorg with the xf86-video-amdgpu DDX.
Was this still on Plasma, but on X?
I forgot that I patched this PR into my Xserver:
It is responsible for the blocked gamma adjustment and the better desktop window performance of the modesetting Xorg driver with the experimental atomic modesetting kernel patches vs. the xf86-video-amdgpu driver.
So, since everything got a bit messy, let me recap the results and add a few more details:
-The experimental atomic modesetting kernel patches actually improve the performance for desktop window usage for one aspect: When I open www.vsynctester.com in Chromium and quickly hover the mouse cursor over my system tray to trigger popup windows, this doesn't result in stuttering anymore. The same applies to little text popups (e.g. URLs of links) during regular web browsing. This is the case with both modesetting and xf86-video-amdgpu, window compositing is enabled and 100% free of tearing at the same time.
-But there is still stutter on www.vsynctester.com in Chromium (please don't use Firefox for this, it even stutters on MS Windows when doing this...) when I hide and show any other window, e.g. of running Dolphin file browser by clicking its starter icon in the taskbar. It's just the window that is shown and hidden, the program itself continues running all the time. This applies to both modesetting and xf86-video-amdgpu driver.
-But when I apply the aforementioned "WIP: modesetting: Use atomic more atomically" patch to Xserver (additionally to the experimental atomic modesetting kernel patches), the modesetting driver is also 100% free of stutter in this situation, while the xf86-video-amdgpu-driver is not.
Question is: Can this also be incorporated into the xf86-video-amdgpu driver? This would be a VAST improvement, the stuttering during gamma adjustments imho is not close to being as important.
-Now back to the stutter in games when moving the mouse: This is completely untouched by all this. The xf86-video-amdgpu driver always show stuttering in the mentioned games (as long as amdgpu.dc=1), while modesetting and also xwayland don't.
Oof, I hope I didn't forget anything. ;)
I'm open to trying out other patches, e.g. concerning double buffering for the cursor. :)
The Witcher 3 is affected as well (a bit less obvious, but still quite bad vs. modesetting or amdgpu.dc=0). So, it seems this is a real dealbreaker for playing games on Linux, which imho justifies to raise this ticket's priority. :(
Any news on this? I'd really like to have this sorted out before I wholeheartedly recommended Navi for Linux gaming.
I can imagine that Navi causes a ton of work, but still this issue is painful.
I've mentioned kwin-lowlatency in this ticket:
It can be used as some kind of workaround for this wine issue, as the stutter doesn't occur when kwin compositing (and thus vsync) is enabled on top of the games' vsync.
Of course this is far from being optimal, as
1. It breaks FreeSync.
2. There is an additional backbuffer queue, causing additional input (or perhaps better output) latency.
3. It may introduce additional stutter when framerate drops below refreshrate
FreeSync situation for wine games seems really terrible with due to this bug. :(
Applying this MR and disabling HW cursor "fixes" the mouse skipping in the menu of Hitman 2 (as there is a cursor visible and thus pageflipping is turned off):
But in the actual game, there is no cursor visible and so there is severe stutter again.
I also reported the bug to the wine devs (still I think this is rather a bug of xf86-video-amdgpu):
There I mentioned that setting "MouseWarpOverride = disable" (a wine features to work around/solve mouse issues) fixes the problem for wined3d/gallium nine.
However, it does not fix the issue in Hitman 2.
The issue in Hitman 2 also is a bit different, as it doesn't seem to have slowdowns regarding the rendering performance, but instead the mouse input rather seems to be partially blocked or discarded. But again: This does not occur without xf86-video-amdgpu or amdgpu.dc=1.
(In reply to tempel.julian from comment #25)
> I also reported the bug to the wine devs (still I think this is rather a bug
> of xf86-video-amdgpu):
It's a kernel issue, not an xf86-video-amdgpu one.
(In reply to Michel Dänzer from comment #26)
> It's a kernel issue, not an xf86-video-amdgpu one.
Thanks for clarifying.
I could also reproduce this issue with Doom OpenGL in Steam Play/Proton 4.9. As soon as I move the mouse enough, there are frametime spikes (the red ones in the "total" graph):
When I turn off pageflipping in xorg config, the red spikes there are gone:
Luckily, the Vulkan renderer of the game doesn't show the issue. But it once again makes clear that this bug can affect a wide variety of software in Wine.
Situation is still unchanged with latest drm-next-5.4-wip kernel branch from a few minutes ago. :(
The patches by Nicholas are now merged in drm-next-5.4 branch (tested with recent commit that bases the branch on 5.3-rc3), but the mouse input issue in certain games is still unaffected.
I was also able to reproduce it with a different system (also with RX 580) which features a 60Hz FreeSync display, it definitely makes FreeSync impossible to use in the aforementioned titles.
(In reply to tempel.julian from comment #29)
> The patches by Nicholas are now merged in drm-next-5.4 branch (tested with
> recent commit that bases the branch on 5.3-rc3), but the mouse input issue
> in certain games is still unaffected.
> I was also able to reproduce it with a different system (also with RX 580)
> which features a 60Hz FreeSync display, it definitely makes FreeSync
> impossible to use in the aforementioned titles.
I still can't reproduce on any setup I've tried.
Here is the current setup I have:
RX580 1920x1080 @ 144Hz
There are no spikes in the DXVK overlay in Hitman 2 when moving the mouse and no noticeable jitter in input.
I am using plasma with the compositor enabled, tearing prevention auto and fullscreen redirection allowed. PageFlip is enabled in xf86-video-amdgpu.
I do see stutters in the graph when moving the cursor over the mission tiles on the menu, but this is GFX stuttering - not display. Moving the cursor at the top of the screen in the menu produces no stuttering.
FreeSync isn't active since this is DXVK.
Created attachment 145117 [details]
new dmesg log with staging-drm-next kernel default parameters
Created attachment 145118 [details]
issue demonstrated with D9VK frametime graph in game Oblivion
I haven't seen anything like the video in my testing. It also doesn't seem to happen every time so I'm wondering if something else is going on in the background that's issuing atomic commits.
Do you mind posting the relevant portion of a dmesg log after running the following:
echo 0x52 > /sys/module/drm/parameters/debug
This will generate a ton of debug information and will likely kill your performance, but if you can reproduce the portion of the frametime graph with the red spikes and post that part of the log that would help.
Thank you for being still with me on this.
I've downgraded to stock packages provided by Arch stable repository, which is:
stock (read: no) xorg config
no custom kernel parameters (except of of disabling intel_pstate, see new dmesg.log attached)
And I've also installed amd-staging-drm-next (6c7a8d5c0772) just like you.
But: The issue is unchanged. To further illustrate the issue, I've recorded a capture of it in the game TESV: Oblivion in D9VK (no difference to WineD3D or Gallium Nine regarding this issue).
The capturing process in OBS Studio via Xcomposite breaks pageflipping, but I can turn it on again via TearFree which I enable via hotkey on the fly. The result 100% matches running the game with modesetting DDX or amdgpu.dc=0 (no spikes) vs. xf86-video-amdgpu + amdgpu.dc=1 (nasty spikes).
Hitman 2 is a bit different, as it doesn't show render spikes for me either (I think I was first mistaken regarding that difference, sorry for the confusion), but the mouse input just blocks/skips heavily and is even more unplayable than Oblivion/Skyrim etc.
I was just writing this while I read your new reply. I'll gladly try what you have suggested.
Created attachment 145119 [details]
The log now starts at [ 2788.164016], I hope nothing important is cut out. Else I'd have to recheck my log size limits.
Are you running a color management tool in the background?
The difference between my setup and yours is that there isn't anything locking the connectors hundreds of times per second and performing full updates.
This is confirmed in your log by lines like the following:
[ 2788.165907] [drm:drm_atomic_add_affected_connectors [drm]] Adding all current connectors for [CRTC:47:crtc-0] to 00000000acb155e9
Huh, that seems suspicious. I'm not aware of any such a tool which would be active for me all the time. I had redshift installed, but it wasn't running in background, so not surprisingly uninstalling it and restarting the system didn't help. There is colord running, but killing its process didn't help either.
So I'm a bit clueless how this comes. If I knew how, I'd try to turn it off.
Could you try manually disabling KWin compositing via Shift + Alt + F12 before starting Hitman 2?
I just tricked myself when trying out Xfce instead of Plasma, but the reason why Xfce wasn't showing the issue was that it didn't turn off compositing in fullscreen (despite of an option telling otherwise). After manually turning off compositing, the issue was the same as on Plasma without compositor.