OpenSceneGraph Forum Forum Index OpenSceneGraph Forum
Official forum which mirrors the existent OSG mailing lists. Messages posted here are forwarded to the mailing list and vice versa.
 
   FAQFAQ    SearchSearch    MemberlistMemberlist    RulesRules    UsergroupsUsergroups    RegisterRegister 
 Mail2Forum SettingsMail2Forum Settings  ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 
   AlbumAlbum  OpenSceneGraph IRC ChatOpenSceneGraph IRC Chat   SmartFeedSmartFeed 

OpenThreads/pthreads & OpenMP on RHEL5.2

Goto page 1, 2  Next
 
Post new topic   Reply to topic    OpenSceneGraph Forum Forum Index -> General
View previous topic :: View next topic  
Author Message
Robert Osfield
Guest





PostPosted: Mon Oct 13, 2008 6:46 pm    Post subject:
OpenThreads/pthreads & OpenMP on RHEL5.2
Reply with quote

Hi Ralf,

I haven't seen a problem like this reported before. The OSG itself
does run multi-threaded and make use of multi-processors, but I have
never played with OpenMP so can't vouche that there isn't some
potential issue with mixing the two - it does surprise me though. The
affinity functions are there to just set the affinity of a particular
thread with a particular processor, it shouldn't affect threading
beyond this.

Robert.

On Mon, Oct 13, 2008 at 6:07 PM, Ralph R. Peters <> wrote:
Quote:
Hello,

I am trying to use OpenMP inside an application that uses OpenSceneGraph.
I can get OpenMP to use multiple threads inside my examples, but NOT inside
my my OpenSceneGraph app. I think that I may have tracked the problem down
to the use of sched_setaffinity inside files in .../OpenThreads/pthreads.
It seems that inside CMakelists.txt in that directory,
pthread_setaffinity_np is not being found and sched_setaffinity calls are
being made that kill multi-processor availability. From CMakeLists.txt:

