From mboxrd@z Thu Jan 1 00:00:00 1970 From: Simon Farnsworth Subject: Re: Page flipping not working as expected for compositing - engineering resource available to help fix it Date: Mon, 10 May 2010 17:59:16 +0100 Message-ID: <201005101759.16910.simon.farnsworth@onelan.com> References: <201005071407.48208.simon.farnsworth@onelan.com> <201005101204.54591.simon.farnsworth@onelan.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from claranet-outbound-smtp00.uk.clara.net (claranet-outbound-smtp00.uk.clara.net [195.8.89.33]) by gabe.freedesktop.org (Postfix) with ESMTP id 580329E76A for ; Mon, 10 May 2010 09:59:20 -0700 (PDT) Received: from host217-35-101-6.in-addr.btopenworld.com ([217.35.101.6]:38929 helo=f12simon.localnet) by relay00.mail.eu.clara.net (relay.clara.net [213.253.3.40]:1025) with esmtpa (authdaemon_plain:simon.farnsworth@onelan.com) id 1OBWK6-0001rX-0p for intel-gfx@lists.freedesktop.org (return-path ); Mon, 10 May 2010 16:59:18 +0000 In-Reply-To: <201005101204.54591.simon.farnsworth@onelan.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: intel-gfx-bounces+gcfxdi-intel-gfx=m.gmane.org@lists.freedesktop.org Errors-To: intel-gfx-bounces+gcfxdi-intel-gfx=m.gmane.org@lists.freedesktop.org To: intel-gfx@lists.freedesktop.org List-Id: intel-gfx@lists.freedesktop.org On Monday 10 May 2010, Simon Farnsworth wrote: > On Friday 7 May 2010, Simon Farnsworth wrote: > > I've attached my test program (it's based on our C++ OpenGL compositor, > > but cut down to just test OpenGL pageflipping) as performance.c, and my > > test X stack's Xorg.0.log after one run of "performance -indirect" > > (which ran for 573 frames). I'm using a 32-bit PAE kernel - I can add > > information as required, and I'm happy to run tests or experiments for > > people. > > > > 2) How should I go about fixing compositing? Should I fix indirect > > rendering to use pageflipping (and if so, where do I start looking for > > the code that's getting it wrong), or should I make TFP work when direct > > rendering (and again, where should I start looking)? > > Is this the expected behaviour when indirect rendering? If so, I'll dive > back into the stack and see if I can work out why TFP and direct rendering > don't interact nicely. If not, roughly where should I look to fix it? I've found why direct rendering and TFP don't interact nicely, and it's a client side error. Briefly, my compositor was being started as our signage user, who does not have access to /dev/dri/card0, so was falling back to swrast. When you're using swrast, TFP only appears to work for pixmaps you create, not for compositing pixmaps. Sorry for the noise, -- Simon Farnsworth Software Engineer ONELAN Limited http://www.onelan.com/