Ian Romanick wrote:
Ah, yes I see where you're coming from -- basically in that case you need to throttle the frame rate anyway -- we already have mechanisms for this, but they may need beefing up if we ever do triple buffering.On Fri, Oct 25, 2002 at 06:19:14PM +0100, Keith Whitwell wrote:Ian Romanick wrote: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.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.
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. :)
Keith
-------------------------------------------------------
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
