Re: [osg-users] setupViewer() hijacks thread affinity mask.
Hi,
I've run into the same issue:
http://thread.gmane.org/gmane.comp.graphics.openscenegraph.user/52734
I think it might be worthwhile to add the affinity clear code to the
OpenThreads lib.
regards
jp
On 05/11/10 12:00, Anders Backman wrote:
Using OSG 2.8.3 under windows 7 64bit. VS2008.
Hi, we discovered a problem where OSG hijacks the affinity for threading
in void ViewerBase::setUpThreading():
ViewerBase.cpp:
// we'll set processor affinity here to help single
threaded apps
// with multiple processor cores, and using the database pager.
int numProcessors = OpenThreads::GetNumberOfProcessors();
bool affinity = numProcessors1;
if (affinity)
{
OpenThreads::SetProcessorAffinityOfCurrentThread(0);
This means that, IF osg viewer is initialized before an app want to
setup threads, any threads started after that will get affinity(0), that
is stick to one core.
viewer.setupViewer( osg::Viewer::SingleThreaded );
createMyOwnThreads(); // sticks to CPU0.
Just because osg want to run on one thread, does not automatically mean
that all other API:s want to stick to that main CPU.
Any threads that should run on other CPU:s needs to be created BEFORE
osg::viewer is initialized, not always the case.
Assume a thread is created from the keypress of a user?
What we do now is to reset the threadmask after setupViewer is called.
Then we get all the core-usage we want :-)
Just wanted to share the experience.
Keep up the excellent work!
/Anders
--
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
--
This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard.
The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html.
This message has been scanned for viruses and dangerous content by MailScanner,
and is believed to be clean. MailScanner thanks Transtec Computers for their support.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] setupViewer() hijacks thread affinity mask.
Using OSG 2.8.3 under windows 7 64bit. VS2008.
Hi, we discovered a problem where OSG hijacks the affinity for threading
in void ViewerBase::setUpThreading():
ViewerBase.cpp:
// we'll set processor affinity here to help single threaded
apps
// with multiple processor cores, and using the database pager.
int numProcessors = OpenThreads::GetNumberOfProcessors();
bool affinity = numProcessors1;
if (affinity)
{
OpenThreads::SetProcessorAffinityOfCurrentThread(0);
This means that, IF osg viewer is initialized before an app want to setup
threads, any threads started after that will get affinity(0), that is stick
to one core.
viewer.setupViewer( osg::Viewer::SingleThreaded );
createMyOwnThreads(); // sticks to CPU0.
Just because osg want to run on one thread, does not automatically mean that
all other API:s want to stick to that main CPU.
Any threads that should run on other CPU:s needs to be created BEFORE
osg::viewer is initialized, not always the case.
Assume a thread is created from the keypress of a user?
What we do now is to reset the threadmask after setupViewer is called.
Then we get all the core-usage we want :-)
Just wanted to share the experience.
Keep up the excellent work!
/Anders
--
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] setupViewer() hijacks thread affinity mask.
Hi Andreas,
Setting of the processor affinity of threads in osgViewer is something
I'd like to make more configurable, but even with that I still don't
understand when threads created after the viewer can't set their own
affinity. Could you explain why the threads created later can't set
affinity?
Robert.
On Fri, Nov 5, 2010 at 10:00 AM, Anders Backman ande...@cs.umu.se wrote:
Using OSG 2.8.3 under windows 7 64bit. VS2008.
Hi, we discovered a problem where OSG hijacks the affinity for threading
in void ViewerBase::setUpThreading():
ViewerBase.cpp:
// we'll set processor affinity here to help single threaded
apps
// with multiple processor cores, and using the database pager.
int numProcessors = OpenThreads::GetNumberOfProcessors();
bool affinity = numProcessors1;
if (affinity)
{
OpenThreads::SetProcessorAffinityOfCurrentThread(0);
This means that, IF osg viewer is initialized before an app want to setup
threads, any threads started after that will get affinity(0), that is stick
to one core.
viewer.setupViewer( osg::Viewer::SingleThreaded );
createMyOwnThreads(); // sticks to CPU0.
Just because osg want to run on one thread, does not automatically mean that
all other API:s want to stick to that main CPU.
Any threads that should run on other CPU:s needs to be created BEFORE
osg::viewer is initialized, not always the case.
Assume a thread is created from the keypress of a user?
What we do now is to reset the threadmask after setupViewer is called.
Then we get all the core-usage we want :-)
Just wanted to share the experience.
Keep up the excellent work!
/Anders
--
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] setupViewer() hijacks thread affinity mask.
On Fri, Nov 5, 2010 at 10:10 AM, Robert Osfield robert.osfi...@gmail.com wrote: Hi Andreas, Ooopsss... I meant to type Anders :-) ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] setupViewer() hijacks thread affinity mask.
You are excused Rupert, considering you taught me to like Bowmore :-) (seems like a million years ago now). :-) Anyways, it is certainly possible to reset the threading mask. It was just the fact that setupViewer() set this, and then left it locked to one core. The main thread (where setupViewer) then will have this threading mask until someone sets it to something else. As we was not aware of this in setupViewer() it took some debugging to understand why we did not get an even load balancing over our 4 cores. Everything just stuck to one of them (whichever the os decided to select for the app at startup). This was first discovered under linux but was reproducible under windows too. So it should be clearly documented as a sideeffect, or handled in some other manner. /Anders On Fri, Nov 5, 2010 at 11:11 AM, Robert Osfield robert.osfi...@gmail.comwrote: On Fri, Nov 5, 2010 at 10:10 AM, Robert Osfield robert.osfi...@gmail.com wrote: Hi Andreas, Ooopsss... I meant to type Anders :-) ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] setupViewer() hijacks thread affinity mask.
Hi Anders, On Fri, Nov 5, 2010 at 10:26 AM, Anders Backman ande...@cs.umu.se wrote: You are excused Rupert, considering you taught me to like Bowmore :-) (seems like a million years ago now). :-) So did Keneth get liking the Highland Park then? ;-) Anyways, it is certainly possible to reset the threading mask. It was just the fact that setupViewer() set this, and then left it locked to one core. The main thread (where setupViewer) then will have this threading mask until someone sets it to something else. Is it just the main thread affinity setting which is at issue here? Assigning this to CPU 0? One thing in the past I've considering is setting the thread CPU affinity hint via GraphicsContext::Traits. We'd also need a ViewerBase CPU affinity hint as well. Then there is the hint for the DatabasePager of where to place this. I have also wondering about having a static map of OpenThreads::Threads so that users can query what threads are and there CPU affinity so that thread affinities could be chosen at runtime better. This might be over-complicating the issue though. Thoughts? Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] setupViewer() hijacks thread affinity mask.
Hi Anders, What we do now is to reset the threadmask after setupViewer is called. Then we get all the core-usage we want :-) Just curious, could you share the code you use to reset that? Also, since the code that sets the affinity is in ViewerBase::setUpThreading(), I guess each time an app does a stopThreading() and then startThreading(), it would need to be reset. We might be seeing something similar in our apps (at least I think it would explain something I was seeing) so thanks for sharing your findings! Thanks, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
