On Wed, 2008-08-20 at 11:52 +0200, Michel Dänzer wrote: > Anyway, this isn't my concern. It's that the client should not have to > block any earlier than when it needs to render to a buffer with a > pending buffer swap.
Right, that's why Kristian proposed the two-request solution, one async
one to queue the swap and a second sync one to wait for the swap to
occur. The first would not block further X requests while the second
would.
> So long as the DRI2 SwapBuffers interface isn't synchronous, it should
> be fine I think.
Yup, just need a second one to serialize the buffer swap with X or DRI
operations touching the buffer.
> Maybe SwapBuffers could
> just return some sort of implementation specific fence handle that can
> be used for either kind of synchronization.
Hmm. I think this would take three operations then:
1. Swap buffers. X request which returns a fence ID.
2. Block X. X request which takes a fence ID, stops X requests
until that fence has passed. Does not have a reply.
3. Block DRI. Kernel API that takes a fence id and blocks ring
submissions until that fence has passed.
--
[EMAIL PROTECTED]
signature.asc
Description: This is a digitally signed message part
------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/
-- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
