[Intel-gfx] [RFC] DRI2 swapbuffers (yes yet again)

[Jesse Barnes]

On Thu, 30 Apr 2009 11:36:55 +0300
Ville Syrjälä <syrjala at sci.fi> wrote:

> On Wed, Apr 29, 2009 at 06:02:59PM -0700, Jesse Barnes wrote:
> > On Wed, 29 Apr 2009 15:09:33 -0700
> > Jesse Barnes <jbarnes at virtuousgeek.org> wrote:
> > > I'm still working through mutlihead issues on the kernel side; the
> > > flip waits should wait for *both* vblank events before completing
> > > the flip.  But other than that, I'm pretty happy with things.
> > 
> > This incremental set fixes up the multihead handling and adds swap
> > interval support as a bonus.  It's nice to see flipping & no
> > tearing on two heads at once!
> 
> Your interval handling seems to be too harsh. In case you wanted
> something that can implement GLX_SGI_swap_control then AFAICS the
> interval should only specify the minimum number of frames that must
> pass between two swaps. Your code appears to always delay the flip by
> exactly interval frames.

The completion won't happen until at least 'interval' frames have
passed since the flip was queued, so I think the semantics match?

> Also it seems that the cases where you have more than one back buffer
> were not yet fully considered. I can see two use cases for this:
> 
> 1) Triple buffering with the purpose of going faster than the monitor
> refresh rate w/o tearing. Here you would never wait for any flips and
> if a new flip is scheduled before the previous was completed then the
> previous flip should be considered immediately complete so the buffer
> can be reused.
> 
> 2) Scheduling multiple flips in advance while maintaining the swap
> interval. This way the application could render several frames in
> advance and just queue the flips in the driver to gain a little more
> breathing room for the rendering.

Yeah, I intended for the DRI2 protocol I added to handle this case, but
there's no code for it yet.  I think it could be done purely in the 2D
driver though.  I think case (2) is probably the most important here,
but (1) is pretty easy to do as well.

> And as a final missing piece I would mention interlaced output with
> proper field parity, but I'm not sure if you're interested in such
> things for this API.

We could treat the 'interval' as meaning odd/even in that case.  I.e.
an interval of 1 would mean 'next field' and 2 would mean 'start of
next frame', but yeah there's not much support for interlacing in the
kernel atm.

-- 
Jesse Barnes, Intel Open Source Technology Center