<html> <head> <base href="https://bugs.freedesktop.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - Screen flickering under amdgpu-experimental [buggy auto power profile]" href="https://bugs.freedesktop.org/show_bug.cgi?id=102646#c101">Comment # 101</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - Screen flickering under amdgpu-experimental [buggy auto power profile]" href="https://bugs.freedesktop.org/show_bug.cgi?id=102646">bug 102646</a> from <a class="email" href="mailto:m.ivanov2k@gmail.com" title="Maxim Ivanov <m.ivanov2k@gmail.com>"> Maxim Ivanov</a> <pre>(In reply to Ahzo from <a href="show_bug.cgi?id=102646#c97">comment #97</a>) > Created <a href="attachment.cgi?id=144950" name="attach_144950" title="Patch to fix the problem">attachment 144950</a> <a href="attachment.cgi?id=144950&action=edit" title="Patch to fix the problem">[details]</a> <a href='page.cgi?id=splinter.html&bug=102646&attachment=144950'>[review]</a> [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 > frequencies 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 using > 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.068, 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 > produce any screen corruption. > For a frequency of 75 Hz the frame time is T = 1000 / 75 ms = 13.3 ms and > the screen corruption happens for sleep times of: > S = 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 <a href="show_bug.cgi?id=102646#c93">comment 93</a>. > 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_x2 as (1000000 / 60) * 2 / 100 = 333, which is then used to set > VBITimeout. Later, 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 > boot argument amdgpu.dc=1), VBITimeout is never set to the default 333, but > directly to 266, which triggers the screen corruption and flickering > problems described 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 href="mailto:alexander.deucher@amd.com">alexander.deucher@amd.com</a>> > 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: <a class="bz_bug_link bz_status_NEW " title="NEW - [dc] [kabini] Errors during startup - X doesn't start" href="show_bug.cgi?id=102372">https://bugs.freedesktop.org/show_bug.cgi?id=102372</a> > Reviewed-by: Mike Lothian <<a href="mailto:mike@fireburn.co.uk">mike@fireburn.co.uk</a>> > Reviewed-by: Harry Wentland <<a href="mailto:harry.wentland@amd.com">harry.wentland@amd.com</a>> > Signed-off-by: Alex Deucher <<a href="mailto:alexander.deucher@amd.com">alexander.deucher@amd.com</a>> > > 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_support(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_support(enum > amd_asic_type asic_type) > #if defined(CONFIG_DRM_AMD_DC_PRE_VEGA) > return amdgpu_dc != 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 <<a href="mailto:Rex.Zhu@amd.com">Rex.Zhu@amd.com</a>> > 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 <<a href="mailto:evan.quan@amd.com">evan.quan@amd.com</a>> > Signed-off-by: Rex Zhu <<a href="mailto:Rex.Zhu@amd.com">Rex.Zhu@amd.com</a>> > Signed-off-by: Alex Deucher <<a href="mailto:alexander.deucher@amd.com">alexander.deucher@amd.com</a>> > > Linux 4.20 contains a commit trying to fix flickering issues: > commit ec2e082a79b5d46addf2e7b83a13fb015fca6149 > Author: Alex Deucher <<a href="mailto:alexander.deucher@amd.com">alexander.deucher@amd.com</a>> > 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 <<a href="mailto:Rex.Zhu@amd.com">Rex.Zhu@amd.com</a>> > Reviewed-by: Huang Rui <<a href="mailto:ray.huang@amd.com">ray.huang@amd.com</a>> > Signed-off-by: Alex Deucher <<a href="mailto:alexander.deucher@amd.com">alexander.deucher@amd.com</a>> > > But that doesn't fix the screen corruption described in this bug, because > the problem is not that VBITimeout isn't updated enough, but rather the > opposite, i.e. that it gets set to the frame_time_x2 value calculated from > the correct, 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 > and thus VBITimeout from being smaller than 280, as in the attached patch. > Setting 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 > rates, as well. Well, people are reporting this patch to be a success. Can you submit this to be reviewed for merging into the kernel? By the way, I have this issue with the amdgpu package, not amdgpu-experimental.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>