Re: [RFC] Async flips

["Ville Syrjälä" <ville.syrjala@linux.intel.com>]

On Wed, Oct 31, 2012 at 04:26:54PM +0100, Daniel Vetter 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 ;-)

That's currently the only major TODO item on my list. Currently the
ioctl just ends up blocking when I pin the buffers, but I need some
async method to avoid that. So yes, irqs seem like the right approach
here. What's the problem w/ irqs?

-- 
Ville Syrjälä
Intel OTC