Created attachment 142686 [details]
dmesg log

Possibly the same issue as bug 106175.

(In reply to Alex Deucher from comment #2)
> Possibly the same issue as bug 106175.

Do you suspect the mouse cursor issue? That's not the case here: The gamma adjustment stutter also occurs without vsync or any other fullscreen vsync application running.

I will give a Wayland session a try this evening. Wouldn't be surprised if this issue is completely unrelated to Xorg specific things.

DC is atomic.  gamma updates may go through a full atomic codepath similar to cursor.  They may also need a similar fast path to avoid a full atomic update.

Thanks for the explanation, I misunderstood you.

So I've tested night colors in a KDE Plasma Wayland session: And indeed, it shows the same behavior as RedShift on Xorg (stutter with amdgpu.dc=1, no stutter with amdgpu.dc=0).

I suspect that Alex is right about this being similar to the cursor update issue - a large volume of color management changes through the full atomic commit codepath would likely be quite slow. The dc=1 to dc=0 comparison is good evidence supporting it as well.

Expanding the cursor path into a generalized plane update fast path would likely resolve the issue, but may be tricky to do right.

Can confirm that enabling redshift causes occasional stutters every 2-4 seconds with amdgpu.dc=1 with linux 5.0rc2. Without  redshift everything (scrolling in browser, video playback)is buttery smooth. With amdgpu.dc=0  redshift doesn't introduce any hiccups.

Unfortunately, Linux 5.0.3 with

drm: Block fb changes for async plane updates
commit 25dc194b34dd5919dd07b8873ee338182e15df9d

hasn't changed the situation, as far as I can tell. :(

(In reply to tempel.julian from comment #8)
> Unfortunately, Linux 5.0.3 with
> 
> drm: Block fb changes for async plane updates
> commit 25dc194b34dd5919dd07b8873ee338182e15df9d
> 
> hasn't changed the situation, as far as I can tell. :(

That's the DRM level bugfix for use after free on async updates for plane framebuffer swaps. It actually hurts performance rather than helps it.

There's a fix that allows framebuffer swaps again being developed right now with some patches in dri-devel:

https://patchwork.freedesktop.org/series/57524/

You'd have to revert

"drm/amd/display: Skip fast cursor updates for fb changes"

as well though to actually allow this series to work.

Thanks for the information, really a relief to know that this is being worked on.
Does this aim to achieve as good performance as with "legacy DC" for every window operation as well?

Would it work to do something like "patch -Np1 -i -R fastcursorpath.patch" and then apply the new set of patches?

In that case my question would be how to find the right patch to revert. The PR for the kernel included much more (yeah, sorry for such beginner questions):
https://github.com/torvalds/linux/commit/74136a3d47f51ae72ee8b9ebc1ec2a29bcf30676

Is it realistic that the maintainers and firms in charge might manage an effort to solve this matter across vendors this year?

I unfortunately always notice the performance issue by simply browsing the web, as even little text or hyperlink pop ups trigger fps drops, which are not there without atomic modesetting on Xorg.

I personally would already be quite happy if the experimental patchset was available e.g. in amd-staging-drm-next branch for the time being.

It seems some recent (kernel?) updates have mitigated the issue a lot when running "redshift -t 4500:4500 -l 1:1", the transition phase is now free of stutter. After that, there is still regular stutter though for subsequent gamma adjustments by RedShift when Compton with vsync is active.

What is really interesting: There is kwin-lowlatency as a kwin fork with vsync adjustments:
https://github.com/tildearrow/kwin-lowlatency
With its compositing, the performance issues of atomic modesetting seem to be entirely missing. There is zero stutter when opening windows etc., and also continuous RedShift adjustments don't stutter. At the same time, there is zero tearing.

Sounds like the stutter with compton could be at least partly a compton (configuration?) issue then.

Well, it's always atomic modesetting that breaks downstream.

Some fixes for 5.1 definitely seem to have improved the situation, as current drm-next 440e80ce02cde7b810e4eb555768c2d77e7a27c8 shows the severe RedShift phase stutter again which 5.1.15 does not. Going to retest with 5.3-rc1 or 5.2.

To clarify: There is no connection to any compositor. You can also reproduce the issue with any desktop environment where you can disable the compositor.
Instead of using a compositor then, simply enable TearFree and run "redshift -t 4500:4500 -l 1:1".
-> It still makes everything stutter. And not just with cursor input, it affects the whole screen content without further doing. Just look at your browser window content of www.vsnctester.com, scroll on any webpage or play a video: The stutter should always be noticeable.
The commit "drm/amd/display: Allow cursor async updates for framebuffer swaps" has not changed the situation.

I can't explain why this issue was less distinct with some 5.1 kernel versions.
Anyway: It's back to "really stuttery" since 5.2.

---

Is this perhaps because userspace uses legacy gamma adjustment instead of new atomic infrastructure? In that case, it would seem unrealistic to expect it to adopt to the new infrastructure if not even Gnome Nightlight on Wayland uses it. So a performance fix for legacy gamma adjustments would be highly welcome (if my assumptions apply ;) ).

I also wonder why there has to be stutter at all. Only the initial setting of new gamma adjustments cause the stutter. When you run redshift in "oneshot" mode via "redshift -O 4500", there is no more stutter once the initial adjustment is done and the gamma stays adjusted.
Perhaps it would help to make the kernel delay the adjustments until they can happen without causing performance issues with vsync + pageflipping?

-- 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/623.