From: Keith W. <ke...@tu...> - 2002-10-25 18:32:15
|
Ian Romanick wrote: > 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. :) 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. Keith |