Bug 202445 - amdgpu/dc: framerate dropping below adaptive sync range causes screen flickering
Summary: amdgpu/dc: framerate dropping below adaptive sync range causes screen flickering
Status: RESOLVED CODE_FIX
Alias: None
Product: Drivers
Classification: Unclassified
Component: Video(DRI - non Intel) (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: drivers_video-dri
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-01-29 04:53 UTC by Clément Guérin
Modified: 2020-04-07 15:10 UTC (History)
3 users (show)

See Also:
Kernel Version: 5.0rc4
Tree: Mainline
Regression: No


Attachments
dmesg output (81.77 KB, text/plain)
2019-01-29 15:46 UTC, Clément Guérin
Details
Xorg.1.log (67.20 KB, text/plain)
2019-01-29 15:47 UTC, Clément Guérin
Details
dmesg drm.debug=4 (120.89 KB, text/plain)
2019-02-04 16:41 UTC, Clément Guérin
Details
attachment-3684-0.html (1.33 KB, text/html)
2019-09-16 15:02 UTC, Clément Guérin
Details

Description Clément Guérin 2019-01-29 04:53:31 UTC
linux 5.0rc4
mesa 4aa64940c
xf86-video-amdgpu a1b479c

hardware:
- R9 Fury
- Samsung C27HG70 (1020.0 firmware, Freesync Ultimate Engine)

I'm running the Unigine Valley benchmark extremely smoothly as long as the framerate stays in between 48-144fps. When it drops below that, I'm observing heavy stuttering and flickering in the darker parts of the image. The flickering also affects the loading screen when frames are rendered very infrequently.
Comment 1 Alex Deucher 2019-01-29 14:48:06 UTC
Please attach your dmesg output and xorg log (if using X).
Comment 2 Clément Guérin 2019-01-29 15:46:57 UTC
Created attachment 280853 [details]
dmesg output
Comment 3 Clément Guérin 2019-01-29 15:47:19 UTC
Created attachment 280855 [details]
Xorg.1.log
Comment 4 Nicholas Kazlauskas 2019-01-30 14:02:49 UTC
Below the range support didn't make it into 5.0. That patches for this are in amd-staging-drm-next:

https://cgit.freedesktop.org/~agd5f/linux/log/?h=amd-staging-drm-next

They should show up in the next release I think.

Nicholas Kazlauskas
Comment 5 Clément Guérin 2019-01-30 16:50:34 UTC
Can you point me to the commits introducing this feature? Thanks.
Comment 6 Nicholas Kazlauskas 2019-01-30 16:53:03 UTC
Should be:

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

"drm/amd/display: Add below the range support for FreeSync"
Comment 7 Clément Guérin 2019-01-30 17:04:37 UTC
Thanks. I'll try it out asap. I strongly feel that this feature should be backported to 5.0 since the freesync implementation seems broken without it. I understand if that's not possible.
Comment 8 Clément Guérin 2019-01-31 05:36:24 UTC
Strange. It looks like this commit has been merged in the mainline kernel before rc1. https://github.com/torvalds/linux/commit/180db303ff466a3887c841e805568b92233e2d0e#diff-730f0f79c9b013ef9a2c68f236d473b0

This should be a legitimate bug then.
Comment 9 Clément Guérin 2019-01-31 06:17:55 UTC
I just tested built `drm-next-5.1-wip` (8054c54a6), it's flickering/stuttering as well.
Comment 10 Clément Guérin 2019-02-02 22:39:28 UTC
I did some more testing today, using my monitor OSD to determine if freesync is active. None of the Steam Play games I own work with freesync, the refresh rate stays at 144Hz. It looks like freesync simply doesn't work with wine. That includes:
- Alan Wake (DX9 -> OpenGL)
- DOOM (OpenGL)
- Fallout: New Vegas (DX9 -> OpenGL)
- Trackmania Stadium² (DX11 -> OpenGL)

Native games do seem to work, and I'm observing flickering with all of them. Including:
- Getting Over It
- Kerbal Space Program
- Night in the Woods
- Rocket League
- Unigine Valley
- VVVVVV

In the case of KSP, I'm seeing flickering even though the framerate floats around 80-90fps. Disabling VSYNC makes the flickering mostly disappear, but it's still visible when microstuttering occurs. The monitor OSD displays a wildly varying refresh rate with VSYNC ON, but seems rather stable with VSYNC OFF.
Comment 11 Clément Guérin 2019-02-03 23:28:29 UTC
Same issue with 5.0rc5.
Comment 12 Clément Guérin 2019-02-03 23:51:26 UTC
Here's a video of the issue shot in 1080p60: https://www.youtube.com/watch?v=yQmlqggF2I8 (sorry I had to make it vertical)

The game fps counter is on the upper right, and the monitor's is on the bottom right. The flickering is visible in the video.
Comment 13 Clément Guérin 2019-02-04 04:59:33 UTC
YouTube refuses to show the vertical video as 1080p so I made another one here, this time horizontal: https://www.youtube.com/watch?v=CTKr4NWXXKI

Also for reference, here's Unigine Valley running on Windows with no flickering and smooth LFC: https://www.youtube.com/watch?v=4mYbZ7leVPw Framerate on the monitor OSD is much more consistent.
Comment 14 Nicholas Kazlauskas 2019-02-04 15:44:42 UTC
FreeSync not working on WINE is a Mesa issue I believe.

I don't think the backend WINE goes through is DRI3 which is required to use the present extension / support page-flipping through X to DRM.

The flickering I'm not quite sure about. I don't think I've observed it happening lately in amd-staging-drm-next on Raven or Vega when running any of the Unigine benchmarks at varying settings (dipping below and into the VRR range).

Do you mind booting with drm.debug=4 and posting a dmesg log when you're running the Unigine Valley benchmark? It would also help to know what desktop environment/compositor you're using.
Comment 15 Clément Guérin 2019-02-04 16:41:54 UTC
Created attachment 280949 [details]
dmesg drm.debug=4

Here's the dmesg output as requested. I'm running gnome-shell 3.30.2.
Comment 16 Clément Guérin 2019-02-07 08:00:07 UTC
Nicholas, I found a TODO in the freesync btr code for pre-DCE12 GPUs (pre-Vega?). https://github.com/torvalds/linux/blob/master/drivers/gpu/drm/amd/display/modules/freesync/freesync.c#L897

Could that be related?
Comment 17 Nicholas Kazlauskas 2019-02-07 14:24:07 UTC
I can reproduce the issue but vsync needs to be on. I'd recommend turning vsync off for now to avoid flickering.

The issue lies in how amdgpu_dm handles waiting for vblank and how userspace interacts with the vblank counter in variable refresh rate mode.

The routine that does the wait / flip programming tries to aim for the next vblank interval based on the current counter which rolls around at the vback porch. If the routine gets delayed past scanout and into the front porch what can happen is we're stuck waiting for the current vblank interval to timeout, which will force the monitor to the lowest refresh rate and introduces stuttering / flickering in this case.

There should be a fix for this soon.
Comment 18 Clément Guérin 2019-02-25 19:13:56 UTC
Hi Nicholas, any progress on this?
Comment 19 Clément Guérin 2019-02-28 04:57:30 UTC
I just built drm-fixes-5.0 including https://cgit.freedesktop.org/~agd5f/linux/commit/?h=drm-fixes-5.0&id=d63716658ac16c515d1223a9fbf5edbf76b1b333 and this issue remains.
Comment 20 Nicholas Kazlauskas 2019-03-01 16:43:39 UTC
That patch certainly helps for the case where the pageflip was submitted during vblank (the frontporch will no longer timeout, causing flickering).

The video you recorded helped identify what I think is the specific issue in this case though - I believe that the implementation is frequently changing the BTR target instead or prioritizing the last used target rate.

There should be a fix for this coming soon, it should also apply to 5.0 once it's done.

Thanks for the report!
Comment 21 Nicholas Kazlauskas 2019-03-01 16:45:12 UTC
I'll let you know when it's up so you can try it. It should resolve the issue, but if it doesn't it will at least help narrow down the cause.
Comment 22 Clément Guérin 2019-03-01 16:54:28 UTC
Great news. Can you confirm that https://bugzilla.kernel.org/show_bug.cgi?id=202445#c16 is not related to this issue?
Comment 23 Clément Guérin 2019-03-11 15:45:20 UTC
Hi Nicholas, any progress on this? Can you answer my question above? Thanks.
Comment 24 Nicholas Kazlauskas 2019-03-15 15:57:15 UTC
I don't believe that it's related to the issue, but the patch below should help with the issue:

https://patchwork.freedesktop.org/patch/292460/
Comment 25 Clément Guérin 2019-03-16 08:30:54 UTC
I tried this patch on top of linux 5.0.2 and it didn't help.
Comment 26 Nicholas Kazlauskas 2019-03-18 13:07:40 UTC
Was "drm/amd/display: Use vrr friendly pageflip throttling in DC." also in the tree you built?
Comment 27 Clément Guérin 2019-03-18 15:25:25 UTC
I'm sorry, I assumed this particular commit had been backported to Linux 5.0, and it's apparently not the case. I will try with both when I find some time tonight.
Comment 28 Clément Guérin 2019-03-18 17:44:34 UTC
Nevermind. This commit was merged right before 5.0 was released. So yes, it was in the tree.

What I suspect is happening is that a couple or more frames are scheduled by the BTR code, but for some reason they are displayed at the max refresh rate (144Hz in my case), then the monitor times out on the last frame and that produces flickering. Which is what I pointed out in comment 16.

EDIT: I just realized that the link in that comment is outdated because code moved around. This is what it originally pointed to: https://github.com/torvalds/linux/blob/672e78c/drivers/gpu/drm/amd/display/modules/freesync/freesync.c#L980

/* TODO: pass in flag for Pre-DCE12 ASIC
 * in order for frame variable duration to take affect,
 * it needs to be done one VSYNC early, which is at
 * frameCounter == 1.
 * For DCE12 and newer updates to V_TOTAL_MIN/MAX
 * will take affect on current frame
 */

As far as I know that will only affect pre-Vega GPUs, and I'm running Fiji.
Comment 29 Clément Guérin 2019-03-28 03:45:00 UTC
Any progress on this?
Comment 30 Clément Guérin 2019-04-28 00:57:58 UTC
I just tested drm-next-5.2 with Mario Kleiner's VRR BTR patch series applied on top: https://lists.freedesktop.org/archives/amd-gfx/2019-April/033470.html

The situation improved a lot. Unigine Valley is now smooth at low framerates with some occasional flickering when the BTR limit is crossed. Rocket League still flickers when the game stutters.

At this point I'm not sure if the bug is fully fixed or if it's just a hardware limitation. Anyhow, it's good progress.
Comment 31 Nicholas Kazlauskas 2019-04-29 13:31:58 UTC
With the third patch in that series the bug should be fixed (ncorrect IRQ handling for older ASICs). I imagine it'll be merged soon.

You'll still likely see minor luminance flickering when you're going from a relatively framerate (short front porch duration) to low framerate (long front porch duration).

It depends on the panel characteristics for the display and supported VRR range, however. Not all displays will exhibit the same luminance delta between min and max front porch duration.
Comment 32 jaapbuurman 2019-06-03 10:56:35 UTC
I am experiencing the exact same issue, although I am still running the 5.1 kernel. I feel uncomfortable compiling my own kernel, so I cannot test 5.2 just yet. I do have an additional observation that might be useful for debugging. My freesync monitor has a 48-144 freesync range, and displays the current refresh rate on its OSD.

The issue for me is the easiest to reproduce in Kerbal Space program while in space, since the flickering is especially visible with the many white stars on the blackness of space.

While in space with a large vessel that pushes your FPS down (33-40 FPS in the ingame FPS monitor), my monitor is rapidly oscillating through the entire freesync range (as low as 48 and as high as 144, and everything in between). As far as I understand the technology, whenever the FPS is stable (for example at 37), it should use LFC to display each frame twice or thrice, and the monitor should refresh at a constant 74hz or 111hz. But that is not what is happening if I use a static view with a constant 37 FPS.

Is there something I can do to rule out a monitor issue? Perhaps by setting some kind of debug option to see what the driver is instructing the monitor to do?
Comment 33 Clément Guérin 2019-09-16 02:33:32 UTC
It looks like the luminance flickering situation is much improved when using linux 5.3 with this "LFC behaviour" patch applied: https://lists.freedesktop.org/archives/amd-gfx/2019-September/039856.html

The easiest way to reproduce the problem is to play Kerbal Space Program, open the Vehicle Assembly Building and then hover the mouse over the parts selector, on the left of this screenshot: https://www.kproplab.org/wp-content/uploads/2018/09/eex-1.png
Comment 34 jaapbuurman 2019-09-16 13:22:40 UTC
How big is the improvement? Is the issue completely gone, or is it still there? The KSP example also reliably triggers the flickering for me, and I am using the exact same monitor.

These LFC patches are going to be included in the 5.5 kernel, right? Or will they be included in an earlier kernel version?
Comment 35 Clément Guérin 2019-09-16 14:58:55 UTC
If you haven't updated to linux 5.2 yet, you should because it fixed constant flickering when in LFC mode.

This additional patch helps when freesync goes in and out of LFC mode. It's not fully fixed, but the flickering is a lot less severe. According to the Phoronix article it should indeed land in linux 5.5.

When compiling a kernel you should be able to install it next to the regular one so you can't break your setup. I personally used the linux-mainline package from the AUR and added the LFC patch on top.
Comment 36 Clément Guérin 2019-09-16 15:02:33 UTC
Created attachment 285011 [details]
attachment-3684-0.html

If you haven't updated to linux 5.2 yet, you should because it fixed constant flickering when in LFC mode.

This additional patch helps when the monitor goes in and out of LFC mode. It's not fully fixed, but the flickering is a lot less severe. According to the Phoronix article it should indeed land in linux 5.5.

When compiling a kernel you should be able to install it next to the regular one so you can't break your setup. I personally used the linux-mainline package from AUR and added the LFC patch on top.
-------- Original Message --------
On Sep 16, 2019, 06:22, wrote:

> https://bugzilla.kernel.org/show_bug.cgi?id=202445
>
> --- Comment #34 from jaapbuurman@gmail.com ---
> How big is the improvement? Is the issue completely gone, or is it still
> there?
> The KSP example also reliably triggers the flickering for me, and I am using
> the exact same monitor.
>
> These LFC patches are going to be included in the 5.5 kernel, right? Or will
> they be included in an earlier kernel version?
>
> --
> You are receiving this mail because:
> You reported the bug.
Comment 37 Clément Guérin 2020-02-15 23:20:40 UTC
An improved version of this patch landed in linux 5.6. I've been running GTA IV with 5.6-rc1, this game is a total stutterfest but the luminance flickering was minimal. It's good enough that I consider this issue fixed.
Comment 38 jaapbuurman 2020-04-07 15:07:53 UTC
While I previously also had to same luminance flickering as you were describing on older kernels, kernel 5.5 and unfortunately also 5.6 are showing me flickering between a completely black screeb and the game itself in very rapid succession. Not playable at all. I already considered it unplayable on older kernels due to the rapidly changing brightness, but the current situation is MUCH worse.

Anything I can do to help debug this issue?
Comment 39 jaapbuurman 2020-04-07 15:10:38 UTC
To add to my previous comment: My ingame FPS is completely stable, yet my monitor's HZ is jumping all over the place as can be seen from the monitor's OSD. Previously, the luminance issue would only occur when the ingame FPS was unstable.

Note You need to log in before you can comment on or make changes to this bug.