Comment # 42
on bug 110659
from tempel.julian@gmail.com
(In reply to Nicholas Kazlauskas from comment #39) > Disabling the compositor doesn't make a difference as far as stuttering goes > for Hitman 2's DXVK - I don't see any commits in the log that are lock the > connector and all the planes. Thanks for trying! > I don't have Oblivion on my machine to test, but I tried running the DX9 > version of Heaven under proton and I don't see stuttering or any gamma/color > adjustment commits under that either. No issues with FreeSync when running > it either from what I can tell with vsync both on/off. I've given Heaven a try, it doesn't show the issue for me either (DX9 via D9VK). > Those commits are definitely what's causing your stuttering, but I'm not > sure what's actually creating them. My initial guess was something in the > compatibility layer for DX9 games, but I don't see that on my setup. I've attached a debug dmesg log after triggering the issue in Hitman 2. It is also what is shown in the new video capture I've provided. As you can see, there are no rendering spikes, but instead the mouse input (and perhaps partially also keyboard) seems to be discarded a lot, causing such jumps. This is also there without vsync enabled, but less obvious. Just like the render spikes in Oblivion/Skyrim, this issue completely disappears by turning off pageflipping in xorg config, switching to modesetting DDX or disabling atomic modesetting via amdgpu.dc=0. I wonder if the log confirms that it's the same issue (or the issue has the same roots)? > Is it only Oblivion that has this issue for you? I found out that also the native OpenGL renderer of Doom 2016 (which also has a free demo on Steam) shows the same behavior as Oblivion/Skyrim, despite of no 3D API wrapper involved. For whatever reason, the Vulkan renderer of the game doesn't show the issue, it seems to run flawlessly with both pageflipping + vsync. > I'm not sure how much of this can be a kernel level fix - I think we need to > lock all the planes whenever gamma or color adjustments have been made and > that probably includes the cursor plane as well. If the cursor plane is > included that will block asynchronous cursor updates from occurring until > the color adjustments have been done. This is why the cursor causes > stuttering. Would it be possible to provide a test patch that completely blocks any gamma adjustment either in Xorg or the kernel? Then we'd have ultimate proof. :) > A check could potentially be made to not lock all the planes for redundant > color management commits, but I'm not sure if the color adjustments > requested are redundant or not. It could be the case that the application is > requesting different color adjustments every single time. It seems some suboptimal behavior of Wine can trigger this issue, but I suppose it would automatically be fixed together with this issue which I reported regarding gamma adjustment performance and atomic modesetting: https://bugs.freedesktop.org/show_bug.cgi?id=108917 I btw. can reproduce that issue by simply booting Fedora 30 Workstation Gnome Live and enable the nightlight feature, the color grading phase makes everything stutter.
You are receiving this mail because:
- You are the assignee for the bug.
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
