Comme=
nt # 42
on bug 11065=
9
from tempel.j=
ulian@gmail.com
(In reply to Nicholas Kazlauskas from comment #39)
> Disabling the compositor doesn't make a differen=
ce 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 run=
ning
> 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. T=
his
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 atom=
ic
modesetting via amdgpu.dc=3D0. I wonder if the log confirms that it's the s=
ame
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 h=
as 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 le=
vel 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 un=
til
> 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 gam=
ma
adjustment either in Xorg or the kernel? Then we'd have ultimate proof. :)
> A check could potentially be made to not lock al=
l 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 applicat=
ion is
> requesting different color adjustments every single time.
It seems some suboptimal behavior of Wine can trigger this issue, but I sup=
pose
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=3D108917
I btw. can reproduce that issue by simply booting Fedora 30 Workstation Gno=
me
Live and enable the nightlight feature, the color grading phase makes
everything stutter.