[Intel-gfx] Page flipping not working as expected for compositing - engineering resource available to help fix it
Jesse Barnes
jbarnes at virtuousgeek.org
Mon May 10 20:00:49 CEST 2010
On Mon, 10 May 2010 17:59:16 +0100
Simon Farnsworth <simon.farnsworth at onelan.com> wrote:
> On Monday 10 May 2010, Simon Farnsworth <simon.farnsworth at onelan.com> wrote:
> > On Friday 7 May 2010, Simon Farnsworth <simon.farnsworth at onelan.com> 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,
What about the indirect bug? Did that also go away when you fixed the
perms issue? If not, that sounds like a serious issue, in indirect
mode the swap interval should still be honored I think...
--
Jesse Barnes, Intel Open Source Technology Center
More information about the Intel-gfx
mailing list