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.pack...@intel.com
signature.asc
Description: PGP signature
_______________________________________________ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel
