Comme=
nt # 97
on bug 10264=
6
from Ahzo@tutanota.co=
m
Created attachment 1449=
50 [details] [review]
Patch to fix the problem
TLDR: A script to reproduce and a patch to fix this problem are attached.
The problem occurs when switching between high and low GPU memory frequenci=
es
at specific time intervals. It can be reproduced with the attached script,
which optionally accepts a time parameter, defaulting to 1 ms.
With a 75 Hz display mode, screen corruption occurs rather reliably by usin=
g a
time parameter in the following ranges:
0.000-0.002, 0.011-0.015, 0.024-0.028, 0.038-0.042, 0.051-0.055, 0.064-0.06=
8,
0.078-0.082, 0.091-0.095, 0.104-0.108
However, using sleep times between these intervals, e.g. 0.1, does not prod=
uce
any screen corruption.
For a frequency of 75 Hz the frame time is T =3D 1000 / 75 ms =3D 13.3 ms a=
nd the
screen corruption happens for sleep times of:
S =3D n * T +- 2 ms
Here n is a natural number, i.e. 0, 1, 2, 3, and so on.
Linux 4.14 is not affected by this problem, as is noted in comment 93. However,
that version only works by accident: When the display mode is not yet known,
default parameters, in particular 60 Hz, are used to calculate frame_time_x=
2 as
(1000000 / 60) * 2 / 100 =3D 333, which is then used to set VBITimeout. Lat=
er,
when the refresh rate of 75 Hz is known, frame_time_x2 gets updated to 266,=
but
VBITimeout is never actually set to that value via smu7_notify_smc_display.
Linux 4.15 included the DC patches, and when using DC (e.g. by using the bo=
ot
argument amdgpu.dc=3D1), VBITimeout is never set to the default 333, but di=
rectly
to 266, which triggers the screen corruption and flickering problems descri=
bed
in this bug.
With Linux 4.17 the problem got more widespread, because the default was
accidentally switched to enable DC by erroneously removing the 'return
amdgpu_dc > 0;' line with:
commit 367e66870e9cc20b867b11c4484ae83336efcb67
Author: Alex Deucher <a=
lexander.deucher@amd.com>
Date: Thu Jan 25 16:53:25 2018 -0500
drm/amdgpu: remove DC special casing for KB/ML
It seems to be working now.
Bug: https://bugs.freedesktop.org/show_bug.=
cgi?id=3D102372
Reviewed-by: Mike Lothian <mike@fireburn.co.uk>
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index 309977ef5b51..2ad9de42b65b 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -1704,6 +1704,8 @@ bool amdgpu_device_asic_has_dc_suppor=
t(enum amd_asic_type
asic_type)
case CHIP_BONAIRE:
case CHIP_HAWAII:
case CHIP_KAVERI:
+ case CHIP_KABINI:
+ case CHIP_MULLINS:
case CHIP_CARRIZO:
case CHIP_STONEY:
case CHIP_POLARIS11:
@@ -1714,9 +1716,6 @@ bool amdgpu_device_asic_has_dc_suppor=
t(enum amd_asic_type
asic_type)
#if defined(CONFIG_DRM_AMD_DC_PRE_VEGA)
return amdgpu_dc !=3D 0;
#endif
- case CHIP_KABINI:
- case CHIP_MULLINS:
- return amdgpu_dc > 0;
case CHIP_VEGA10:
#if defined(CONFIG_DRM_AMD_DC_DCN1_0)
case CHIP_RAVEN:
Linux 4.18 aligns the Non-DC case more closely with the DC case and thus
VBITimeout gets actually set to the updated frame_time_x2 via
smu7_notify_smc_display. Thus the Non-DC case is also affected by this bug
since:
commit 555fd70c59bc7f7acd8bc429d92bd59a66a7b83b
Author: Rex Zhu <Rex.Zhu@amd.=
com>
Date: Tue Mar 27 13:32:02 2018 +0800
drm/amd/pp: Not call cgs interface to get display info
DC/Non DC all will update display configuration
when the display state changed
No need to get display info through cgs interface
Reviewed-by: Evan Quan <eva=
n.quan@amd.com>
Signed-off-by: Rex Zhu <Rex.Z=
hu@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Linux 4.20 contains a commit trying to fix flickering issues:
commit ec2e082a79b5d46addf2e7b83a13fb015fca6149
Author: Alex Deucher <a=
lexander.deucher@amd.com>
Date: Thu Aug 9 14:24:08 2018 -0500
drm/amdgpu/powerplay: check vrefresh when when changing displays
Compare the current vrefresh in addition to the number of displays
when determining whether or not the smu needs updates when changing
modes. The SMU needs to be updated if the vbi timeout changes due
to a different refresh rate. Fixes flickering around mode changes
in some cases on polaris parts.
Reviewed-by: Rex Zhu <Rex.Zhu=
@amd.com>
Reviewed-by: Huang Rui <ray=
.huang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
But that doesn't fix the screen corruption described in this bug, because t=
he
problem is not that VBITimeout isn't updated enough, but rather the opposit=
e,
i.e. that it gets set to the frame_time_x2 value calculated from the correc=
t,
high refresh rate instead of the default value of 333.
At least for 75 Hz, this problem can be fixed by preventing frame_time_x2 a=
nd
thus VBITimeout from being smaller than 280, as in the attached patch. Sett=
ing
VBITimeout to higher values than the calcualted frame_time_x2 does not seem=
to
cause any problems.
It would be great if someone could test this patch with higher refresh rate=
s,
as well.