Re: [RFC] Async flips

[Jesse Barnes <jbarnes@virtuousgeek.org>]

On Wed, 31 Oct 2012 15:49:36 +0000
Chris Wilson <chris@chris-wilson.co.uk> wrote:

> On Wed, 31 Oct 2012 08:39:09 -0700, Jesse Barnes <jbarnes@virtuousgeek.org> wrote:
> > On Wed, 31 Oct 2012 16:26:54 +0100
> > Daniel Vetter <daniel@ffwll.ch> wrote:
> > 
> > > On Wed, Oct 31, 2012 at 4:23 PM, Jesse Barnes <jbarnes@virtuousgeek.org> wrote:
> > > >
> > > >> On Tue, Oct 30, 2012 at 01:33:47PM -0500, Jesse Barnes wrote:
> > > >> > The hw supports async flips through the render ring, so why not expose it?
> > > >> > It gives us one more "tear me harder" option we can use in the DDX and
> > > >> > for other cases where simply flipping to the latest buffer is more
> > > >> > important than visual quality.
> > > >>
> > > >> The only reason I can see why anyone would really want async flips is
> > > >> when you're restricted to double buffering. With triple buffering you
> > > >> should be able to override the previous flip w/o tearing.
> > > >>
> > > >> Well, actually if you use the ring based flips, then you can't do the
> > > >> override. My atomic page flip code can do it because it's using mmio
> > > >> flips. There were also other reasons favoring mmio over ring.
> > > >>
> > > >> Once the atomic code is deemed ready, I would suggest we just nuke the
> > > >> ring based flip code (pun intended).
> > > >
> > > > Yeah, I agree.  In fact one of the first versions of the flip code used
> > > > mmio, and I think it's a better way to go.
> > > 
> > > How are we gonna sync up with outstanding rendering before issuing the
> > > flip? If the answer is involves enabling the render irq, I'm not gonna
> > > like it ;-)
> > 
> > Why are you afraid of irqs when rendering is active?  We'll already be
> > awake at those times anyway...
> 
> Because it involves the driver stalling.

Can you elaborate?  I know there are pros & cons to mmio vs ring.
Synchronization is different in each case, and getting the flip to
happen when you want can be tough too in both cases.

-- 
Jesse Barnes, Intel Open Source Technology Center