Created attachment 137704 [details] edids for 2560x1440 73Hz, 74Hz and 75Hz Hello, I tried out amd-staging-drm-next-git with Linux 4.16 and my DL-DVI 2560x1440 display: Now I finally get a picture and refreshrates below 74Hz seem to work without apparent issues, thanks for fixing the black screen issue! However, when using edid information which contains a resolution with refreshrates higher than 73Hz, I get flickering artifacts on the desktop. The issue disappears when I force full clocks via sysfs or use display timings which prevent the VRAM from downclocking. So it seems very likely to me that it's related to downclocking of the VRAM when using higher refreshrates. This is a regression, the old display stack (amdgpu.dc=0) works with refreshrates higher than 73Hz and VRAM downclocking at the same time without issues. I attached edid files which can be loaded via drm_kms_helper.edid_firmware and drm.edid_firmware (they show equal behavior in this case), they use LCD standard timings. Thanks!
I wonder if what you're seeing is related to this: https://bugs.freedesktop.org/show_bug.cgi?id=102646#c22 It's a different ASIC but also does not reproduce when clocks are forced high.
I think there are some differences: The user there described that he would have the issue also with the legacy DC, which is not the case for me. He also had issues with just 60Hz, which is definitely not the case for me as well. To describe my visual corruption a bit closer: It's flashing of various colors and forms, mostly stripe artifacts. It's quite extreme and makes the system practically unusable. My display btw. doesn't have an internal scaler/OSD, DL-DVI input gets straight to the display panel (if that makes any difference).
Good point. Do you mind posting a picture of what you're seeing? It often helps clarify what sort of corruption is happening and helps us understand which part of the pipeline is messing up.
Please attach your dmesg, Xorg.0.log and xrandr output. Are you modifying your monitor's EDIDs to support higher refresh rates?
Created attachment 137752 [details] dmesg.log
Created attachment 137753 [details] Xorg.0.log
Created attachment 137754 [details] xrandr.log
Video which shows the artifacts: https://youtu.be/it3d6BjpZjU (can also be quite worse when doing stuff) It happens with every desktop environment with and without enabled OGL compositor. In the video, it's KDE Plasma on Xorg. But there is no difference with a Wayland session, the artifacts there are the same. You are correct that the display's own edid information doesn't know any other refreshrate than 59.95Hz. However, these Korean import display's are very often used with higher refreshrates because their panels allow this without incompatible scaler in between. With the old display stack, I can even set 85Hz without any issues. 75Hz is also not very uncommon for some 2560x1440p IPS displays, I suppose there is the realistic possibility that also displays which have a 2560x1440 75Hz resolution in their original edid are affected by this bug (since the old stack isn't affected, I'm quite sure it's some kind of bug).
Are you messing with TMDS_MAX_PIXEL_CLOCK as Andrew is doing in this ticket: https://bugs.freedesktop.org/show_bug.cgi?id=105302 ? With DC clock switching might happen more aggressively which could explain the underflow you're seeing.
I thought of something similar too. But I'm far away from 330Mhz pixel clock. I'm just using LCD standard timings, which result in a pixel clock of 304.37MHz: https://abload.de/img/75hzhgs1d.png I also had the suspicion that the magic 300Mhz mark might be a problem, so I created a resolution with custom timings for 74Hz which resulted in ~295MHz, but the issue was still the same. It seems like it's really just about the refresh rate and not the timings or pixelclock.
One of the recent changes in drm-next-4.17-wip has also introduced this issue for the old legacy DC.
Created attachment 139000 [details] 2560x1440 72Hz edid
Since a month back or so, also 73Hz now shows the artifacts. 72Hz is still artifact free.
73Hz + dynamic clocking work again with recent drm-next-4.19-wip build. As a sidenote: On Windows (which is installed on the same system as a 2nd OS), there has never been an issue with 75Hz during the last six months.
Issue still exists with current 4.21-wip kernel. As a workaround, it's enough to force the highest VRAM clock state (Forcing higher clocks on the GPU itself is not necessary.): echo "manual" > /sys/class/drm/card0/device/power_dpm_force_performance_level echo "2" > /sys/class/drm/card0/device/pp_dpm_mclk Odd side note: It doesn't help to overclock the lower VRAM pstates to the same clocks and voltages as the highest one.
*** This bug has been marked as a duplicate of bug 102646 ***
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.