https://bugzilla.kernel.org/show_bug.cgi?id=202445

--- Comment #2 from Clément Guérin (libcg@protonmail.com) --- Created attachment 280853 --> https://bugzilla.kernel.org/attachment.cgi?id=280853&action=edit dmesg output

https://bugzilla.kernel.org/show_bug.cgi?id=202445

--- Comment #4 from Nicholas Kazlauskas (nicholas.kazlauskas@amd.com) --- 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

https://bugzilla.kernel.org/show_bug.cgi?id=202445

--- Comment #6 from Nicholas Kazlauskas (nicholas.kazlauskas@amd.com) --- Should be:

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

"drm/amd/display: Add below the range support for FreeSync"

https://bugzilla.kernel.org/show_bug.cgi?id=202445

--- Comment #8 from Clément Guérin (libcg@protonmail.com) --- Strange. It looks like this commit has been merged in the mainline kernel before rc1. https://github.com/torvalds/linux/commit/180db303ff466a3887c841e805568b92233...

This should be a legitimate bug then.

https://bugzilla.kernel.org/show_bug.cgi?id=202445

--- Comment #10 from Clément Guérin (libcg@protonmail.com) --- 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.

https://bugzilla.kernel.org/show_bug.cgi?id=202445

--- Comment #12 from Clément Guérin (libcg@protonmail.com) --- 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.

https://bugzilla.kernel.org/show_bug.cgi?id=202445

--- Comment #14 from Nicholas Kazlauskas (nicholas.kazlauskas@amd.com) --- 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.

https://bugzilla.kernel.org/show_bug.cgi?id=202445

--- Comment #16 from Clément Guérin (libcg@protonmail.com) --- 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/mo...

Could that be related?

https://bugzilla.kernel.org/show_bug.cgi?id=202445

--- Comment #18 from Clément Guérin (libcg@protonmail.com) --- Hi Nicholas, any progress on this?

https://bugzilla.kernel.org/show_bug.cgi?id=202445

--- Comment #20 from Nicholas Kazlauskas (nicholas.kazlauskas@amd.com) --- 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!

https://bugzilla.kernel.org/show_bug.cgi?id=202445

--- Comment #22 from Clément Guérin (libcg@protonmail.com) --- Great news. Can you confirm that https://bugzilla.kernel.org/show_bug.cgi?id=202445#c16 is not related to this issue?

https://bugzilla.kernel.org/show_bug.cgi?id=202445

--- Comment #24 from Nicholas Kazlauskas (nicholas.kazlauskas@amd.com) --- 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/

https://bugzilla.kernel.org/show_bug.cgi?id=202445

--- Comment #26 from Nicholas Kazlauskas (nicholas.kazlauskas@amd.com) --- Was "drm/amd/display: Use vrr friendly pageflip throttling in DC." also in the tree you built?

https://bugzilla.kernel.org/show_bug.cgi?id=202445

--- Comment #28 from Clément Guérin (libcg@protonmail.com) --- 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/m...

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

https://bugzilla.kernel.org/show_bug.cgi?id=202445

--- Comment #30 from Clément Guérin (libcg@protonmail.com) --- 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.

https://bugzilla.kernel.org/show_bug.cgi?id=202445

jaapbuurman@gmail.com changed:

What |Removed |Added ---------------------------------------------------------------------------- CC| |jaapbuurman@gmail.com

--- Comment #32 from jaapbuurman@gmail.com --- 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?

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?

https://bugzilla.kernel.org/show_bug.cgi?id=202445

--- Comment #36 from Clément Guérin (libcg@protonmail.com) --- 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.

https://bugzilla.kernel.org/show_bug.cgi?id=202445

--- Comment #38 from jaapbuurman@gmail.com --- 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?