| Bug ID | 105300 |
|---|---|
| Summary | amd-staging-drm-next-git 4.16 & RX 560 DL-DVI: corruption= with refreshrates >73Hz when DPM changing VRAM clock |
| Product | DRI |
| Version | unspecified |
| Hardware | x86-64 (AMD64) |
| OS | Linux (All) |
| Status | NEW |
| Severity | normal |
| Priority | medium |
| Component | DRM/AMDgpu |
| Assignee | dri-devel@lists.freedesktop.org |
| Reporter | tempel.julian@gmail.com |
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. T=
he
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=3D0) 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=3D102646#c22 It's a different ASIC but also does not reproduce when clocks are forced hi= gh.
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 col= ors 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 stra= ight to the display panel (if that makes any difference).
Good point. Do you mind posting a picture of what you're seein= g? 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 [deta=
ils]
dmesg.log
Created attachment 137753 [det=
ails]
Xorg.0.log
Created attachment 137754 [det=
ails]
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 ot= her 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 i= n this ticket: https://bugs.freedesktop.org/show_bug.= cgi?id=3D105302 ? 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 330M= hz pixel clock. I'm just using LCD standard timings, which result in a pixel clock of 304.37MHz: https://abload.de/img/75hzh= gs1d.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 introd= uced this issue for the old legacy DC.
![https://abload.de/img/75hzh= gs1d.png](3D"https://abload.de/img/75hzhgs1d.png"){kind=link}
Created attachment 139000 [details]
2560x1440 72Hz edid
Since a month back or so, also 73Hz now shows the artifacts. 7= 2Hz is still artifact free.
73Hz + dynamic clocking work again with recent drm-next-4.19-w= ip build. As a sidenote: On Windows (which is installed on the same system as a 2nd O= S), 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_pe= rformance_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 s= ame clocks and voltages as the highest one.
| What | Removed | Added |
|---|---|---|
| Resolution | --- | DUPLICATE |
| Status | NEW | RESOLVED |
*** This bug has been marked as a duplicate of bug 102646 ***