On Tue, Aug 19, 2008 at 1:29 PM, Keith Packard <[EMAIL PROTECTED]> wrote: > On Tue, 2008-08-19 at 12:50 -0400, Kristian Høgsberg wrote: > >> Are you thinking that the DRI client will do the wait-for-vblank and >> then post the swap buffer request? That's clearly not feasible, but >> my thinking was that the waiting will be done in the X server, thus >> the flags argument to DRI2SwapBuffers. What I think we should do here >> is to use a dedicated command queue for the front buffer and block >> that on vblank using a hw wait instruction. This lets us just fire >> and forget swap buffer commands, since any cliprect changes and >> associated window contents blits end up in the front buffer queue >> after the buffer swap commands. > > How do we block access to the back buffer though? Presumably the DRI > client would like to avoid trashing the content before it is displayed > on the screen.
We can just submit the swap buffer commands, wait for them to fire and then send the reply. What we do now is to wait for vblank and then submit the swap commands, what I'm suggesting is to submit the commands and wait for vblank. Same thing. We cound conceivably do better if we could let software queue up commands for the next frame, either in a blocked command ring (sw or hw) and then unblock it once the swap commands have been executed. This increases the parallelism, but relieson synchronization between multiple command queues. >> One thing I had in mind was that DRI2SwapBuffers could return the new >> color buffer, or maybe it should just return the full new set of >> buffers always. This lets us do page flips for fullscreen >> non-redirected windows and for redirected windows (just swap the >> pixmaps). As it is, it doesn't return anything, but we can add that >> in a later version easily. > > Sounds like having it return the new set of buffers would be a good > idea, although I fear implementing something here that turns out to be > wasteful without an actual user. I doubt it will be really wasteful - we have to do the reply for synchronization purposes, adding ~100 bytes of data to the reply doesn't seem significant. >> Do we need to split DRI2SwapBuffers into two requests? One async >> request that schedules the swap and one that blocks the client and >> waits for the swap to complete and returns the new buffers? > > No, the client doesn't *have* to wait for the reply; it can wait when it > needs to for suitable serialization. We always have to wait before > drawing to the backbuffer, so we always need the reply; splitting this > into two requests just makes it slightly less efficient. Doing it as two requests lets you do other requests between them though and the overhead of an extra async request before the synchronous second half is negligible. Kristian ------------------------------------------------------------------------- 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
