Created attachment 142685 [details]
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.
both modesetting and xf86-video-amdgpu-git 220.127.116.11 DDX driver
Created attachment 142686 [details]
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
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:
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):
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:
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.