[Bug 108917] gamma adjustments cause stuttering with amdgpu.dc=1, especially problematic with RedShift etc.
https://bugs.freedesktop.org/show_bug.cgi?id=108917
Bug ID: 108917 Summary: gamma adjustments cause stuttering with amdgpu.dc=1, especially problematic with RedShift etc. Product: DRI Version: DRI git 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 142685 --> https://bugs.freedesktop.org/attachment.cgi?id=142685&action=edit xorg log
With amdgpu.dc=1, there is stuttering in the moment when gamma adjustments are getting applied. This is not the case with amdgpu.dc=0, it is entirely free of stutter.
Both RedShift and Gnome night light in Xorg session show the very same behavior: When "nightmode" is getting turned on with a transition effect, there is severe stuttering going on. The same is the case in the opposite direction when turning nightmode off again.
It's also very problematic that the stutter is ongoing, as tools like RedShift in dynamic mode constantly adjust color temperature as the night progresses. There is stutter happening every few seconds because of that.
To reproduce, simply start e.g. RedShift in dynamic mode with "redshift -t 4500:4500 -l 1:1". The stutter can be easily observed when looking at the animation of www.vsynctester.com in Chromium, which should be absolutely free of stutter without gamma adjustment (perhaps set CPU clock governor to performance). But you should already notice that even moving windows etc. is stuttery, especially during transition effect.
As a workaround, one might want to use "oneshot" mode of RedShift, e.g. "redshift -O 4500". This applies a gamma adjustment just once and thus prevents further stuttering. But that's not how the usage of such tools usually is intended.
linux-drm-next-4.21-wip-6b456d7e60007022d91c701c00c76cdfa8774eaf xorg-server 1.20.3 gnome 3.30.1 both modesetting and xf86-video-amdgpu-git 18.1.0.20 DDX driver
https://bugs.freedesktop.org/show_bug.cgi?id=108917
--- Comment #1 from tempel.julian@gmail.com --- Created attachment 142686 --> https://bugs.freedesktop.org/attachment.cgi?id=142686&action=edit dmesg log
https://bugs.freedesktop.org/show_bug.cgi?id=108917
--- Comment #2 from Alex Deucher alexdeucher@gmail.com --- Possibly the same issue as bug 106175.
https://bugs.freedesktop.org/show_bug.cgi?id=108917
--- Comment #3 from tempel.julian@gmail.com --- (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.
https://bugs.freedesktop.org/show_bug.cgi?id=108917
Michel Dänzer michel@daenzer.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #142685|text/x-log |text/plain mime type| |
https://bugs.freedesktop.org/show_bug.cgi?id=108917
Michel Dänzer michel@daenzer.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #142686|text/x-log |text/plain mime type| |
https://bugs.freedesktop.org/show_bug.cgi?id=108917
--- Comment #4 from Alex Deucher alexdeucher@gmail.com --- 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.
https://bugs.freedesktop.org/show_bug.cgi?id=108917
--- Comment #5 from tempel.julian@gmail.com --- 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).
https://bugs.freedesktop.org/show_bug.cgi?id=108917
--- Comment #6 from Nicholas Kazlauskas nicholas.kazlauskas@amd.com --- 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.
https://bugs.freedesktop.org/show_bug.cgi?id=108917
--- Comment #7 from Hans D awotozamist@tutanota.com --- 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.
https://bugs.freedesktop.org/show_bug.cgi?id=108917
--- Comment #8 from tempel.julian@gmail.com --- 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. :(
https://bugs.freedesktop.org/show_bug.cgi?id=108917
--- Comment #9 from Nicholas Kazlauskas nicholas.kazlauskas@amd.com --- (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.
https://bugs.freedesktop.org/show_bug.cgi?id=108917
--- Comment #10 from tempel.julian@gmail.com --- 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/74136a3d47f51ae72ee8b9ebc1ec2a29bcf...
https://bugs.freedesktop.org/show_bug.cgi?id=108917
--- Comment #11 from tempel.julian@gmail.com --- 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.
https://bugs.freedesktop.org/show_bug.cgi?id=108917
--- Comment #12 from tempel.julian@gmail.com --- 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.
https://bugs.freedesktop.org/show_bug.cgi?id=108917
--- Comment #13 from Michel Dänzer michel@daenzer.net --- Sounds like the stutter with compton could be at least partly a compton (configuration?) issue then.
https://bugs.freedesktop.org/show_bug.cgi?id=108917
--- Comment #14 from tempel.julian@gmail.com --- 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.
https://bugs.freedesktop.org/show_bug.cgi?id=108917
--- Comment #15 from tempel.julian@gmail.com --- 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?
https://bugs.freedesktop.org/show_bug.cgi?id=108917
Martin Peres martin.peres@free.fr changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |MOVED
--- Comment #16 from Martin Peres martin.peres@free.fr --- -- 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.
dri-devel@lists.freedesktop.org
-
bugzilla-daemon＠freedesktop.org