From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tony Lindgren Subject: Re: [PATCH] drm/omap: gem: Fix tearing with BO_TILED Date: Wed, 8 Jan 2020 08:57:14 -0800 Message-ID: <20200108165714.GI5885@atomide.com> References: <20191221005711.47314-1-tony@atomide.com> <20191221164141.GI35479@atomide.com> <20200104050950.GA11429@chinchilla> <20200104055011.GA5885@atomide.com> <20200105203704.GD5885@atomide.com> <20200106180631.GA30670@chinchilla> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <20200106180631.GA30670@chinchilla> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Tomi Valkeinen , Laurent Pinchart , Sebastian Reichel , dri-devel@lists.freedesktop.org, linux-omap@vger.kernel.org, "H . Nikolaus Schaller" , Merlijn Wajer List-Id: linux-omap@vger.kernel.org * Matthijs van Duin [200106 10:07]: > On Sun, Jan 05, 2020 at 12:37:04PM -0800, Tony Lindgren wrote: > > 4. The issue I'm seeing with stellarium on droid4 may be a stride > > issue as about one out of 3 or 4 frames is OK and aligning to > > 512 also fixes the issue maybe because it happens to make > > multiple frames align to 4096 > > Yeah if your buffers are 960 pixels wide (assuming the droid4's screen > is natively portrait) and 32bpp then 512-byte alignment suffices to > automatically make them 4KB alignment. Hmm sounds like I need to retest this. But doesn't 512-byte alignment only make the 960 pixels case 2KB aligned? > The most obvious thing I can think of that could do wrong is that it > might contiguously map the pages that cover each line, which is what > will happen if they use e.g. for_each_sg_page, but subsequently assume > that the stride in sgx virtual memory is ALIGN( width * cpp, PAGE_SIZE ) > without taking the offset of the buffer inside the mapping into account. OK > If each line is at most 4KB (i.e. 1024 pixels @ 32bpp) but each line > straddles an MMU page boundary, then the result would be that the even > lines of the frame are written to the top half of the buffer, causing it > to be scaled to 50% vertically, while the odd lines are "lost" (written > outside the buffer, either to a different buffer or unmapped tiler > memory). This sounds like what you described on irc? Yes this sounds like what I've been seeing. Regards, Tony 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=-0.8 required=3.0 tests=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 E1D2BC282DD for ; Thu, 9 Jan 2020 17:52:22 +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 B2D6F2073A for ; Thu, 9 Jan 2020 17:52:22 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org B2D6F2073A Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=atomide.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 0E77A6E94A; Thu, 9 Jan 2020 17:51:33 +0000 (UTC) Received: from muru.com (muru.com [72.249.23.125]) by gabe.freedesktop.org (Postfix) with ESMTP id 0521E6E062 for ; Wed, 8 Jan 2020 16:57:19 +0000 (UTC) Received: from atomide.com (localhost [127.0.0.1]) by muru.com (Postfix) with ESMTPS id 959CB80C5; Wed, 8 Jan 2020 16:57:58 +0000 (UTC) Date: Wed, 8 Jan 2020 08:57:14 -0800 From: Tony Lindgren To: Tomi Valkeinen , Laurent Pinchart , Sebastian Reichel , dri-devel@lists.freedesktop.org, linux-omap@vger.kernel.org, "H . Nikolaus Schaller" , Merlijn Wajer Subject: Re: [PATCH] drm/omap: gem: Fix tearing with BO_TILED Message-ID: <20200108165714.GI5885@atomide.com> References: <20191221005711.47314-1-tony@atomide.com> <20191221164141.GI35479@atomide.com> <20200104050950.GA11429@chinchilla> <20200104055011.GA5885@atomide.com> <20200105203704.GD5885@atomide.com> <20200106180631.GA30670@chinchilla> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20200106180631.GA30670@chinchilla> X-Mailman-Approved-At: Thu, 09 Jan 2020 17:51:28 +0000 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" * Matthijs van Duin [200106 10:07]: > On Sun, Jan 05, 2020 at 12:37:04PM -0800, Tony Lindgren wrote: > > 4. The issue I'm seeing with stellarium on droid4 may be a stride > > issue as about one out of 3 or 4 frames is OK and aligning to > > 512 also fixes the issue maybe because it happens to make > > multiple frames align to 4096 > > Yeah if your buffers are 960 pixels wide (assuming the droid4's screen > is natively portrait) and 32bpp then 512-byte alignment suffices to > automatically make them 4KB alignment. Hmm sounds like I need to retest this. But doesn't 512-byte alignment only make the 960 pixels case 2KB aligned? > The most obvious thing I can think of that could do wrong is that it > might contiguously map the pages that cover each line, which is what > will happen if they use e.g. for_each_sg_page, but subsequently assume > that the stride in sgx virtual memory is ALIGN( width * cpp, PAGE_SIZE ) > without taking the offset of the buffer inside the mapping into account. OK > If each line is at most 4KB (i.e. 1024 pixels @ 32bpp) but each line > straddles an MMU page boundary, then the result would be that the even > lines of the frame are written to the top half of the buffer, causing it > to be scaled to 50% vertically, while the odd lines are "lost" (written > outside the buffer, either to a different buffer or unmapped tiler > memory). This sounds like what you described on irc? Yes this sounds like what I've been seeing. Regards, Tony _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel