Hi Paul, I haven't looked at the submission yet but as quick reply it rather sounded to me like you've missed the capability of the osg::BarrierOperation to optionally use a glFlush or glFinish. Changing the barrier operation to use glFinish and selecting it so that it's before swap would achieve what you are suggesting. The only essential change to make this possible would be to add a getEndBarrierOperation() method into ViewerBase.
I do wonder if a hint to osgViewer as to the type of sync to use when setting up threading would be nice - so the user can select that they want to ensure swaps are synced. Robert. On 20 January 2012 21:28, Paul Martz <[email protected]> wrote: > Hi Robert -- > > This is a proposed (strawman, really) fix that fell our of the thread "Frame > syncing over multiple contexts" over in osg-users. > > It seems like what John really needs is for all draw threads to have > completely executed all of their respective OpenGL commands before they > enter the end barrier. That way, when the final thread enters the end > barrier and all threads are released, all their associated OpenGL contexts > will be idle, thus maximizing the probability of simultaneous execution of > the swap commands. > > It seems like the best way to achieve that is to have each thread perform > the following operations: > > 1. Do all their drawing (aka "runOperations") > 2. Issue a glFinish() command. > 3. Enter the end barrier > 4. Swap. > > The attached modified ViewerBase.cpp works for John, but is probably not an > acceptable change. Would you provide us with feedback on how we can make > this change acceptable? (Or, if you like the change as-is, excellent! :-) ) > > The change is twofold: > 1. It causes the existing SwapReadyBarrier to issue a glFinish() command. > 2. It also modifies the thread Operation order to ensure that the threads > are ready to swap *before* entering the end barrier. > > I'm fairly confident that #2 is the right thing to do, but I fear I've > broken something with #1. > > Guidance and advice appreciated, thanks. > > -- > -Paul Martz Skew Matrix Software > http://www.skew-matrix.com/ > > > _______________________________________________ > osg-submissions mailing list > [email protected] > http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org > _______________________________________________ osg-submissions mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
