On Tue, 2008-08-19 at 12:57 +0200, Michel Dänzer wrote: > Also, I'm wondering if xDRI2Buffer should have a buffer size field, or > if any buffer size padding requirements beyond height * pitch can always > be handled in the driver components.
GEM has all of this information in the kernel, so that API doesn't really need anything else in DRI2. Other EMs may have additional requirements; we could handle those with driver-specific interfaces, either kernel or protocol. > Making SwapBuffers a round trip isn't ideal for sync to vblank > (especially considering potentially using triple buffering, but see > below). Also, it looks like currently every glXCopySubBufferMESA() call > is a roundtrip as well, which might incur a noticeable hit with compiz. A reply is equivalent to an event from the protocol perspective; it's just a response from server back to the client so that the client can serialize as necessary. XCB makes it easy to leave these non-blocking; Xlib requires a bit more work, but it would still be possible. Using a reply has the added benefit of not requiring that the applications forward X events into the library -- XCB will queue the reply when it receives it, and Xlib will give us a callback. Both will let us block waiting for the reply without managing events. > About triple buffering, AFAICT this scheme makes that impossible, as > well as implementing buffer swaps by just flipping the front and back > buffers, because the clients won't know the mapping from API buffers to > memory buffers changed. One option here is to have the X server actually flip buffers around so that the existing application references end up pointing at the right buffers after wards. This is just handwaving on my part though. The alternative is some back-channel through the kernel as with the basic buffer information above. > Have you considered any other schemes, e.g. some kind of event triggered > when a buffer swap actually takes effect, and which includes information > about the new mapping from API buffers to memory buffers? Or is the idea > to just leave any advanced SwapBuffers schemes to the drivers? I assume the X reply (or event, if we switch) would be triggered by the actual buffer swap. Is that sufficient? Or should we return a reply when the request is queued and then an event when it actually occurs? > > Since we just end up calling CopyArea, damage is posted automatically > > and now DRI magically works with SW cursors. > > Nice for MPX. :) Yeah, Peter got fairly excited when he heard that. -- [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
