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? -- [email protected]
signature.asc
Description: PGP signature
------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference
-- _______________________________________________ Dri-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dri-devel
