(In reply to Alex Deucher from comment #67) > Do you get flickering at 144Hz without forcing t= he mclk to high? I.e., > without these patches: > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/l= inux.git/commit/ > ?id=3D0a646f331db0eb9efc8d3a95a44872036d441d58 > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/l= inux.git/commit/ > ?id=3D58d7e3e427db1bd68f33025519a9468140280a75 > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/l= inux.git/commit/ > ?id=3D09be4a5219610a6fae3215d4f51f948d6f5d2609 > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/l= inux.git/commit/ > ?id=3D2275a3a2fe9914ba6d76c8ea490da3c08342bd19 Yes, I've experienced that before and just tested it again. > > Do you know how this works on Windows? Do t= hey increase voltage without > > raising clocks and could this be an option for amdgpu too? >=20 > It's not the mclk frequency or voltage, it's the blanking period for t= he > display timing, it's apparently too short on some monitors at very high > refresh rates for the mclk to finish switching in time. If part of th= e mclk > switch happens outside of the vblank period, you end up with flickerin= g or > other display artifacts. I assumed it is related to any voltage because higher sclk helps too. I'll = just call sclk/mclk dpm states "sdpm" and "mdpm" auto (sdpm 0, mdpm 0 or switching through states): very bad flickering and artifacts sdpm 1-7, mdpm 0: better (still flickering/artifacts, but only when bigger areas on the screen are updated) sdpm any, mdpm 1: no flickering and artifacts