CHECK_FUNCTION_EXISTS(pthread_setaffinity_np HAVE_PTHREAD_SETAFFINITY_NP)
IF(HAVE_PTHREAD_SETAFFINITY_NP)
ADD_DEFINITIONS(-DHAVE_PTHREAD_SETAFFINITY_NP)
ELSE(HAVE_PTHREAD_SETAFFINITY_NP)
CHECK_CXX_SOURCE_COMPILES("
#include <sched.h>
int main() {
cpu_set_t cpumask;
sched_setaffinity( 0, sizeof(cpumask), &cpumask );
return 0;
}" HAVE_THREE_PARAM_SCHED_SETAFFINITY)
IF(HAVE_THREE_PARAM_SCHED_SETAFFINITY)
ADD_DEFINITIONS(-DHAVE_THREE_PARAM_SCHED_SETAFFINITY)
ELSE(HAVE_THREE_PARAM_SCHED_SETAFFINITY)
CHECK_CXX_SOURCE_COMPILES("
#include <sched.h>
int main() {
cpu_set_t cpumask;
sched_setaffinity( 0, &cpumask );
return 0;
}" HAVE_TWO_PARAM_SCHED_SETAFFINITY)
IF(HAVE_TWO_PARAM_SCHED_SETAFFINITY)
ADD_DEFINITIONS(-DHAVE_TWO_PARAM_SCHED_SETAFFINITY)
ENDIF(HAVE_TWO_PARAM_SCHED_SETAFFINITY)
ENDIF(HAVE_THREE_PARAM_SCHED_SETAFFINITY)
ENDIF(HAVE_PTHREAD_SETAFFINITY_NP)

so I see:
[hopper@babs src]$ find . -exec grep -n -H sched_setaffinity {} \;
./OpenThreads/pthreads/CMakeLists.txt:73: sched_setaffinity( 0,
sizeof(cpumask), &cpumask );
./OpenThreads/pthreads/CMakeLists.txt:83: sched_setaffinity( 0, &cpumask );
./OpenThreads/pthreads/PThread.c++:135: sched_setaffinity( 0,
sizeof(cpumask), &cpumask );
./OpenThreads/pthreads/PThread.c++:137: sched_setaffinity( 0,
&cpumask );
./OpenThreads/pthreads/PThread.c++:549: sched_setaffinity( 0,
sizeof(cpumask), &cpumask );
./OpenThreads/pthreads/PThread.c++:551: sched_setaffinity( 0,
&cpumask );
./OpenThreads/pthreads/PThread.c++:984: sched_setaffinity( 0,
sizeof(cpumask), &cpumask );
./OpenThreads/pthreads/PThread.c++:986: sched_setaffinity( 0,
&cpumask );
./OpenThreads/pthreads/GNUmakefile:43:ifeq
($(COMPILE_USING_TWO_PARAM_sched_setaffinity),yes)
./OpenThreads/pthreads/GNUmakefile:44:DEF +=
-DCOMPILE_USING_TWO_PARAM_sched_setaffinity

I am compiling this myself with GCC 4.3.2 (that I also compile myself), so I
am not out-of-date with my compiler.

What do I need to do to get this working? Must I run on only a single
processor? I have an 8 processor PC and huge jobs to run on it.
My app also must run in windows (sigh). Will the MS Visual Studio 2005
compiler be a problem?


Ralph







------------------
Post generated by Mail2Forum
Back to top
Robert Osfield
Guest





PostPosted: Tue Oct 14, 2008 4:47 pm    Post subject:
OpenThreads/pthreads & OpenMP on RHEL5.2
Reply with quote

HI Ralf,

Could you please keep your posts on the same thread so it makes it
possible for others to follow, there are a great many posts that get
posted on osg-users and unless you keep to the thread basically it
becomes unmanageable for us to follow things.

And when you say Hi... and he disagress with you, who do you mean
here? Please make your posts human readable as if you want
assistance on any on this topics then you need others to be able to
follow easily.

Robert.

On Tue, Oct 14, 2008 at 5:25 PM, Ralph R. Peters <> wrote:
Quote:
Hi,

I spent some time talking to jakub who runs the gcc forum and he disagrees
with you. A digest follows of our exchanges and a link to the entire
thread.

A related problem may be that the test for pthread_setaffinity_np fails in
CMake. See my second post from yesterday.

Ralph



Initially, I sent email to . The entire thread may
be found at:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37586

After a number of emails jakub responded:

************************************************************************* (A
strace -f -e sched_getaffinity dump by me yielded the following:

jakub responded:

sched_getaffinity(3502, 128, { ff, 0, 0, 0 }) = 32
....
sched_getaffinity(3502, 128, { 1, 0, 0, 0 }) = 32
...
sched_getaffinity(3502, 128, { 1, 0, 0, 0 }) = 32

Shows that the process originally was bound to any of the 8 CPUs (mask
0xff),
but after a while it got confined only to the first CPU. The question is
what
has done that. You can look for sched_setaffinity syscall in the strace
dump,
then either from the surrounding syscalls or under debugger find out where
sched_setaffinity or pthread_setaffinity_np functions have been called from
or if the program invokes the syscall directly, without calling a
libc/libpthread function.

****************************************************************************
I responded:
Hi Jakub,

I did as you asked and get:

sched_setaffinity(24094, 128, { 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0 }) = 0

Its buried in other "startup" code:

..............................
NOTE: usg::Scene using usg default data file path list

path =
.:/usr/local/share/OpenSceneGraph/data:/usr/local/share/OpenSceneGraph/data/Env:/usr/local/share/OpenSceneGraph/data/fonts:/usr/local/share/OpenSceneGraph/data/Images:/usr/share/OpenSceneGraph/data:/usr/share/OpenSceneGraph/data/Env:/usr/share/OpenSceneGraph/data/fonts:/usr/share/OpenSceneGraph/data/Images

camera number: 0

sched_setaffinity(24094, 128, { 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0 }) = 0

INFO> navigation mode set to umbra

Warning: font file "fonts/arial.ttf" not found.

Setting savConfigCB to '::guiWrapper saveConfig'

sLoadFile filename:/home/vision_data/geometry_objects/test.cdf fileType:
lineRowCnt=-1 lineColCnt=-1

std::string UmbModCDFDataSet::LoadFile(const s......
...................................

I suppose that this means that something in Tcl, OpenScenegraph, umbra, my
own rwm is setting the following software to run on only one processor. I
ran a strace -f to get a full "dump" and found that it occurs between 2
"open(library)" calls. I backtracked to OpenSceneGraph to find one
possibility:

[hopper@babs src]$ pwd

/usr/local/src/OpenSceneGraph-2.4.0/src

[hopper@babs src]$ find . -exec grep -n -H sched_setaffinity {} \;

./OpenThreads/pthreads/CMakeLists.txt:73: sched_setaffinity( 0,
sizeof(cpumask), &cpumask );

./OpenThreads/pthreads/CMakeLists.txt:83: sched_setaffinity( 0, &cpumask );

./OpenThreads/pthreads/PThread.c++:135: sched_setaffinity( 0,
sizeof(cpumask), &cpumask );

./OpenThreads/pthreads/PThread.c++:137: sched_setaffinity( 0,
&cpumask );

./OpenThreads/pthreads/PThread.c++:549: sched_setaffinity( 0,
sizeof(cpumask), &cpumask );

./OpenThreads/pthreads/PThread.c++:551: sched_setaffinity( 0,
&cpumask );

./OpenThreads/pthreads/PThread.c++:984: sched_setaffinity( 0,
sizeof(cpumask), &cpumask );

./OpenThreads/pthreads/PThread.c++:986: sched_setaffinity( 0,
&cpumask );

./OpenThreads/pthreads/GNUmakefile:43:ifeq
($(COMPILE_USING_TWO_PARAM_sched_setaffinity),yes)

./OpenThreads/pthreads/GNUmakefile:44:DEF +=
-DCOMPILE_USING_TWO_PARAM_sched_setaffinity

[hopper@babs src]$

This looks like a possibility for the source of my problem or not?
Can I make my own call to sched_setaffinity? There is, of course, always
the possibility of causing problems.

Ralph

***************************************************************************
jakub responded:

-
------ Comment #9 from jakub at gcc dot gnu dot org 2008-10-13 17:52
-------
Yes, that certainly is the source of your problems. You could call
sched_setaffinity or pthread_sched_setaffinity in your program before
entering
an OpenMP region, guess you should also find out why does that library
confine
the thread to just one CPU.
Anyway, closing this, as it clearly is not a GCC/libgomp bug.
***************************************************************************







------------------
Post generated by Mail2Forum
Back to top
Ralph R. Peters
Guest





PostPosted: Tue Oct 14, 2008 5:22 pm    Post subject:
OpenThreads/pthreads & OpenMP on RHEL5.2
Reply with quote

Hi Robert,

I get an email digest and so I have been responding "directly" with
thunderbird. What should I put in the "subject" line so that I maintain
the thread? Is what I put above sufficient? Please tell me what to do!

Yes, my last post was really long!!! :-[

I was trying to provide as much information as I thought that you would
need to understand the problem and overdid it.

Essentially, jakub (at the gcc forum) thinks that the sched_setaffinity
calls are causing the problem. I don't know if he is correct -- I am
just trying to solve a problem.

Questions? Drop me a note!
Ralph




------------------
Post generated by Mail2Forum
Back to top
Robert Osfield
Guest





PostPosted: Tue Oct 14, 2008 5:49 pm    Post subject:
OpenThreads/pthreads & OpenMP on RHEL5.2
Reply with quote

HI Ralf,

On Tue, Oct 14, 2008 at 6:21 PM, Ralph R. Peters <> wrote:
Quote:
Hi Robert,

I get an email digest and so I have been responding "directly" with
thunderbird. What should I put in the "subject" line so that I maintain the
thread? Is what I put above sufficient? Please tell me what to do!

Add a "Re:" in front of the original subject.

You might just fine it easier to disable the digest and set
thunderbird to thread things automatically for you.

Robert.


------------------
Post generated by Mail2Forum
Back to top
Ralph R. Peters
Guest





PostPosted: Wed Oct 15, 2008 3:14 pm    Post subject:
OpenThreads/pthreads & OpenMP on RHEL5.2
Reply with quote

Hi,

I will try to be much more concise! Smile

The problem appears to be that
SetProcessorAffinityOfCurrentThread(unsigned int cpunum) is always being
called with a cpunum value of zero. More information follows.

I am trying to use OpenMP with an application that uses OpenScenGraph.
When OpenMP runs it says that there is only 1 CPU available on an 8
processor PC.

After numerous exchanges with jakub (thread may be found at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37586), it appears that a
call to sched_setaffinity, or its "wrapper" pthread_setaffinity_np, is
setting the number of processors available to 1 on my PC.

After a fair amount of looking around, I dug deep into OpenSceneGraph
software and found 3 instances in
OpenSceneGraph-2.4.0/src/OpenThreads/pthreads/ PThread.c++ where calls
of this sort are being made. I put printouts in those places to check
on what is going on. I found that only one call to
pthread_setaffinity_np was being run in
SetProcessorAffinityOfCurrentThread(unsigned int cpunum) -- see below.
A short code fragment from SetProcessorAffinityOfCurrentThread follows
which shows my printout.

#if defined(HAVE_PTHREAD_SETAFFINITY_NP)
std::cout << "SetProcessorAffinityOfCurrentThread cpunum=" <<
cpunum << " sizeof(cpumask)=" << sizeof(cpumask) << std::endl;
pthread_setaffinity_np( pthread_self(), sizeof(cpumask), &cpumask);
#elif defined(HAVE_THREE_PARAM_SCHED_SETAFFINITY)
sched_setaffinity( 0, sizeof(cpumask), &cpumask );
#elif defined(HAVE_TWO_PARAM_SCHED_SETAFFINITY)
sched_setaffinity( 0, &cpumask );
#endif
#endif

If I use strace -f -e sched_setaffinity to watch what is happening with
sched_setaffinity I see (partial output listing follows):

NOTE: usg::Scene using usg default data file path list
path =
.:/usr/local/share/OpenSceneGraph/data:/usr/local/share/OpenSceneGraph/data/Env:/usr/local/share/OpenSceneGraph/data/fonts:/usr/local/share/OpenSceneGraph/data/Images:/usr/share/OpenSceneGraph/data:/usr/share/OpenSceneGraph/data/Env:/usr/share/OpenSceneGraph/data/fonts:/usr/share/OpenSceneGraph/data/Images
camera number: 0
SetProcessorAffinityOfCurrentThread cpunum=0 sizeof(cpumask)=128
sched_setaffinity(16718, 128, { 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0 }) = 0
INFO> navigation mode set to umbra

which seems to imply that the call pthread_setaffinity_np with zero
processors is causing a problem.

I looked for calls to this function and found the following which
explains why cpunum is zero!
../src/osgViewer/ViewerBase.cpp:137:
OpenThreads::SetProcessorAffinityOfCurrentThread(0);
../src/osgViewer/ViewerBase.cpp:452:
OpenThreads::SetProcessorAffinityOfCurrentThread(0);

What do you, particularly Robert, think? (More information concerning
my PC is available.) How can we fix this? I am quite happy to run some
experiments to figure this out.

Ralph





------------------
Post generated by Mail2Forum
Back to top
Robert Osfield
Guest





PostPosted: Wed Oct 15, 2008 3:27 pm    Post subject:
OpenThreads/pthreads & OpenMP on RHEL5.2
Reply with quote

Hi Ralf,

SetProcessorAffinityOfCurrentThread(0) is just setting the affinity of
thread to cpu number 0, this is a perfectly normal reasonable setting,
it in itself is nothing to worry about, the main rendering thread
being assigned to cpu number 0 is exactly what you want for most apps.

What the other threads are being assinged to depends upon the
existance of other threads. What is your viewer setup? How many
GraphicsContext/Camera's, and what threading model?

Also what value does OpenThreads::GetNumberOfProcessors() return?

Robert.

On Wed, Oct 15, 2008 at 4:14 PM, Ralph R. Peters <> wrote:
Quote:
Hi,

I will try to be much more concise! Smile
The problem appears to be that SetProcessorAffinityOfCurrentThread(unsigned
int cpunum) is always being called with a cpunum value of zero. More
information follows.

I am trying to use OpenMP with an application that uses OpenScenGraph. When
OpenMP runs it says that there is only 1 CPU available on an 8 processor PC.

After numerous exchanges with jakub (thread may be found at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37586), it appears that a call
to sched_setaffinity, or its "wrapper" pthread_setaffinity_np, is setting
the number of processors available to 1 on my PC.

After a fair amount of looking around, I dug deep into OpenSceneGraph
software and found 3 instances in
OpenSceneGraph-2.4.0/src/OpenThreads/pthreads/ PThread.c++ where calls of
this sort are being made. I put printouts in those places to check on what
is going on. I found that only one call to pthread_setaffinity_np was being
run in SetProcessorAffinityOfCurrentThread(unsigned int cpunum) -- see
below. A short code fragment from SetProcessorAffinityOfCurrentThread
follows which shows my printout.

#if defined(HAVE_PTHREAD_SETAFFINITY_NP)
std::cout << "SetProcessorAffinityOfCurrentThread cpunum=" << cpunum
<< " sizeof(cpumask)=" << sizeof(cpumask) << std::endl;
pthread_setaffinity_np( pthread_self(), sizeof(cpumask), &cpumask);
#elif defined(HAVE_THREE_PARAM_SCHED_SETAFFINITY)
sched_setaffinity( 0, sizeof(cpumask), &cpumask );
#elif defined(HAVE_TWO_PARAM_SCHED_SETAFFINITY)
sched_setaffinity( 0, &cpumask );
#endif
#endif

If I use strace -f -e sched_setaffinity to watch what is happening with
sched_setaffinity I see (partial output listing follows):

NOTE: usg::Scene using usg default data file path list
path =
.:/usr/local/share/OpenSceneGraph/data:/usr/local/share/OpenSceneGraph/data/Env:/usr/local/share/OpenSceneGraph/data/fonts:/usr/local/share/OpenSceneGraph/data/Images:/usr/share/OpenSceneGraph/data:/usr/share/OpenSceneGraph/data/Env:/usr/share/OpenSceneGraph/data/fonts:/usr/share/OpenSceneGraph/data/Images
camera number: 0
SetProcessorAffinityOfCurrentThread cpunum=0 sizeof(cpumask)=128
sched_setaffinity(16718, 128, { 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0 }) = 0
INFO> navigation mode set to umbra

which seems to imply that the call pthread_setaffinity_np with zero
processors is causing a problem.

I looked for calls to this function and found the following which explains
why cpunum is zero!
../src/osgViewer/ViewerBase.cpp:137:
OpenThreads::SetProcessorAffinityOfCurrentThread(0);
../src/osgViewer/ViewerBase.cpp:452:
OpenThreads::SetProcessorAffinityOfCurrentThread(0);

What do you, particularly Robert, think? (More information concerning my PC
is available.) How can we fix this? I am quite happy to run some
experiments to figure this out.

Ralph






------------------
Post generated by Mail2Forum
Back to top
Robert Osfield
Guest





PostPosted: Wed Oct 15, 2008 3:51 pm    Post subject:
OpenThreads/pthreads & OpenMP on RHEL5.2
Reply with quote

Hi Ralf,

As a sanity test I've just added some debug code into
src/osgViewer/ViewerBase.cpp and src/OpenThreads/pthreads/PThead.c++
to track what cpu numbers as being assigned from the viewer, and what
is being recieved by OpenThreads, running osgwindow cow.osg I get:

numProcessors = 4
cpunum=1
cpunum=2
cpunum=3
cpunum=0
running and setting thread 0x737238 for cpunum=3
running and setting thread 0x737638 for cpunum=0
running and setting thread 0x734bf8 for cpunum=1
running and setting thread 0x736de8 for cpunum=2

So all looks correct in terms of num of processors and cpu number
assigned for affinity.

Could you please do such a test at your end, without OpenMP confusing
things. Once you have this santity test that confirms that the basic
affinity functionality is working on the OpenThreads/osgVIewer side
then throw OpenMP into the mix.

Robert.


------------------
Post generated by Mail2Forum
Back to top
Robert Osfield
Guest





PostPosted: Wed Oct 15, 2008 3:59 pm    Post subject:
OpenThreads/pthreads & OpenMP on RHEL5.2
Reply with quote

On Wed, Oct 15, 2008 at 4:46 PM, Robert Osfield
<> wrote:
Quote:
Hi Ralf,

As a sanity test I've just added some debug code into
src/osgViewer/ViewerBase.cpp and src/OpenThreads/pthreads/PThead.c++

Attached is the files I modified to get the debug output.

Robert.



------------------
Post generated by Mail2Forum
Back to top
Csaba Halász
Guest





PostPosted: Wed Oct 15, 2008 4:12 pm    Post subject:
OpenThreads/pthreads & OpenMP on RHEL5.2
Reply with quote

On Wed, Oct 15, 2008 at 5:46 PM, Robert Osfield
<> wrote:
Quote:

numProcessors = 4
cpunum=1
cpunum=2
cpunum=3
cpunum=0
running and setting thread 0x737238 for cpunum=3
running and setting thread 0x737638 for cpunum=0
running and setting thread 0x734bf8 for cpunum=1
running and setting thread 0x736de8 for cpunum=2

So all looks correct in terms of num of processors and cpu number
assigned for affinity.

I wonder why OSG assigns threads to cpus by itself and not rely on the
operating system. Or at least have a switch to disable this behaviour.
Suppose I have 3 cameras and 2 contexts, that could mean 5 threads
each with different cpu needs. How does OSG know what threads to put
on the same cpu? All I see is a simple round-robin distribution.
Am I missing something? Is this affinity possibly just a hint rather
than an enforced constraint, so threads might run on other cpus too?

--
Csaba


------------------
Post generated by Mail2Forum
Back to top
Robert Osfield
Guest





PostPosted: Wed Oct 15, 2008 4:16 pm    Post subject:
OpenThreads/pthreads & OpenMP on RHEL5.2
Reply with quote

Hi Csaba,

On Wed, Oct 15, 2008 at 5:07 PM, Csaba Halász <> wrote:
Quote:
Quote:
So all looks correct in terms of num of processors and cpu number
assigned for affinity.

I wonder why OSG assigns threads to cpus by itself and not rely on the
operating system.

Because a OS will let that thread move from core to core and destroy
cache coherency and with it most or sometimes all the performance
benefit of going multi-threaded. Setting thread affinity is *crucial*
to getting good multi-threaded performance.

Robert.


------------------
Post generated by Mail2Forum
Back to top
Csaba Halász
Guest





PostPosted: Wed Oct 15, 2008 4:31 pm    Post subject:
OpenThreads/pthreads & OpenMP on RHEL5.2
Reply with quote

On Wed, Oct 15, 2008 at 6:15 PM, Robert Osfield
<> wrote:
Quote:
Hi Csaba,

On Wed, Oct 15, 2008 at 5:07 PM, Csaba Halász <> wrote:
Quote:
Quote:
So all looks correct in terms of num of processors and cpu number
assigned for affinity.

I wonder why OSG assigns threads to cpus by itself and not rely on the
operating system.

Because a OS will let that thread move from core to core and destroy
cache coherency and with it most or sometimes all the performance
benefit of going multi-threaded. Setting thread affinity is *crucial*
to getting good multi-threaded performance.

But if OSG happens to force 2 cpu intensive threads to the same core,
performance will suffer anyway, and more than a simple cache
efficiency issue.
I have 3 cameras, two of which are using the same graph and a third
that's drawing GUI elements. As such this third one is much less cpu
intensive. So depending on what order they get instantiated the two
"main" cameras might end up on the same cpu while the other cpu is
bored to death with the GUI camera. (I have dual-core machine)

As a related question, in the stats display if multiple cpus are used
properly, should that manifest itself as overlapping bars? Because I
don't see any such, the different phases (draw, cull) for the cameras
all appear to be run after each other. I am now building osg with your
debug modifications, to see if that tells me something.

--
Csaba


------------------
Post generated by Mail2Forum
Back to top
Robert Osfield
Guest





PostPosted: Wed Oct 15, 2008 4:53 pm    Post subject:
OpenThreads/pthreads & OpenMP on RHEL5.2
Reply with quote

Hi Csaba,

On Wed, Oct 15, 2008 at 5:30 PM, Csaba Halász <> wrote:
Quote:
But if OSG happens to force 2 cpu intensive threads to the same core,
performance will suffer anyway, and more than a simple cache
efficiency issue.
I have 3 cameras, two of which are using the same graph and a third
that's drawing GUI elements. As such this third one is much less cpu
intensive. So depending on what order they get instantiated the two
"main" cameras might end up on the same cpu while the other cpu is
bored to death with the GUI camera. (I have dual-core machine)

The setup in osgViewer does make assumptions about the loading across
cameras and does it best to guess what might be appropriate, but it
won't be perfect for all usages.

My long tmer plan for osg::GraphicsContext::Traits has been to put in
an cpu affinity field into it, and therefore provide users an ability
to explicitly set the affinity. This is just another item on my TODO
list.. Feel free to jump and implement this yourself and submit the
changes. Such as field could be used by users with "awkward" cases
which the defaults don't do well on.

Quote:
As a related question, in the stats display if multiple cpus are used
properly, should that manifest itself as overlapping bars? Because I
don't see any such, the different phases (draw, cull) for the cameras
all appear to be run after each other. I am now building osg with your
debug modifications, to see if that tells me something.

On my quad core system I certain do see overlap. Milage will vary
across hardware, OS and OSG usage.

Robert.


------------------
Post generated by Mail2Forum
Back to top
Ralph R. Peters
Guest





PostPosted: Wed Oct 15, 2008 4:58 pm    Post subject:
OpenThreads/pthreads & OpenMP on RHEL5.2
Reply with quote

Hi Robert,

Would you please send me your modified code and we can run the same code!

Ralph



{snip
Hi Ralf,

As a sanity test I've just added some debug code into
src/osgViewer/ViewerBase.cpp and src/OpenThreads/pthreads/PThead.c++
to track what cpu numbers as being assigned from the viewer, and what
is being recieved by OpenThreads, running osgwindow cow.osg I get:

numProcessors = 4
cpunum=1
cpunum=2
cpunum=3
cpunum=0
running and setting thread 0x737238 for cpunum=3
running and setting thread 0x737638 for cpunum=0
running and setting thread 0x734bf8 for cpunum=1
running and setting thread 0x736de8 for cpunum=2

So all looks correct in terms of num of processors and cpu number
assigned for affinity.

Could you please do such a test at your end, without OpenMP confusing
things. Once you have this santity test that confirms that the basic
affinity functionality is working on the OpenThreads/osgVIewer side
then throw OpenMP into the mix.

Robert.
}






------------------
Post generated by Mail2Forum
Back to top
Csaba Halász
Guest





PostPosted: Wed Oct 15, 2008 5:03 pm    Post subject:
OpenThreads/pthreads & OpenMP on RHEL5.2
Reply with quote

On Wed, Oct 15, 2008 at 6:47 PM, Robert Osfield
<> wrote:
Quote:

On Wed, Oct 15, 2008 at 5:30 PM, Csaba Halász <> wrote:

Quote:
As a related question, in the stats display if multiple cpus are used
properly, should that manifest itself as overlapping bars? Because I
don't see any such, the different phases (draw, cull) for the cameras
all appear to be run after each other. I am now building osg with your
debug modifications, to see if that tells me something.

On my quad core system I certain do see overlap. Milage will vary
across hardware, OS and OSG usage.

Here is what stats I get: http://imagebin.ca/view/lDtnJ9ET.html
I have tried your debugging mods, with the osgcamera example I get the
expected printout:

numProcessors = 2
cpunum=1
cpunum=0
cpunum=1
running and setting thread 0xd91d18 for cpunum=0
running and setting thread 0xcb31c8 for cpunum=1
running and setting thread 0xd1e528 for cpunum=1

With our app (flightgear), however, I don't get any. I might have
messed up the compilation, but do you think there is another code path
to set threading model that could circumvent your prints?
In the meantime, I'll investigate too.

--
Csaba


------------------
Post generated by Mail2Forum
Back to top
Robert Osfield
Guest





PostPosted: Wed Oct 15, 2008 5:04 pm    Post subject:
OpenThreads/pthreads & OpenMP on RHEL5.2
Reply with quote

On Wed, Oct 15, 2008 at 5:58 PM, Ralph R. Peters <> wrote:
Quote:
Would you please send me your modified code and we can run the same code!

I already did, please trace back through the thread.

Robert.


------------------
Post generated by Mail2Forum
Back to top
Display posts from previous:   
Post new topic   Reply to topic    OpenSceneGraph Forum Forum Index -> General All times are GMT
Goto page 1, 2  Next
Page 1 of 2

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You cannot download files in this forum

Similar Topics
Topic Author Forum Replies Posted
No new posts Happy New Year to all OSG Users Chris Hanson General 0 Mon Jan 07, 2019 10:17 am View latest post
No new posts osg-users Digest, Vol 138, Issue 27 Zachary1234 General 0 Tue Jan 01, 2019 1:16 am View latest post
No new posts osg-users Digest, Vol 137, Issue 14 poweruserm@live.com.au General 0 Fri Nov 16, 2018 11:16 pm View latest post
No new posts General Users starting questions in O... A Z General 1 Mon Oct 15, 2018 3:59 am View latest post
No new posts osg-users Digest, Vol 136, Issue 8 jonasydy General 0 Wed Oct 10, 2018 12:40 am View latest post


Board Security Anti Bot Question MOD - phpBB MOD against Spam Bots
Powered by phpBB © 2001, 2005 phpBB Group
Protected by Anti-Spam ACP