[osg-users] SingleThreaded leading to whole application just running on one core

[Robert Osfield]

I have now implemented support for manually setting the Affinity of
the various threads that the viewer manages - so main thread,
camera's, graphics threads and database pager threads.  You'll now can
set these via:

   osg::Camera::setProcessorAffinity(OpenThreads::Affinity);
   osg::GraphicsContext::Traits::setProcessorAffinity(OpenThreads::Affinity);
   osgDB::DatabasePager::setProcessorAffinity(OpenThreads::Affinity);
   osgViewer::Viewer::setProcessorAffinity(OpenThreads::Affinity);

I have also added a ViewerBase::configureAffinity() that sets these up
automatically based on the viewer's combination of threading, cameras,
graphics contexts and database pagers.  These new method does a better
job of setting up affinity that the previous codes as it also handles
the DatabasePager affinity, making sure that the DatabasPager threads
don't sit on any of the other viewer threads. This will be really
helpful for applications that use paged databases as it'll avoid the
possibility of a loader bumping a viewer thread during frame and so
reducing the likelhood of a frame break.

There is also a ViewerBase::setUseConfigureAffinity(bool flag) method
that users can call before ViewerBase::realize() to specify whether
the ViewerBase::setUpThreads() method calls the
ViewerBase::configureAffinity() method.  If you set this property to
false then the setUpThreads() will not call configureAffinity() and
the set up the thread affinity based on the Camera,
GraphicsContext::Traits and DatabasePager's ProcessorAffinity
properties.  By default all the Affinity settings are empty, which
signifies no CPU affinity so the associated threads will run on all
available CPUs.

If you do want to disable the call to configureAffinity() then thread
affinity is entirely in your hands, if you are power user and know
exactly what affinity settings to use for all the threads then it will
be a very useful mode, however, I'd caution on using without due
consideration as you can easily end up with an application that breaks
frame or runs at more erratic and lower frame rate.  For the majority
of users I would recommend just using the defaults and let
configureAffinity() do it's magic.

For those who kicked off this thread, setting setUseConfigureAffinity
to false with the ViewerBase's ProcessorAffinity left as default will
mean the main thread will be told to run on all available CPU's so any
threads you set up after the viewer realize() will now run across all
threads.  This might be what you are asking for... BUT... I would
strongly recommend against this approach.  Not setting affinity in a
highly threaded visualization application will lead to a higher risk
frame drops and  erratic and lower framerates.   The correct thing to
do is have the Viewer use ConfigureAffinty or manually set the
Affinity and then set your additional threads to run on entirely
separate cores so they don't interfere with the rendering and
visa-versa so you end up with a better performing application.

The power and flexibility of handling affinity is now entirely in your
hands if you want, but think twice about it - if you are doing
threading then you really need to understand the topic including the
importance of processor affinity.

All these changes are checked into the openthreads_affinity_mask
branch.  All the functionality is now in place so it's now just a case
of testing it out across various platforms and usage patterns.  There
remains some debugging output to the console that I'll remove once
more testing has been done.  Once things have settled down on this
branch and everything looks good I'll merge it with master so it'll be
part of the up coming OSG-3.6 release.

Robert.



Robert.