https://bugs.kde.org/show_bug.cgi?id=514855
--- Comment #9 from Mantas Vaitkus <[email protected]> --- Hi, I'm not an expert so I use AI a lot to get the correct info for you. I'm sorry if something doesn't make sense at all, please let me know. I dug deeper into this and I believe I have identified the cause. It appears to be a hardware/driver issue related to aggressive VRAM Clock Switching, which is triggered when Direct Scanout is active (because the load drops effectively?). I monitored the VRAM frequency via hwmon while the flickering occurred. The logs show the memory clock oscillating rapidly and unstably (about 10 times per second) between low and medium states. It seems the GPU cannot decide on a power state for this specific workload. If I force the GPU power level to high, the flickering stops immediately and completely, even with Direct Scanout active. Command used: echo high | sudo tee /sys/class/drm/card1/device/power_dpm_force_performance_level Setting it back to auto brings the flickering back immediately. Why previous workarounds may have helped: KWIN_DRM_NO_AMS=1, Night Light, or obstructing the window likely disable Direct Scanout. This forces the GPU to do compositing, which seemingly adds enough consistent load to keep the memory clock stable (or prevents the specific power-saving state entry). Here is a snippet of the VRAM clock behavior during the flickering: 1:48:48.153 | VRAM Takt: 783 MHz 21:48:48.257 | VRAM Takt: 774 MHz 21:48:48.361 | VRAM Takt: 768 MHz 21:48:48.465 | VRAM Takt: 763 MHz 21:48:48.568 | VRAM Takt: 758 MHz 21:48:48.671 | VRAM Takt: 770 MHz 21:48:48.775 | VRAM Takt: 812 MHz 21:48:48.879 | VRAM Takt: 843 MHz 21:48:48.983 | VRAM Takt: 853 MHz 21:48:49.087 | VRAM Takt: 840 MHz 21:48:49.191 | VRAM Takt: 849 MHz 21:48:49.294 | VRAM Takt: 886 MHz 21:48:49.397 | VRAM Takt: 914 MHz 21:48:49.500 | VRAM Takt: 924 MHz 21:48:49.604 | VRAM Takt: 910 MHz 21:48:49.708 | VRAM Takt: 930 MHz 21:48:49.812 | VRAM Takt: 929 MHz 21:48:49.916 | VRAM Takt: 916 MHz 21:48:50.020 | VRAM Takt: 896 MHz 21:48:50.125 | VRAM Takt: 878 MHz 21:48:50.229 | VRAM Takt: 913 MHz 21:48:50.332 | VRAM Takt: 965 MHz 21:48:50.438 | VRAM Takt: 1010 MHz 21:48:50.541 | VRAM Takt: 1025 MHz 21:48:50.644 | VRAM Takt: 1017 MHz 21:48:50.748 | VRAM Takt: 1015 MHz 21:48:50.852 | VRAM Takt: 1005 MHz 21:48:50.957 | VRAM Takt: 986 MHz 21:48:51.062 | VRAM Takt: 982 MHz 21:48:51.168 | VRAM Takt: 955 MHz 21:48:51.272 | VRAM Takt: 953 MHz 21:48:51.377 | VRAM Takt: 924 MHz 21:48:51.483 | VRAM Takt: 904 MHz 21:48:51.588 | VRAM Takt: 883 MHz 21:48:51.693 | VRAM Takt: 860 MHz 21:48:51.798 | VRAM Takt: 854 MHz 21:48:51.902 | VRAM Takt: 841 MHz 21:48:52.008 | VRAM Takt: 824 MHz 21:48:52.114 | VRAM Takt: 810 MHz 21:48:52.219 | VRAM Takt: 797 MHz 21:48:52.324 | VRAM Takt: 785 MHz Since this seems to be a kernel/firmware behavior, do you think this should be forwarded to the amdgpu kernel tracker, or is there anything KWin can do to mitigate this "jittery" load? -- You are receiving this mail because: You are watching all bug changes.
