[Bug 102646] Screen flickering under amdgpu-experimental [buggy auto power profile]
bugzilla-daemon at freedesktop.org
bugzilla-daemon at freedesktop.org
Tue Aug 6 18:54:36 UTC 2019
https://bugs.freedesktop.org/show_bug.cgi?id=102646
--- Comment #101 from Maxim Ivanov <m.ivanov2k at gmail.com> ---
(In reply to Ahzo from comment #97)
> Created attachment 144950 [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
> 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 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_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 <alexander.deucher at 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=102372
> Reviewed-by: Mike Lothian <mike at fireburn.co.uk>
> Reviewed-by: Harry Wentland <harry.wentland at amd.com>
> Signed-off-by: Alex Deucher <alexander.deucher at 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_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 <Rex.Zhu at 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 <evan.quan at amd.com>
> Signed-off-by: Rex Zhu <Rex.Zhu at amd.com>
> Signed-off-by: Alex Deucher <alexander.deucher at amd.com>
>
> Linux 4.20 contains a commit trying to fix flickering issues:
> commit ec2e082a79b5d46addf2e7b83a13fb015fca6149
> Author: Alex Deucher <alexander.deucher at 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 at amd.com>
> Reviewed-by: Huang Rui <ray.huang at amd.com>
> Signed-off-by: Alex Deucher <alexander.deucher at amd.com>
>
> 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.
--
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20190806/4630cee4/attachment-0001.html>
More information about the dri-devel
mailing list