Hi Robert, We just recently (three weeks ago) upgraded our software to OSG 2.4, and in 2.2 we was not able to get the multithreading work properly. There will still be some time untill we release the new version to our customers as the release has to be synchronized with some other modules.
However, even with multithreading, how can we ensure that the GPU execution is not shifted between the frames? If you see the two images I attached to my previous post, you will see that in the situation with low load, the GPU processing is done on the next frame even if it is more than time enough within current frame. While in the more loaded situation the GPU processing is done on current frame even if it barely is time. We need to be sure that the GPU is executed every frame, and the only way I can think about, is to synchronize the GPU to the vertical sync signal. It is not a good idea to wait until culling is ended, and then trust that there will be time eough to complete the GPU processing within the same frame. Thanks, -Alf Inge Robert Osfield wrote: > > Is there a reason why you are running single threaded? This would the > obvious improvement you could make. > > Robert. > > On Fri, Jul 18, 2008 at 4:54 PM, Alf Inge Iversen > <[EMAIL PROTECTED]> wrote: > > Bob Balfour wrote: > > > >> Why is the GPU now being delayed so much after > >> Draw?? It's almost like the GPU is stuck starting out > there mid-frame? > > > > Hi, > > We are dealing with a problem that looks like a closely > related problem. Though we would prefer a kind of delay after draw: > > > > Our application is a real-time visualization process, and > constant frame rate at 60 Hz is an absolute necessity. Most > of the time the load is not not bigger than 60 Hz should be > well maintained, but we still observe severe glitches in the > visualiation, especially when running a mirror view as a > second channel embedded in the main channel. > > > > Closer investigation (by visually observing the OSG stats, > together with printouts to the console window to detect lost > real-tme position data) shows that even if no datasets are > missing and the computing time is well inside the available > time slot, glitches occur. When observing the stats, we > realized that the execution of the GPU happen to be performed > sometimes within the current frame (see attached image > GPU-early.jpg), sometimes in the next frame (see > GPU-late.jpg). We could not identify why the execution of the > GPU is sometimes postponed. As you see from the images that > even when the load is minimal, the GPU may be postponed. We > observed significant glitches in the visualization at the > moments the execution shifted from one frame to the other or > vice versa. > > > > Some latency can be accepted, so to ensure a stable image, > it should be possible to lock the start of the GPU processing > to the vertical sync. It would then process on data delivered > from the Draw of last frame. This would give a stable image, > in addition to increase the available time for the processing > (full 16 ms for Update, Cull and Draw, and another full 16 ms > for the GPU). > > > > Is there a way to control the execution start time of the > GPU from the application? > > > > > > -Alf Inge > > > > ---------------------------------------- > > Mr. Alf Inge Iversen, VP Engineering > > AutoSim AS, Strandveien 106, 9006 Tromsø > > Visit us at http://www.autosim.no > > > > _______________________________________________ > > osg-users mailing list > > osg-users@lists.openscenegraph.org > > > http://lists.openscenegraph.org/listinfo.cgi/osg-users-opensce negraph.org > > > > > _______________________________________________ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-opensce negraph.org > _______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
