Bug 105300 - amd-staging-drm-next-git 4.16 & RX 560 DL-DVI: corruption with refreshrates >73Hz when DPM changing VRAM clock
Summary: amd-staging-drm-next-git 4.16 & RX 560 DL-DVI: corruption with refreshrates >...
Status: RESOLVED DUPLICATE of bug 102646
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/AMDgpu (show other bugs)
Version: unspecified
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Default DRI bug account
QA Contact:
Depends on:
Reported: 2018-02-28 20:28 UTC by tempel.julian
Modified: 2018-10-31 19:08 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:

edids for 2560x1440 73Hz, 74Hz and 75Hz (573 bytes, application/x-7z-compressed)
2018-02-28 20:28 UTC, tempel.julian
no flags Details
dmesg.log (54.67 KB, text/x-log)
2018-03-02 13:36 UTC, tempel.julian
no flags Details
Xorg.0.log (25.93 KB, text/x-log)
2018-03-02 13:37 UTC, tempel.julian
no flags Details
xrandr.log (336 bytes, text/x-log)
2018-03-02 13:38 UTC, tempel.julian
no flags Details
2560x1440 72Hz edid (226 bytes, application/x-7z-compressed)
2018-04-23 13:03 UTC, tempel.julian
no flags Details

Description tempel.julian 2018-02-28 20:28:36 UTC
Created attachment 137704 [details]
edids for 2560x1440 73Hz, 74Hz and 75Hz

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.

Comment 1 Harry Wentland 2018-03-01 15:06:44 UTC
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.
Comment 2 tempel.julian 2018-03-01 17:21:23 UTC
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).
Comment 3 Harry Wentland 2018-03-01 19:43:26 UTC
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.
Comment 4 Harry Wentland 2018-03-01 20:26:06 UTC
Please attach your dmesg, Xorg.0.log and xrandr output.

Are you modifying your monitor's EDIDs to support higher refresh rates?
Comment 5 tempel.julian 2018-03-02 13:36:25 UTC
Created attachment 137752 [details]
Comment 6 tempel.julian 2018-03-02 13:37:00 UTC
Created attachment 137753 [details]
Comment 7 tempel.julian 2018-03-02 13:38:03 UTC
Created attachment 137754 [details]
Comment 8 tempel.julian 2018-03-02 13:40:50 UTC
Video which shows the artifacts:
(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).
Comment 9 Harry Wentland 2018-03-02 15:03:30 UTC
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.
Comment 10 tempel.julian 2018-03-02 15:41:52 UTC
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:

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.
Comment 11 tempel.julian 2018-03-29 14:05:04 UTC
One of the recent changes in drm-next-4.17-wip has also introduced this issue for the old legacy DC.
Comment 12 tempel.julian 2018-04-23 13:03:42 UTC
Created attachment 139000 [details]
2560x1440 72Hz edid
Comment 13 tempel.julian 2018-04-23 13:04:06 UTC
Since a month back or so, also 73Hz now shows the artifacts. 72Hz is still artifact free.
Comment 14 tempel.julian 2018-06-05 16:31:04 UTC
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.
Comment 15 tempel.julian 2018-10-31 18:58:30 UTC
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.
Comment 16 Alex Deucher 2018-10-31 19:08:25 UTC

*** 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.