I forgot to mention that the change applies not only to osg::Timer, but also to Producer::Timer (which is exactly the same code). Changing Producer::Timer to use clock() is what actually fixes the erratic stats display. This applies to OSG 1.2 of course.
I will be happy to submit this change; but I am not using the SVN trunk yet -gw On 3/8/07, Robert Osfield <[EMAIL PROTECTED]> wrote:
Hi Glenn, We used to have a similar option before, then for toggle between using a machine code call to get the processor counter and standard code that probably used clock(), but its a while so I can't recall for sure. The machien code path was abandoned when processors started changing clock frequency on the fly. I'm open to adding back a toggle for the timer implementation, especially if someone else writes it :-) The other avenue to explore is multi-buffering the Timer is some way that manages the QueryPerformanceCounter() from different processes. Robert. On 3/8/07, Glenn Waldron <[EMAIL PROTECTED]> wrote: > A temporary solution may be to simply replace QueryPerformanceCounter() with > clock(). The resolution is less, but a quick search shows that the delta_u() > and delta_n() methods are never used within OSG (1.2). I have tried this and > the problems went away. Of course, any user code that used these methods > would break. > > Perhaps we can enhance osg::Timer to use one implementation or the other > depending on the number of logical CPUs detected? Or let the user override > at startup time by calling a static function, like > osg::Timer::setUseLowResolutionTimer(bool)? -gw > > > On 3/8/07, Robert Osfield <[EMAIL PROTECTED]> wrote: > > Hi Anders, > > > > The OSG support multi-threaded usage, and the time code happens in > > both the main threads and the cull-draw ones, one can't just limit > > timer calls to one thread. Setting process affinity is now supported, > > in particular with osgViewer, but the timer calls are still called > > from different threads, so I don't think this will solve much. > > > > Perhaps one could multi-buffer the Timer so there is one per thread, I > > don't know how we'd go about this, or whether it would work. Is the > > problem that QueryPerformanceCounter()'s base offset changes per core? > > If so the the multi-buffering might work, but... how would you > > syncronize the various buffers so that they all tell the same time? > > > > Clamping times won't really solve anything as the time will still be > > wrong, just not negatively wrong. > > > > Robert. > > > > On 3/7/07, Anders Backman < [EMAIL PROTECTED]> wrote: > > > Is there anyone out there experiencing strange hang and timing problems > on > > > dual CPU/Core/HT windows XP machines? > > > except for the ordinary laptop-timing problems of course ;-) > > > > > > > > > Im currently debugging something that gives me gray hair, and someone > > > suggested that it could be a potential problem coming from the fact that > > > QueryPerformanceCounter() is used (osg::Timer) > > > I have an app that runs just fine for a while (can be 1 minute, > sometimes > > > 30) and then it hangs, and it never occurs in debug-mode (of course!) so > its > > > quite tricky find the cause for it. > > > I have already found one reason for the hangs, and that was in Producer > > > where a OpenGL timer query never returned....But that is fixed (by > skipping > > > after 1000 iterations). > > > > > > > > > It seems to be quite a few developers with this problem when I searched > the > > > web. > > > > > > For example: > > > http://www.virtualdub.org/blog/pivot/entry.php?id=106 > > > > > > It seems that when a thread is moved in and out between different > execution > > > cores/CPU:s it can drop timing or even get negative timing results.... > > > It also talks about hangs (which I guess could be a second order problem > > > that comes from the timing problem). > > > Right now Im looking at something that looks like a hang inside > > > osg::Timer::tick() > > > > > > > > > So is there anyone else experiencing this? > > > > > > > > > There is a bunch of recommendations from MS: > > > > > > > http://msdn.microsoft.com/library/default.asp?url=/library/en-us/directx9_c/Game_Timing_and_Multicore_Processors.asp > > > > > > - using QueryPerformanceCounter from only one thread > > > - setting SetThreadAffinityMask so that the timing thread runs on only > one > > > CPU/Core > > > - clamping the subtraction result so you never get a negative one: > > > > > > inline double delta_s( Timer_t t1, Timer_t t2 ) const { return > > > (double)(t2 - t1)*_secsPerTick; } > > > > > > Should be: > > > > > > inline double delta_s( Timer_t t1, Timer_t t2 ) const { return > > > (double)osg::clampAbove((t2 - t1), 0)*_secsPerTick; } > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > ________________________________________________________________ > > > Anders Backman Email: [EMAIL PROTECTED] > > > HPC2N/VRlab Phone: +46 (0)90-786 > 9936 > > > Umea university Cellular: +46 (0)70-392 > 64 67 > > > S-901 87 UMEA SWEDEN Fax: +46 90-786 6126 > > > > http://www.cs.umu.se/~andersb > > > _______________________________________________ > > > osg-users mailing list > > > osg-users@openscenegraph.net > > > http://openscenegraph.net/mailman/listinfo/osg-users > > > http://www.openscenegraph.org/ > > > > > _______________________________________________ > > osg-users mailing list > > osg-users@openscenegraph.net > > http://openscenegraph.net/mailman/listinfo/osg-users > > http://www.openscenegraph.org/ > > > > > _______________________________________________ > osg-users mailing list > osg-users@openscenegraph.net > http://openscenegraph.net/mailman/listinfo/osg-users > http://www.openscenegraph.org/ > _______________________________________________ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
-- Glenn Waldron : Pelican Mapping : 703-652-4791
_______________________________________________ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
