SUMMARY When using KDE in X11 and Wayland with VRR enabled, RADV and an RX 6700 XT I have been experiencing display flicker on my 144Hz monitor via DisplayPort and HDMI. I am currently using GNOME 42.5 with the Mutter VRR patch, as this setup allows for FreeSync with no flicker. As far as I've found, Plasma has vsync forced on Wayland, which I believe may be making the issue visible due to added latency. I am unsure if RADV adds latency with its vsync implementation, if Kwin has higher latency than GNOME's Mutter, if Kwin's Wayland implementation is not handing the desire for tearing by default for some users relying on Freesync or if there's an issue with direct scanout. My issue may be similar to Bug 450914 and Bug 450884. However, I am making this bug report as from what I gather a tear-free experience is forced in Wayland by default, which may be the issue. Also my refresh rate is not limited to 60. The issue still persists in Halo when limiting to 120Hz in the game's settings and when using DXVK Async while the issue does not occur in GNOME using VRR. STEPS TO REPRODUCE 1. Enable VRR in display settings (also in config for X11). 2. Launch a game (tried with Halo: The Master Chief Collection (Proton) and Terraria (Native) OBSERVED RESULT Flicker present from the start of playing a game, especially evident when loading into a level in Halo and playing in general. EXPECTED RESULT A more stable presentation of frames on my display, which is achievable with GNOME when using the Mutter VRR patch yet not possible for me using Plasma/Kwin. SOFTWARE/OS VERSIONS OS: EndeavourOS Linux x86_64 Kernel: 5.19.13-zen1-1-zen DE (non-issue for me): GNOME 42.5 (VRR patch using Wayland) DE (issue visible): KDE 5.25.5 (X11 and Wayland) Mesa: 22.1.7 (RADV) Wayland: 1.21 with Kwayland Integration GPU: RX 6700 XT ADDITIONAL INFORMATION I have commented on a bug report for Mesa that may be relevant. I feel the need to do this as I am unsure where the issue is exactly coming from and if a variety of issues may be making the issue I am having more visible. https://gitlab.freedesktop.org/mesa/mesa/-/issues/6984
Thank you for the bug report! Please note that Plasma 5.25.5 is not supported for much longer by KDE; supported versions are 5.24, and 5.26 or newer. If at all possible please upgrade to a supported version and verify that the bug is still happening there.
(In reply to Bug Janitor Service from comment #1) > Thank you for the bug report! > > Please note that Plasma 5.25.5 is not supported for much longer by KDE; > supported versions are 5.24, and 5.26 or newer. > > If at all possible please upgrade to a supported version and verify that the > bug is still happening there. I will try out 5.26 soon. I had tried 5.25.5 last week alongside my GNOME install of EndeavourOS before the new release to see if the issue had resolved since earlier versions. I may add Plasma alongside my current install again. If a fresh install is recommended I may make a fresh install or resize my main partition, as I don't want to nuke my main install. I could also try a different distro to test further.
Installed Plasma 5.26 on EndeavourOS like I had before with 5.25.5 along with having all packages up-to-date and here's some results I gathered for X11 and Wayland along with GNOME 42.5 in Wayland using RADV. My display has FreeSync enabled and defaults are used in each DE (1080p 144Hz used) along with VRR options enabled. - - - Plasma - X11 VRR enabled in X11 AMD config. Default display/compositor settings used. Halo MCC - Proton Flicker even with vsync and 120 FPS cap. Terraria - Native Flicker mostly gone. Half-Life 2 - Native Flicker without vsync. DOOM (2016) - Proton, Vulkan Flicker without vsync. Using the mouse in the pause menu causes an FPS drop as low as 2. Final Fantasy X HD - Proton Severe menu flicker when moving the mouse and some flicker in-game with vsync on and off. The game is limited to 60. - - - Plasma - Wayland VRR set to automatic. Default display/compositor settings used. Halo MCC - Proton Flicker even with vsync and 120 FPS cap and only slightly better. Terraria - Native No flicker at all. Half-Life 2 - Native Flicker mostly gone and only really seen during level loading. DOOM (2016) - Proton, Vulkan No flicker Using the mouse in the pause menu causes an FPS drop but not always. Final Fantasy X HD - Proton Severe menu flicker when moving the mouse and some flicker in-game with vsync on and off. The game is limited to 60. - - - GNOME - Wayland Mutter VRR patch and VRR enabled in control center. Halo MCC - Proton No menu flicker, very stable. Only the slightest flicker with anything above a 120 FPS cap when loaded in or with a rare FPS drop. Terraria - Native No flicker at all. Half-Life 2 - Native No flicker at all. DOOM (2016) - Proton, Vulkan No flicker. Using the mouse in the pause menu causes an FPS drop but not always. Final Fantasy X HD - Proton No flicker at all. - - - GNOME seems to be the best experience, which is a shame since I prefer using Plasma. Halo MCC seems the most sensitive when using Plasma. Flicker is also present in Halo MCC's menus on Plasma overall. The DOOM pause menu issue seems more likely to be a Proton or RADV issue. FPS was very steady using Wayland except for the flickering in Plasma, only fluctuating heavily using X11 in Half-Life 2 without vsync. No flicker when using the desktop itself in either DE. I would assume there's some latency causing the issue or something else that I'm not facing in GNOME.
How did you verify that the Gnome Wayland vrr implementation works? If your monitor has no brightness flicker with it but both Plasma Xorg (note that it's Xorg and nothing KDE related that handles the refresh rate there) and Plasma Wayland do, that suggests to me that vrr is not working for you in Gnome Wayland. A few additional remarks: > Plasma has vsync forced on Wayland As does every Wayland compositor. Note that this has effectively nothing to do with the "VSync" option games provide. > if Kwin has higher latency than GNOME's Mutter It doesn't, with the latest Gnome version latency should be comparable to Xorg for both compositors. Either way, latency has no effect on vrr flicker. > if Kwin's Wayland implementation is not handing the desire for tearing by default for some users relying on Freesync Tearing and FreeSync is an "either or" choice. There's no situation where it would make sense to do both at the same time.
(In reply to Ash from comment #2) > (In reply to Bug Janitor Service from comment #1) > > Thank you for the bug report! > > > > Please note that Plasma 5.25.5 is not supported for much longer by KDE; > > supported versions are 5.24, and 5.26 or newer. > > > > If at all possible please upgrade to a supported version and verify that the > > bug is still happening there. > > I will try out 5.26 soon. I had tried 5.25.5 last week alongside my GNOME > install of EndeavourOS before the new release to see if the issue had > resolved since earlier versions. I may add Plasma alongside my current > install again. If a fresh install is recommended I may make a fresh install > or resize my main partition, as I don't want to nuke my main install. I > could also try a different distro to test further. I think I found a correlation. Games that limit their framerates (for example, Sonic Frontiers or NFS Hot Pursuit Remastered being engine locked to 60fps) somehow make the display's refresh rate vary. Severity depends on the game, varies between a hitch every second to constant variation in display refresh rate. Locking the display's refresh rate to 60 for these games fixes the issue, but it's tedious. I am using Arch Linux, Mesa RADV driver version 22.3.2-3 on an RX 5700, KDE Plasma 5.26.5. This happens both on Wayland and X11. VRR is set to automatically apply on Wayland. Not only does this cause display brightness flicker, but also extremely uneven frame pacing.
(In reply to dfodre from comment #5) > (In reply to Ash from comment #2) > > (In reply to Bug Janitor Service from comment #1) > > > Thank you for the bug report! > > > > > > Please note that Plasma 5.25.5 is not supported for much longer by KDE; > > > supported versions are 5.24, and 5.26 or newer. > > > > > > If at all possible please upgrade to a supported version and verify that the > > > bug is still happening there. > > > > I will try out 5.26 soon. I had tried 5.25.5 last week alongside my GNOME > > install of EndeavourOS before the new release to see if the issue had > > resolved since earlier versions. I may add Plasma alongside my current > > install again. If a fresh install is recommended I may make a fresh install > > or resize my main partition, as I don't want to nuke my main install. I > > could also try a different distro to test further. > > I think I found a correlation. Games that limit their framerates (for > example, Sonic Frontiers or NFS Hot Pursuit Remastered being engine locked > to 60fps) somehow make the display's refresh rate vary. Severity depends on > the game, varies between a hitch every second to constant variation in > display refresh rate. Locking the display's refresh rate to 60 for these > games fixes the issue, but it's tedious. > > I am using Arch Linux, Mesa RADV driver version 22.3.2-3 on an RX 5700, KDE > Plasma 5.26.5. This happens both on Wayland and X11. VRR is set to > automatically apply on Wayland. > > Not only does this cause display brightness flicker, but also extremely > uneven frame pacing. Have you tried forcing the shader and memory clocks to be constant? E.g. by doing as root: `echo profile_standard > /sys/class/drm/card0/device/power_dpm_force_performance_level`. You could also try `profile_peak` for max clocks. It seems that the dynamic reclocking (to save power) causes uneven frame delivery, which causes (brightness) flickering and stuttering with VRR.
(In reply to wokim from comment #6) > (In reply to dfodre from comment #5) > > (In reply to Ash from comment #2) > > > (In reply to Bug Janitor Service from comment #1) > > > > Thank you for the bug report! > > > > > > > > Please note that Plasma 5.25.5 is not supported for much longer by KDE; > > > > supported versions are 5.24, and 5.26 or newer. > > > > > > > > If at all possible please upgrade to a supported version and verify that the > > > > bug is still happening there. > > > > > > I will try out 5.26 soon. I had tried 5.25.5 last week alongside my GNOME > > > install of EndeavourOS before the new release to see if the issue had > > > resolved since earlier versions. I may add Plasma alongside my current > > > install again. If a fresh install is recommended I may make a fresh install > > > or resize my main partition, as I don't want to nuke my main install. I > > > could also try a different distro to test further. > > > > I think I found a correlation. Games that limit their framerates (for > > example, Sonic Frontiers or NFS Hot Pursuit Remastered being engine locked > > to 60fps) somehow make the display's refresh rate vary. Severity depends on > > the game, varies between a hitch every second to constant variation in > > display refresh rate. Locking the display's refresh rate to 60 for these > > games fixes the issue, but it's tedious. > > > > I am using Arch Linux, Mesa RADV driver version 22.3.2-3 on an RX 5700, KDE > > Plasma 5.26.5. This happens both on Wayland and X11. VRR is set to > > automatically apply on Wayland. > > > > Not only does this cause display brightness flicker, but also extremely > > uneven frame pacing. > > Have you tried forcing the shader and memory clocks to be constant? E.g. by > doing as root: `echo profile_standard > > /sys/class/drm/card0/device/power_dpm_force_performance_level`. You could > also try `profile_peak` for max clocks. It seems that the dynamic reclocking > (to save power) causes uneven frame delivery, which causes (brightness) > flickering and stuttering with VRR. Both profile_standard and profile_peak fix the issue for me. I have a 6950XT, so that means idle power consumption of 90W and 220W respectively, according to `sensors` and `radeon-profile`. That's a lot of power, even with profile_standard. Ideally, power management should be solved somehow so that I don't waste power on the desktop.
I have replaced my RX 5700 with a 6950XT and Arch with Nobara 38 KDE since I made the comments, but the same issue is present, unless I force higher clocks.
(In reply to dfodre from comment #7) > Both profile_standard and profile_peak fix the issue for me. I have a > 6950XT, so that means idle power consumption of 90W and 220W respectively, > according to `sensors` and `radeon-profile`. That's a lot of power, even > with profile_standard. Ideally, power management should be solved somehow so > that I don't waste power on the desktop. You could also use a shell script that automatically sets profile_standard or profile_peak when starting a game and sets it back to auto when exiting the game. But yeah, it would be better if the amdgpu driver provided consistent frame timings and reasonable power savings out of the box...
(In reply to wokim from comment #9) > (In reply to dfodre from comment #7) > > Both profile_standard and profile_peak fix the issue for me. I have a > > 6950XT, so that means idle power consumption of 90W and 220W respectively, > > according to `sensors` and `radeon-profile`. That's a lot of power, even > > with profile_standard. Ideally, power management should be solved somehow so > > that I don't waste power on the desktop. > > You could also use a shell script that automatically sets profile_standard > or profile_peak when starting a game and sets it back to auto when exiting > the game. But yeah, it would be better if the amdgpu driver provided > consistent frame timings and reasonable power savings out of the box... I seem to have found a better solution, using `radeon-profile` and disabling the lowest available Core clock in the overclock section (in my case that would be 500MHz, the only other option 2720Mhz for me) mostly fixes the freesync issue, and doesn't seem to affect idle power consumption. It varies between 9W and 25W. However, power consumption ingame is raised quite a bit in games that don't push the hardware all that much. For example, Sonic Frontiers uses 90W before, and 125W after, even though the framerate is 60 in both cases (according to Steam Overlay). This also fixes NFS Hot Pursuit, but only in the races, not on the map screen, but profile_standard and profile_peak can't fix that either. Oh, well. I'm sticking to radeon-profile, until AMD fixes this.
Okay, then this is just https://gitlab.freedesktop.org/drm/amd/-/issues/1500 and not related to KWin.
(In reply to dfodre from comment #10) > I seem to have found a better solution, using `radeon-profile` and disabling > the lowest available Core clock in the overclock section (in my case that > would be 500MHz, the only other option 2720Mhz for me) mostly fixes the > freesync issue, and doesn't seem to affect idle power consumption. It varies > between 9W and 25W. > > However, power consumption ingame is raised quite a bit in games that don't > push the hardware all that much. > For example, Sonic Frontiers uses 90W before, and 125W after, even though > the framerate is 60 in both cases (according to Steam Overlay). The best solution I've currently found is to set "power_dpm_force_performance_level" to "manual" and "pp_power_profile_mode" to "1", and to raise the minimum core clock. E.g. on my GPU I raised the minimum core clock from 700 MHz to 1700 MHz by echoing "s 0 1700" to "pp_od_clk_voltage" and then echoing "c" to it so it applies. Interestingly, raising the minimum clock from 700 MHz to 1700 MHz only increased power consumption by about one Watt from 36 to 37 W in a game with a medium GPU load (e.g. locked at 60 fps). And idle desktop power consumption is pretty much unchanged. Increasing the minimum core clock further to 1800-2000 MHz increases power consumption in-game by just a few Watts. It's only when I increase the minimum core clock even further, e.g. 2300-2700 MHz, that power consumption increases significantly in-game.