From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9D21EC2D0E5 for ; Wed, 25 Mar 2020 18:53:44 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 7DE2C2076F for ; Wed, 25 Mar 2020 18:53:44 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7DE2C2076F Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=intel.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=dri-devel-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 1885E6E1F9; Wed, 25 Mar 2020 18:53:43 +0000 (UTC) Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by gabe.freedesktop.org (Postfix) with ESMTPS id 44BA06E19B for ; Wed, 25 Mar 2020 18:53:41 +0000 (UTC) IronPort-SDR: gYj8eu8X9RR6bbKoV9TgyT2sc/ZAxvA+Rjg9195FkfyLZ0NWaI7zpmyG1mHc80nNBRKF4X04U8 E30SnA59DvLA== X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by orsmga101.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 25 Mar 2020 11:53:40 -0700 IronPort-SDR: CuEazhPQX4Ep7yHyBiM6whSZC0Uf8n695K9lyoqpQ9iEKs67BclaUttydKLtqaAxqgTn+yoCav nZc3jFQ6KC5Q== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.72,305,1580803200"; d="scan'208";a="357896634" Received: from labuser-z97x-ud5h.jf.intel.com (HELO intel.com) ([10.165.21.211]) by fmsmga001.fm.intel.com with ESMTP; 25 Mar 2020 11:53:39 -0700 Date: Wed, 25 Mar 2020 11:55:27 -0700 From: Manasi Navare To: Harry Wentland Subject: Re: Variable Refresh Rate & flickering screens Message-ID: <20200325185526.GA14320@intel.com> References: <647ff0e7-f186-4e16-f9b9-0908a3171051@daenzer.net> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Scott Anderson , Michel =?iso-8859-1?Q?D=E4nzer?= , DRI Development , Alex Deucher , "Anthony.Koo@amd.com" , Nicholas Kazlauskas Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" On Tue, Mar 17, 2020 at 09:25:33AM -0400, Harry Wentland wrote: > > > On 2020-03-17 5:08 a.m., Simon Ser wrote: > > On Thursday, March 12, 2020 3:43 PM, Harry Wentland wrote: > > > >> Not the main VRR expert and we're still discussing this internally but I > >> think it'll very much depend on the display whether you'll see flicker > >> in this case. > >> > >> The other complication is that for gaming we don't want to use the > >> cursor as a VRR trigger and only look at page flips in order to allow > >> for smooth gameplay. For a desktop use-case that's probably not the > >> right policy. > > > > I think user-space can handle this and correctly synchronize cursor > > updates with game updates via the KMS atomic API. > > > > However I still think flickering should be avoided by the hardware. > > Flickering is a completely separate issue and user-space shouldn't add > > workarounds for screen issues like this. > > > > Do you think that would be acceptable? Do you have any "slew rate > > register" in AMD hardware? > > In case of Intel HW, we do have a way to program the maxshift so the max increment or decrement in the vblank in successive frames. This is designed to be used for the displays that have a restriction on the maximum change in refresh rate between two consecutive frames. But I am still figuring out how the panel indicates this restriction that we need to program in the HW registers. Harry/SImon, do you know of any such panels that have these restrictions and if they indicate this limitation or the maxshift through EDID or DPCD? Manasi > > There are no slew rate registers in current AMD HW but I also think > slewing would best be done in kernel space, either directly in HW by HW > that supports it or in SW for HW that doesn't support it. > > Harry > > > Thanks, > > > > Simon > > _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel