[RFC] DRI2 synchronization and swap bits

[Jesse Barnes]

On Fri, 30 Oct 2009 19:15:17 -0700
Keith Packard <keithp at keithp.com> wrote:

> Excerpts from Jesse Barnes's message of Fri Oct 30 10:59:08 -0700
> 2009:
> 
> > These allow us to support GLX extensions like SGI_video_sync,
> > OML_swap_control and SGI_swap_interval.
> 
> Let's get the protocol nailed down before we go into detailed code
> review. Besides, you need to rebase -i to get rid of the broken
> versions.

Yeah, some merging/splitting of the commits is in order before merging
it upstream.

> > There have been a few comments about the protocol so far:
> >   1) DRI2SwapBuffers
> >      a) Concern about doing another round trip to fetch new buffers
> >     following the swap.
> 
> Do we want to deal with stereo here?

I think the protocol is sufficient for that; it just requests the swap,
so for stereo buffers both would be swapped.

> >         I think this is a valid concern, we could potentially
> > respond from the swap with the new buffers, but this would make some
> >         memory saving optimizations more difficult (e.g. freeing
> >         buffers if no drawing comes in for a short time after the
> >         swap).
> 
> Hrm. Ideally, we'd send back new buffer IDs but delay creation until
> someone accessed them. That would require kernel magic to create an
> un-realized buffer, but perhaps avoiding an explicit round trip per
> swap would be worth it?

I don't see how we can avoid the round trip entirely, without sharing
some state between the server and client (i.e. re-introducing the
SAREA).  I'll do some benchmarking of the proposed buffer freeing and
see how bad it is.

> >   2) DRI2WaitMSC/SBC
> >      a) Concern about blocking the client on the server side as
> > opposed to a client side wait.
> 
> So, some kind of cookie that you'd pass to the kernel for the wait
> instead of just blocking in the server? I can see a lot of uses for
> this kind of mechanism beyond X, which makes it somewhat more
> interesting to contemplate in this case.

Oh we never block the server.  The protocol here just tells the server
when the client should be awakened again by passing a cookie.  The open
question is whether the server should be putting the client to sleep
and waking it back up, or whether in the direct rendered case the
client gets a cookie from the server and sleeps itself (in the aiglx
case the server has to handle things regardless).

> > The implementation tries to avoid blocking the clients at all for
> > swap requests, only blocking them on wait requests that are
> > specified to cause blocking.  This should allay the concerns raised
> > in the page flipping thread about unnecessary blocking of clients
> > (that's left as an implementation detail for the drivers supporting
> > these new functions).
> 
> Do we have a driver which does this the 'right' way yet?

The i915 page flipping code does this correctly, by marking the buffers
in question busy and blocking the client in the kernel if it tries to
access a busy buffer.  For the windowed swap case we may have to block
the client less nicely if we end up blitting between back & front.  (GL
fences could make this better.)

Jesse