[RFC] DRI2 synchronization and swap bits
keithp at keithp.com
Fri Oct 30 19:15:17 PDT 2009
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
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
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...
Size: 190 bytes
Desc: not available
Url : http://lists.x.org/archives/xorg-devel/attachments/20091030/0bf47b6e/attachment.pgp
More information about the xorg-devel