Hi Alfe, Multi-threading is really out of scope of this thread so I suggest you start up a thread about this particular topic. Also please specify viewer usage/OS version/OSG version/hardware available etc.
Robert. On Fri, Jul 18, 2008 at 7:08 PM, Alf Inge Iversen <[EMAIL PROTECTED]> wrote: > 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 >> > [email protected] >> > >> http://lists.openscenegraph.org/listinfo.cgi/osg-users-opensce > negraph.org >> > >> > >> _______________________________________________ >> osg-users mailing list >> [email protected] >> http://lists.openscenegraph.org/listinfo.cgi/osg-users-opensce > negraph.org >> > _______________________________________________ > osg-users mailing list > [email protected] > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
