On Fri, Oct 25, 2002 at 06:19:14PM +0100, Keith Whitwell wrote: > Ian Romanick wrote: > > On Fri, Oct 25, 2002 at 10:39:23AM -0600, Jens Owen wrote: > > > > > >>I've heard you and others talk about triple buffering a few times, and > >>I'm wondering if you can fill me in on a few details. Is the primary > >>motivation for a 3rd buffer to aliviate delays associated with vertical > >>refresh? Using a page swapping method, I would guess the pointers for > >>front, back and display buffer would look like: > >> > > > > Yes, that is a very nice summary of triple buffering. You've also caught on > > to the potential problem with it. If your frame rate exceeds your refresh > > rate, you're toast. > > Only if you sync to vertical refresh. I wouldn't propose that... From my > point of view it's a scheme to make pageflipping work on hardware where the > pageflip command isn't instantaneous. When this is the case you have to wait > on the pageflip, which is boring, or start rendering immediately (a clear to > the new backbuffer, which is still being displayed, which is bad), or have a > third buffer to look at --- triple buffering.
That's basically what we said. :) You're still toast if you render too fast. I remember running into this problem when I was demo coding on the Amiga back-in-the-day. I used triple buffering in my 3D demos so that I never had to wait for the retrace. Then I upgraded from my Amiga 500 (7.14MHz 68000) to an Amiga 3000 (25MHz 68030) and all hell broke loose. Here's the problem... Time step 1: - Buffer 0 is being displayed (front buffer / display buffer). - Buffer 1 is the render buffer (back buffer). Time step 2: - Finish rendering to buffer 1, and queue it to be displayed on the next frame (front buffer). - Buffer 0 is still being displayed. Vertical beam is, say, 1/3rd of the way down the screen now (display buffer). - Buffer 2 becomes the render buffer (back buffer). Time step 3: - Finish rendering to buffer 2, and queue it to be displayed on the next frame (front buffer). - Buffer 0 is still being displayed. Vertical beam is, say, 2/3rd of the way down the screen now (display buffer). - Buffer 0 becomes the render buffer (back buffer). Time step 4: - Hey! What happened to the bottom of my display?!? Let me tell you what, that took a long time to debug! Notice that this is exactly the same problem as in the double buffer case if you don't wait for the retrace. The sollution was to use a vblank interrupt to (basically) fence the buffers, though I didn't know the term 'fence' at the time. You still /might/ have to wait, but only if you have a very high frame rate. That's why I only saw the problem after increasing my CPU speed by a factor of 10. :) -- Smile! http://antwrp.gsfc.nasa.gov/apod/ap990315.html ------------------------------------------------------- This sf.net email is sponsored by: Influence the future of Java(TM) technology. Join the Java Community Process(SM) (JCP(SM)) program now. http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0004en _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
