HI Andre,
On 2/8/07, André Garneau <[EMAIL PROTECTED]> wrote:
I have started looking at this threading issue yesterday evening and here
are some observations (warning: this is an on-going effort more
investigation is required):
* It looks like there are some threads being orphaned (but not terminated)
in the NVIDIA driver (calling stopThreading() and startThreading()
repeatedly will increase the number of threads belonging to the NVIDIA
driver implementation). The orphaned threads seem to be spinning taking up
valuable CPU cycles (doing this many times will result in a sluggish
system).
Sounds a bit odd, the osgViewer's threading should be decoupled
entirely from the driver, the only thing it'll know about things is
that their are makeCurrent() and releaseContext() being called, unless
everytime there is makeCurrent() isn't kicking off a thread.
Are you able to track all the threads running on the machine? How
certain can you be of their origin? Is there anything we can do to
help identication of which threads are going awol?
* There is a race condition in the Stats handling; pressing the 'S' key
rapidly while "osgviewer cow.osg" is running will result in corruption in
the _attributeMapList structure since the main thread and a graphics thread
are both fighting for cleaning up/using entries in _attributeMapList in the
following case:
Main thread partial call stack:
Stats::setAttribute()
ViewerDoubleBufferedRenderingOperation::cull()
Other graphics thread call stack:
Stats::setAttribute()
ViewerDoubleBufferedRenderingOperation::draw()
The rendering operation object being executed is the same for both threads.
Threading model used is DrawThreadPerContext.
I'll keep looking into this later today to see if I can get more precise
information.
I've spotted this race condition too - the problem with States happens
when in DrawThreadPerContext and
CullThreadPerCameraDrawThreadPerContext, but not in other threading
mods.
The reason for the problem is that the double buffered SceneView means
that view Stats structure is begin written to at the same time as
being read. One solution would be localise the draw stats so they are
attached to the GraphicsContext as well as to the Camera, another
would be to mutex the access to the Stats structure.
There is also a small tweak to the SceneView double buffering w.r.t
FrameStamp that I haven't done yet - currently both SceneView's share
the viewers FrameStamp, but each one really needs its own. This
change may actually make the race condition less likely.
So I wouldn't worry about this particular problem, I can recreate it,
and understand it well enough to fix it... once I get the time :)
Robert.
_______________________________________________
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
