Hi Robert,

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).

* 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.

André

-----Message d'origine-----
De : [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] De la part de Robert Osfield
Envoyé : February 8, 2007 8:05 AM
À : osg users
Objet : [osg-users] osgviewer threading model control and stats report

Hi All,

To help speed the process of locking down the multi-threaded stability, and
hopefully provide some generally useful features, I have add two items:

To osgviewer I have addd the command line options (extracted from osgviewer
--help)

Options:
  --CullDrawThreadPerContext   Select CullDrawThreadPerContext
                                             threading model for viewer.
  --CullThreadPerCameraDrawThreadPerContext  Select
 
CullThreadPerCameraDrawThreadPerCo-
                                             ntext threading model for
viewer.
  --DrawThreadPerContext        Select DrawThreadPerContext
                                             threading model for viewer.
  --SingleThreaded                  Select SingleThreaded threading
                                             model for viewer.

This allows you to set the threading model to the one you wish.

Next up to help know which threading model you have at any time I have added
a field to the on screen stats that specifies which threading model is being
used.  So pressing 's' a couple of times will show this.

These changes won't solve any the problems that some users are reporting
with certain OS/hardware configurations, but it will at least give us a bit
more control and feedback on what threading is used at any one time.

The only gotcha is that turning on stats is invoking at
stopThreading/startThreading pair to enable it to add the HUD camera, and
thereby triggering the as yet unresolved crash... Still this doesn't
diminish the usefulness of this feature for the rest  :)

Robert.
_______________________________________________
osg-users mailing list
[email protected]
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/



_______________________________________________
osg-users mailing list
[email protected]
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/

Reply via email to