Re: [osg-users] Problems using QueryPerformanceCounter()??
Hello Robert et al, I've been out of town for the last week, so haven't seen this thread, but just an FYI... 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. In most cases I've seen, the erratic timer behaviour on multi-core/Hyperthreaded CPUs has been resolved by implementing this fix: http://support.microsoft.com/kb/895980 In short: add the /usepmtimer option to the line that describes the OS you boot in the boot.ini file which is in the root dir of your boot drive. For example, if it reads multi(0)disk(0)rdisk(0)partition(2)\WINDOWS="Windows XP Professional" /fastdetect /NoExecute=OptIn add /usepmtimer like so: multi(0)disk(0)rdisk(0)partition(2)\WINDOWS="Windows XP Professional" /fastdetect /NoExecute=OptIn /usepmtimer Installing the latest CPU driver from AMD or Intel normally applies this fix automatically, but you can check if it's there by opening the boot.ini file in a text editor. I don't know what the fix does at a low level, but it seems to work. Of course, the bad news is that it's a per-installation fix, so you can't implement it once in your code base to prevent new users from coming here to report erratic timer behaviour... So if the changes to osg::Timer you propose don't affect precision in unwanted ways, you might want to do those anyways. Just thought you should know about the MS knowledge base article. J-S -- __ Jean-Sebastien Guay [EMAIL PROTECTED] http://whitestar02.webhop.org/ This message was sent using IMP, the Internet Messaging Program. ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] Problems using QueryPerformanceCounter()??
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 returnedBut 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 Phon
Re: [osg-users] Problems using QueryPerformanceCounter()??
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 returnedBut 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/
>
_
Re: [osg-users] Problems using QueryPerformanceCounter()??
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 returnedBut 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/
Re: [osg-users] Problems using QueryPerformanceCounter()??
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 returnedBut 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/
RE: [osg-users] Problems using QueryPerformanceCounter()??
I've been running OSG1.0 on dual-core HT Pentium D Windows XP machine,
without that problem. (looks like 4 procs). Although, it looks like I
updated to OpenThreads 1.1 (OSG_OP_OT1.1 version of OpenThreads) to fix some
lock up problems. Maybe at the time I was experiencing the same problem?
It is too long ago for me to remember, though, and my CM logs don't tell me
the reason. Is it possible you are not compiling the correct OpenThreads
version?
Zach
_
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Glenn Waldron
Sent: Wednesday, March 07, 2007 14:56
To: osg users
Subject: Re: [osg-users] Problems using QueryPerformanceCounter()??
Anders,
There is a previous discussion on this topic here:
http://openscenegraph.org/archiver/osg-users/2006-March/0252.html
I'm running OSG 1.2 and I still see this problem on dual-core or HT
machines. -gw
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 returnedBut 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
<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
<http://www.cs.umu.se/%7Eandersb>
___
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/
Re: [osg-users] Problems using QueryPerformanceCounter()??
Anders,
There is a previous discussion on this topic here:
http://openscenegraph.org/archiver/osg-users/2006-March/0252.html
I'm running OSG 1.2 and I still see this problem on dual-core or HT
machines. -gw
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 returnedBut 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/
--
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/
[osg-users] Problems using QueryPerformanceCounter()??
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 returnedBut 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/
