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.
Please attach your dmesg output and xorg log (if using X).
Created attachment 280853 [details] dmesg output
Created attachment 280855 [details] Xorg.1.log
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
Can you point me to the commits introducing this feature? Thanks.
Should be: https://patchwork.freedesktop.org/series/53559/ "drm/amd/display: Add below the range support for FreeSync"
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.
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.
I just tested built `drm-next-5.1-wip` (8054c54a6), it's flickering/stuttering as well.
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.
Same issue with 5.0rc5.
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.
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.
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.
Created attachment 280949 [details] dmesg drm.debug=4 Here's the dmesg output as requested. I'm running gnome-shell 3.30.2.
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?
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.
Hi Nicholas, any progress on this?
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.
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!
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.
Great news. Can you confirm that https://bugzilla.kernel.org/show_bug.cgi?id=202445#c16 is not related to this issue?
Hi Nicholas, any progress on this? Can you answer my question above? Thanks.
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/
I tried this patch on top of linux 5.0.2 and it didn't help.
Was "drm/amd/display: Use vrr friendly pageflip throttling in DC." also in the tree you built?
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.
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.
Any progress on this?
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.
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.
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?
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
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?
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.
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.
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.
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?
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.