From patchwork Mon Aug 5 22:11:01 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: bugzilla-daemon@freedesktop.org X-Patchwork-Id: 11077809 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 8B80714DB for ; Mon, 5 Aug 2019 22:11:07 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 754E82857D for ; Mon, 5 Aug 2019 22:11:07 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 64C8E28833; Mon, 5 Aug 2019 22:11:07 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.2 required=2.0 tests=BAYES_00,HTML_MESSAGE, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED autolearn=ham version=3.3.1 Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.wl.linuxfoundation.org (Postfix) with ESMTPS id 72AB02857D for ; Mon, 5 Aug 2019 22:11:06 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id E154A6E2EC; Mon, 5 Aug 2019 22:11:03 +0000 (UTC) X-Original-To: dri-devel@lists.freedesktop.org Delivered-To: dri-devel@lists.freedesktop.org Received: from culpepper.freedesktop.org (culpepper.freedesktop.org [IPv6:2610:10:20:722:a800:ff:fe98:4b55]) by gabe.freedesktop.org (Postfix) with ESMTP id C85736E2B2 for ; Mon, 5 Aug 2019 22:11:02 +0000 (UTC) Received: by culpepper.freedesktop.org (Postfix, from userid 33) id C51AE72167; Mon, 5 Aug 2019 22:11:02 +0000 (UTC) From: bugzilla-daemon@freedesktop.org To: dri-devel@lists.freedesktop.org Subject: [Bug 102646] Screen flickering under amdgpu-experimental [buggy auto power profile] Date: Mon, 05 Aug 2019 22:11:01 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: DRI X-Bugzilla-Component: DRM/AMDgpu X-Bugzilla-Version: unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: major X-Bugzilla-Who: Ahzo@tutanota.com X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: high X-Bugzilla-Assigned-To: dri-devel@lists.freedesktop.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc attachments.created Message-ID: In-Reply-To: References: X-Bugzilla-URL: http://bugs.freedesktop.org/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" X-Virus-Scanned: ClamAV using ClamSMTP https://bugs.freedesktop.org/show_bug.cgi?id=102646 Ahzo@tutanota.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |Ahzo@tutanota.com --- Comment #97 from Ahzo@tutanota.com --- Created attachment 144950 --> https://bugs.freedesktop.org/attachment.cgi?id=144950&action=edit 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 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 Reviewed-by: Harry Wentland Signed-off-by: Alex Deucher 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 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 Signed-off-by: Rex Zhu Signed-off-by: Alex Deucher Linux 4.20 contains a commit trying to fix flickering issues: commit ec2e082a79b5d46addf2e7b83a13fb015fca6149 Author: Alex Deucher 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 Reviewed-by: Huang Rui Signed-off-by: Alex Deucher 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. 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: