On Tue, Aug 19, 2008 at 12:50:18PM -0400, Kristian Høgsberg wrote: > On Tue, Aug 19, 2008 at 6:57 AM, Michel Dänzer > <[EMAIL PROTECTED]> wrote: > > 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? > > Right, the problem with triple buffering is that once we schedule a > swap, we don't know when the previous swap is finished and we can > start rendering again. Is it actually different from the regular > double buffer case though? You still need to block the client, which > we can just do by delaying the reply from DRI2SwapBuffers. In the > triple buffering case you just have an extra buffer and you're > blocking on the previous buffer swap instead of the current.
The idea with triple buffering is that you never have to wait. When you do a flip all you need to know is whether the previously scheduled flip has actually happened or not. If it has you rotate the buffers so that the current scanout buffer is left alone. If the flip hasn't happened yet you just swap the back and front buffers. -- Ville Syrjälä [EMAIL PROTECTED] http://www.sci.fi/~syrjala/ ------------------------------------------------------------------------- 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
