On Fri, 28 Aug 2009 15:14:47 +0200 Michel Dänzer <mic...@daenzer.net> wrote: > One possible solution for this would be for the DRI2SwapBuffer request > to return the suggested set of buffers for the next frame, and then > for the client to block (which could involve a DRM event or whatever > if just plain blocking turns out to be a real problem in practice - > doubtful IME) on command submission if those buffers still have > pending flips.
Yeah, that's what the initial implementation did (though with more blocking than was necessary iirc, but that was just an implementation detail). I don't think it precludes things like triple buffering either; the server is still free to allocate new buffers and return them to the client at swapbuffers time. I think we're all agreed that we want to minimize blocking of any kind; we should keep all the clients busy submitting commands as much as possible. Any kind of GPU drain or wait on event is a killer. -- Jesse Barnes, Intel Open Source Technology Center ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
