Re: [Dri-devel] Triple Buffering
On Fri, 22 Nov 2002 09:42:06 +0100 "Marcelo E. Magallon" <[EMAIL PROTECTED]> wrote: > > Then you are taking about a single frame taking 1/120 seconds to > render, and not about pushing 120 frames per second to the user. > Which, if you think about it, is what I said previously. ok, fair enough. but obviously the user isnt seeing those 120 frames if their refresh is only 80. So the number reported clearly isnt the number of displayed frames (if we're not talking single buffered no-sync...) --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Triple Buffering
On Thu, Nov 21, 2002 at 03:45:19PM +, Ian Molton wrote: > > What's the point of trying to display 120 Hz if you monitor can only > > do 85 Hz? > > the faster you render, the lower your latency. its pointless for 3D > modelling / artwork, but very nice for 3D games. Then you are taking about a single frame taking 1/120 seconds to render, and not about pushing 120 frames per second to the user. Which, if you think about it, is what I said previously. -- Marcelo --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Triple Buffering
On Thu, 21 Nov 2002 12:14:20 +0100 "Marcelo E. Magallon" <[EMAIL PROTECTED]> wrote: > > What's the point of trying to display 120 Hz if you monitor can only > do 85 Hz? the faster you render, the lower your latency. its pointless for 3D modelling / artwork, but very nice for 3D games. --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Triple Buffering
On Sun, Oct 27, 2002 at 04:44:34PM +0100, Felix Kühling wrote: > But this way you waste lots of CPU cycles on frames which are never > displayed. Wouldn't be waiting (IRQ) for the pageflip to occur before > you render the 3rd frame in the above example a better approach? What's the point of trying to display 120 Hz if you monitor can only do 85 Hz? On SGIs, which sync to vblank per default, there's a query which sort of tells you "how much time you have before the next swap happens". In that way you can decide if you want to wait for it or miss it. If you let it fly by, you can use the extra time to keep doing stuff in your simulation. The way I understood triple buffering the intention is to avoid hanging there for long times waiting for the vblank. You get the benefits from sync-to-vblank (no tearing) while paying a somewhat smaller price. -- Marcelo --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Triple Buffering
On Fri, 25 Oct 2002 23:38:41 +0100 Ian Molton <[EMAIL PROTECTED]> wrote: > On Fri, 25 Oct 2002 10:34:35 -0700 > Ian Romanick <[EMAIL PROTECTED]> wrote: > > > > > Time step 1: > > > > Er. surely you would render lkike this > > 1: Display 0 Render 1 > 2: Display 0.n Render 2 > Now, if still displaying 0, swap 1 and 2 (surely a pointer swap) and > re-render in 1 else switch to 1. > > in other words, never render to the current buffer, but keep rendering > full-tilt into the two back buffers alternately until one gets flipped. > > At least, thats how I used to do things on my old A410... But this way you waste lots of CPU cycles on frames which are never displayed. Wouldn't be waiting (IRQ) for the pageflip to occur before you render the 3rd frame in the above example a better approach? Felix __\|/_____ ___ ___ __Tschüß___\_6 6_/___/__ \___/__ \___/___\___You can do anything,___ _Felix___\Ä/\ \_\ \_\ \__U___just not everything [EMAIL PROTECTED]>o<__/ \___/ \___/at the same time! --- This SF.net email is sponsored by: ApacheCon, November 18-21 in Las Vegas (supported by COMDEX), the only Apache event to be fully supported by the ASF. http://www.apachecon.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Triple Buffering
On Fri, 25 Oct 2002 10:34:35 -0700 Ian Romanick <[EMAIL PROTECTED]> wrote: > > Time step 1: Er. surely you would render lkike this 1: Display 0 Render 1 2: Display 0.n Render 2 Now, if still displaying 0, swap 1 and 2 (surely a pointer swap) and re-render in 1 else switch to 1. in other words, never render to the current buffer, but keep rendering full-tilt into the two back buffers alternately until one gets flipped. At least, thats how I used to do things on my old A410... --- This SF.net email is sponsored by: ApacheCon, November 18-21 in Las Vegas (supported by COMDEX), the only Apache event to be fully supported by the ASF. http://www.apachecon.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Triple Buffering
Keith, Ian, Thanks for educating me on the issues. -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado --- 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
Re: [Dri-devel] Triple Buffering
On Fri, Oct 25, 2002 at 10:34:35AM -0700, Ian Romanick wrote: > Time step 1: > - Buffer 0 is being displayed (front buffer / display buffer). > - Buffer 1 is 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?!? > ... > 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. :) whats wrong with simply changing the way you do next-frame queueing, and make it most-recent, instead of always progressing? eg: at step 3, - finish rendering to buffer 2 - mark buffer2 as next to be displayed - if buffer 0 still being displayed, start rendering to buffer 1 [-] else 0 must be free, start rendering to buffer 1 ? Is the problem that the prior commands are already "in the queue"? If you are queuing up 3d commands way ahead of the video card draw speed, then maybe the trick would be to make sure that queue buffers were no more than [X rendertime] long. ideally, so that you would have the case where there would be multiple dmabuffers, looking like: dmabuf1 [ draw draw draw ] dmabuf2 [ draw showbuffer1 ] dmabuf3 [ draw draw draw ] dmabuf4 [ (being filled) ] So if the videocard is still working on buf1, then buf2 is not "active"(?) so you might be able to yank it, remove the showbuffer1 command, then put showbuffer2 in the dmabuf4 queue, and THEN start rending to buffer 1 again. if videocard has reached buf2, then you just wait for a few cycles, since you now shouldnt have long to wait. related to that - if you are tripple-buffering, maybe mandate that the [showbufferX] should always be in a dmabuffer BY ITSELF. So it is "easy" (?) to yank it if required. --- 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
Re: [Dri-devel] Triple Buffering
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 --- 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
Re: [Dri-devel] Triple Buffering
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
Re: [Dri-devel] Triple Buffering
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. 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
Re: [Dri-devel] 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. -- 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
[Dri-devel] Triple Buffering
Keith, 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: Before SwapBuffers: Buffer 1 Buffer 2 Buffer 3 ^^ Front & Back Display After SwapBuffers but Before Vertical Retrace: Buffer 1 Buffer 2 Buffer 3 ^^^ Display FrontBack At Vertical Retrace: Buffer 1 Buffer 2 Buffer 3 ^^ Front & Back Display I'm wondering what happens when the frame rate exceeds the refresh rate. Also, would X need to render to all 3 buffers? Would X's notion of front and back (For DBE) still work at a semantic level? I know DBE doesn't work properly with the DRI right now, but we haven't done anything to prevent it from being implemented. -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado --- 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
