I'm talking traditional/typical double buffering, not special cases.
-----Original Message----- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Lilith Bryant Sent: Thursday, August 05, 2010 5:27 PM To: OpenSceneGraph Users Subject: Re: [osg-users] OSG and vsync (UNCLASSIFIED) My own research indicates that the timing rules are: The first opengl call will block if the back buffer is not available at that point. The swapbuffers will block if there is already a pending swap queued (by the last call to swapbuffers) So, depending on the circumstances, both can block. Lilith On 2010-08-06 11:15:14 AM, Buckley, Bob CTR MDA/DES wrote: > The sync blocks on a swap buffers call, not on the first OpenGL call > (unless > by accident it's an actual OpenGL blocking call). > Non-blocking OpenGL calls run asynchronous on the back buffer (traditional > double buffering). > A glGet call is an actual OpenGL blocking call as it forces a pipe flush. > Making blocking calls when trying to run real time thoroughly defeats the > purpose. > > Giovanni, what you're seeing is typical behavior when syncing with the > vertical retrace. > To maintain real-time at 50Hz each frame must be rendered in less than 20ms > (1/50). > If a frame just happens to take 21ms, then the buffer swap will block for > 19ms before actually swapping buffers. > Hence, your frame rate is cut completely in half (21ms + 19ms = 40ms = > 25Hz). > And it also introduces nasty temporal aliasing. > > I'm not aware of another way to synchronize with such regularity as the > monitor retrace. > I'm guessing that deterministic hardware is required given the nature of > something like OpenSceneGraph on a PC. > Although, you can achieve near real-time by things like database tuning and > pre-emptive rendering. > But, nothing to guarantee actual real time. > > Extra hardware is not needed to run at multiples of the frame rate. > Just set the retrace rate to the desired frame rate and run sync'd. > Boom - multiples of the frame rate. > > > BTW, there's something about this alleged '2 frame latency' charge that > just > doesn't pass the smell test. > Mostly - ATI sure the hell wouldn't let 'em! > > Bob > > -----Original Message----- > From: osg-users-boun...@lists.openscenegraph.org > [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Bunfield, > Dennis AMRDEC/AEgis > Sent: Wednesday, June 23, 2010 4:35 PM > To: osg-users@lists.openscenegraph.org > Subject: Re: [osg-users] OSG and vsync (UNCLASSIFIED) > > Classification: UNCLASSIFIED > Caveats: FOUO > > The sync actually blocks on the first open gl call. So your osg update > and cull stages will run then you will block on the draw stage until the > vsync. Your problem is actually worse than 20ms w/o you knowing it. > For Nvidia cards there is a built in 2 frames of latency. So even after > your sync you won't see the image you updated come out the DVI until 2 > render frames later. > > In order for you to do what you want you will need some expensive frame > lock hardware with external syncs to run at a multiple of the frame > rate. > > -----Original Message----- > From: osg-users-boun...@lists.openscenegraph.org > [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of > Giovanni Ferrari > Sent: Wednesday, June 23, 2010 3:28 AM > To: osg-users@lists.openscenegraph.org > Subject: [osg-users] OSG and vsync > > Hi, > > i'm developing an application that need vsync to avoid tearing but i'm > having some problems. > Here is the (really simplified) code structure of my application: > > > Code: > > ... > while ( !mViewer->done() ) { > mGraph->Update(...); > mViewer->frame(); > } > > > > > > I've noticed frame() function is blocking when vsync is enabled. > This means that i call the frame function, i stay blocked for something > like 20ms (50hz PAL), and then i must terminate the Update call in the > vsync period otherwise i won't be able to draw a new frame ( the graphic > card draw the old content of frame buffer without changes performed in > the update function. Changes will be performed in the next frame ). > > As you can immagine this is a big problem for real-time applications > cause i'm introducing 20ms of retard. > > Is there a way to syncronize frame call without using vsync ? or can i > scompose the frame function to be able to separate functions that > operate on the graph from those that perform the rendering ? > The second solution could help me cause i would be able to operate on > the graph with mGraph->Update(...) even if the frame "part" that write > the frameBuffer is blocked. > > I hope i've explained my problem clearly. > > Thank you! > > Cheers, > Giovanni > > ------------------ > Read this topic online here: > http://forum.openscenegraph.org/viewtopic.php?p=29295#29295 > > > > > > _______________________________________________ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or > g > Classification: UNCLASSIFIED > Caveats: FOUO > > > _______________________________________________ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > _______________________________________________ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > _______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org _______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
