Comment # 68
on bug 93826
from iuno@posteo.net
(In reply to Alex Deucher from comment #67) > Do you get flickering at 144Hz without forcing the mclk to high? I.e., > without these patches: > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/ > ?id=0a646f331db0eb9efc8d3a95a44872036d441d58 > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/ > ?id=58d7e3e427db1bd68f33025519a9468140280a75 > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/ > ?id=09be4a5219610a6fae3215d4f51f948d6f5d2609 > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/ > ?id=2275a3a2fe9914ba6d76c8ea490da3c08342bd19 Yes, I've experienced that before and just tested it again. > > Do you know how this works on Windows? Do they increase voltage without > > raising clocks and could this be an option for amdgpu too? > > It's not the mclk frequency or voltage, it's the blanking period for the > 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 the mclk > switch happens outside of the vblank period, you end up with flickering 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
You are receiving this mail because:
- You are the assignee for the bug.
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel