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=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 7280DC433EF for ; Thu, 16 Sep 2021 13:17:57 +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 2E77D6120F for ; Thu, 16 Sep 2021 13:17:57 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 2E77D6120F Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linux.intel.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 9470F6EB7C; Thu, 16 Sep 2021 13:17:56 +0000 (UTC) Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) by gabe.freedesktop.org (Postfix) with ESMTPS id 0243F6EB7C for ; Thu, 16 Sep 2021 13:17:55 +0000 (UTC) X-IronPort-AV: E=McAfee;i="6200,9189,10108"; a="308104596" X-IronPort-AV: E=Sophos;i="5.85,298,1624345200"; d="scan'208";a="308104596" Received: from orsmga007.jf.intel.com ([10.7.209.58]) by fmsmga105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 16 Sep 2021 06:17:55 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.85,298,1624345200"; d="scan'208";a="472765637" Received: from stinkbox.fi.intel.com (HELO stinkbox) ([10.237.72.171]) by orsmga007.jf.intel.com with SMTP; 16 Sep 2021 06:17:53 -0700 Received: by stinkbox (sSMTP sendmail emulation); Thu, 16 Sep 2021 16:17:52 +0300 Date: Thu, 16 Sep 2021 16:17:52 +0300 From: Ville =?iso-8859-1?Q?Syrj=E4l=E4?= To: "Souza, Jose" Cc: "Mun, Gwan-gyeong" , "intel-gfx@lists.freedesktop.org" Message-ID: References: <20210914212507.177511-1-jose.souza@intel.com> <20210914212507.177511-3-jose.souza@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Patchwork-Hint: comment Subject: Re: [Intel-gfx] [PATCH v2 3/5] drm/i915/display: Workaround cursor left overs with PSR2 selective fetch enabled X-BeenThere: intel-gfx@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Intel graphics driver community testing & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" On Wed, Sep 15, 2021 at 06:18:35PM +0000, Souza, Jose wrote: > On Wed, 2021-09-15 at 17:58 +0300, Ville Syrjälä wrote: > > On Tue, Sep 14, 2021 at 02:25:05PM -0700, José Roberto de Souza wrote: > > > Not sure why but when moving the cursor fast it causes some artifacts > > > of the cursor to be left in the cursor path, adding some pixels above > > > the cursor to the damaged area fixes the issue, so leaving this as a > > > workaround until proper fix is found. > > > > Have you tried warping the cursor clear across the screen while > > a partial update is already pending? I think it will go badly. > > You mean move the cursor for example from 0x0 to 500x500 in one frame? > It will mark as damaged the previous area and the new one. Legacy cursor updates bypass all that stuff so you're not going to updating the sel fetch area for the other planes. > > > > > In fact I'm thinking the mailbox style legacy cursor updates are just > > fundementally incompatible with partial updates since the cursor > > can move outside of the already committed update region any time. > > Ie. I suspect while the cursor is visible we simply can't do partial > > updates. > > Probably I did not understand what you want to say, but each cursor update will be in one frame, updating the necessary area. The legacy cursor uses mailbox updates so there is no 1:1 relationship between actual scanned out frames and cursor ioctl calls. You can have umpteen thousand cursor updates per frame. > So I can't understand why it is incompatible. Because all the other planes already got their selective fetch area updated earlir, and now the cursor's new update area is something totally different. Doesn't the total area need to computed to comprise of a single crtc space rectangle essentially? So we could start with something like: sel fetch area | v ________________ | ________ | | | plane | | | | |_____ | | _________ || | _ | plane || | |_| |_______|| |________________| ^ | cursor Then the cursor moves before the hardware has even latched the previous update: old sel fetch area | v ________________ | ________ | | | plane | | _ | | |_____ | |_| | _________ || ^ | | plane || | | |_______|| cursor |________________| -- Ville Syrjälä Intel