I've put up some trees (after learning my lesson about working in the
main tree) with the latest DRI2 sync/swap bits:
git://git.freedesktop.org/home/jbarnes/xserver master branch
git://git.freedesktop.org/home/jbarnes/mesa master branch
They includes support for some new DRI2 requests (proto for which is in
the dri2-swapbuffers branch of dri2proto), including:
DRI2SwapBuffers
DRI2GetMSC
DRI2WaitMSC
and
DRI2WaitSBC
These allow us to support GLX extensions like SGI_video_sync,
OML_swap_control and SGI_swap_interval.
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.
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).
2) DRI2WaitMSC/SBC
a) Concern about blocking the client on the server side as opposed
to a client side wait.
I'm a bit less worried about this, since these type of waits
typically aren't very latency sensitive. Doing the wait on the
client side is definitely possible though if really desired,
though it would split the request for the DRM event and its
consumption across the server/client boundary (we'd have to
return the sequence number to look for to the client, then
have it poll the DRM fd).
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).
As mentioned above, these changes require new dri2proto, but they also
need libdrm master and airlied's drm-next branch, which has the vblank
event bits that the new server code depends on.
Thanks,
--
Jesse Barnes, Intel Open Source Technology Center
_______________________________________________
xorg-devel mailing list
xorg-devel@lists.x.org
http://lists.x.org/mailman/listinfo/xorg-devel
