[RFC] DRI2 synchronization and swap bits

[Keith Packard]

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.

> 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 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?

We can even make the Xlib API asynchronous in this case; just requires
a bit of hackery to post an async reply handler and then a function to
collect the async reply data.

>   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.

> 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?

-- 
keith.packard at intel.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: not available
Url : http://lists.x.org/archives/xorg-devel/attachments/20091030/0bf47b6e/attachment.pgp