Re: [RFC] Async flips

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

On Wed, Oct 31, 2012 at 10:44:47AM -0700, Eric Anholt wrote:
> Ville Syrjälä <ville.syrjala@linux.intel.com> writes:
> 
> > 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).
> 
> Can you outline what exactly your plan is for doing faster-than-vblank
> page flipping without tearing, and how it gets synchronized with
> rendering?

The faster than vrefresh flipping simply involves overwriting the
display plane registers before they've been latched by the hardware.
This appears to work fine already.

As far as the synchronization goes, I basically just want a callback
from the GPU when it's done with the buffer. I'm expecting to find
some kind of GPU progress interrupt that I can enable while I'm waiting
for the GPU to catch up. So I also need a FIFO to store the flip
requests in the meantime. Once the GPU tells me it's ready, I pull the
flip request from the queue and proceed with the display plane
programming.

So the synchronization part it's still quite handwavy, and I need
to study the hardware/driver in more detail to figure out the
specifics.

-- 
Ville Syrjälä
Intel OTC