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

Reply via email to