Hi,
I've stumbled upon the following issue. Our renderer runs
SingleThreaded because that what most Qt integrations seem to use, or
else other issues arise. I'd be happy to change that of course.
This makes the whole application run on just one core. It's still
"multithreaded", as the loa
This is, bizarrely, by design.
In single-threaded mode, OpenSceneGraph silently sets CPU affinity to a single
core by default. Personally I think this is incredibly obtrusive on the
programmer, and the reasons for this being default behaviour are terrible, but
it is what it is.
This is what I
On 23 September 2016 at 05:25, Pete Black wrote:
> This is, bizarrely, by design.
>
> In single-threaded mode, OpenSceneGraph silently sets CPU affinity to a
> single core by default. Personally I think this is incredibly obtrusive on
> the programmer, and the reasons for this being default beha
Thank you so much for pointing this out, Pete. So in
ViewerBase::setUpThreading() osg decides the whole application should be
confined to a single core.
Judging by your comment, this has already been discussed and not deemed
a fault that should be fixed?
Also, I suppose there is no way to i
Hi Robert,
wouldn't it be a better approach to give the user the option to change
such a setting for their application?
But thanks for pointing out the subclassing option, that's what I'll go
for! Still it took me half a day to track down what was going on. (I
didn't suspect OSG in the beg
On 23 September 2016 at 08:42, Christoph Weiss wrote:
> Thank you so much for pointing this out, Pete. So in
> ViewerBase::setUpThreading() osg decides the whole application should be
> confined to a single core.
When running SingleThread the OSG just sets the affinity of the
current thread. Th
Hi Robert,
When running SingleThread the OSG just sets the affinity of the
current thread. That's it, that's all it's doing.
This actually has a very bad side effect that I only noticed now. Since
it explicitly sets the affinity to core zero, any other application that
does so will share i
Hi Chris,
On 23 September 2016 at 09:19, Christoph Weiss wrote:
> This actually has a very bad side effect that I only noticed now. Since it
> explicitly sets the affinity to core zero, any other application that does
> so will share its CPU entirely with it. In particular if you start a
> Sing
> Affinity is set by default because the it will provide the best
> performance for majority of OSG applications. This might be a
> "terrible" reason for you, but the OSG development is motivated not by
> just focusing on one class of users needs or preferences, default
> settings we try to do the
On 09/24/2016 02:18 AM, Pete Black wrote:
I have no particular desire to repeat the last discussion, but i'll say it
again.
Hardcoding CPU affinity is:
a) unexpected
In particular it is not done by some osg::setThreadingModel() but rather
deep down in the call stack by a function that is cal
Hi,
Wow, before this escalates: OSG is setting the affinity for some of its
own threads, which is totally legitimate.And I totally agree, that it
would be nice to have an interface to control the core/wether affinity
is used in single-threaded mode except from having to subclass the viewer.
Hi Pete,
> I have no particular desire to repeat the last discussion, but i'll say it
> again.
But then you'lll throw is some ill-informed and emotive language anyway.
>From my experience of maintaining an open source project for 17 years
is that emotive language is used when people have a tend
OK,
Apologies if I caused offense.
Goodbye.
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=68731#68731
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/
Hi,
> OSG is setting the affinity for some of its own threads, which is totally
> legitimate.
Currently, I was not able to confirm it on my Mac. But I think, I observed such
a behaviour in my application on Linux.
But take it with a grain of salt, as it can be the result of some other side
ef
I wrote a simple sample program that produces the following output:
% g++ -std=c++14 -losgViewer -pthread a.cpp && time ./a.out
Thread 5 done
Thread 9 done
Thread 4 done
Thread 0 done
Thread 6 done
Thread 15 done
Thread 12 done
Thread 13 done
Thread 11 done
Thread 7 done
Thread 8 done
Thread 1 do
Hi,
I can confirm the behaviour with the following test case:
https://github.com/fwiesel/vertexarrayfunctest/blob/threads/main.cpp#L92-L103
All threads run on CPU 0.
That clears up the mystery, which baffled me and two of my colleagues:
After upgrading to a new Ubuntu version, suddenly our applic
Thanks for the example Fabian, I'm away from my desktop system this
weekend, will have a look in the week.
Have you tried setting the affinity of the threads that are created?
Have you tried creating the threads before the call to viewer.realize()?
The way things are behaving looks to be down t
Hi Robert,
> Have you tried setting the affinity of the threads that are created?
> Have you tried creating the threads before the call to viewer.realize()?
Yes, both cause the threads being distributed across the cores. That is
probably also why initialising TBB early in main helps, as it create
HI Fabien,
On 25 September 2016 at 22:52, Fabian Wiesel wrote:
> Yes, both cause the threads being distributed across the cores. That is
> probably also why initialising TBB early in main helps, as it creates a pool
> of worker threads. For my app, you can consider it solved.
> But don't you see
Dear Robert,
On 09/26/2016 09:39 AM, Robert Osfield wrote:
The only "difficulty" is when using a certain usage model when
threading, it's not a general issue. The issue looks to be isolated
to the case where users set up threads after the viewer has been
realized.
This sounds a bit as if this
Hi Christoph,
On 26 September 2016 at 11:01, Christoph Weiss wrote:
> This sounds a bit as if this was a rare thing to do, or at least a design
> choice that can or should be avoided. I think on the contrary, explicit
> thread handling is something that is slowly going to die for many
> applicat
Hi All,
I have taken Christoph's test problem and reproduced the affinity
issue on my Kubuntu 16.04, so this is useful first step.
I've also reviewed the OpenThreads code, so have a better idea of the
code in question. Please note that I'm not the author of OpenThreads,
the project just fell on
Hi Robert,
I
Hi All,
I have taken Christoph's test problem and reproduced the affinity
issue on my Kubuntu 16.04, so this is useful first step.
I've also reviewed the OpenThreads code, so have a better idea of the
code in question. Please note that I'm not the author of OpenThreads,
the pro
Hi Sebastian,
On 26 September 2016 at 12:15, Sebastian Messerschmidt
wrote:
> Would a small function to enable/disable the affinity in SingleThreaded mode
> be a big breaking change? Defaulting to using the affinity mask, making it
> up to the advanced user to sacrifice the performance.
I would
Hi Robert,
If you are using OpenThreads for your threads then you have no problem
at all anyway, you can create them before or after viewer.realizer()
without any problem.
It's only if you create your threads afterwards using another
threading library that doesn't set the affinity mask in any w
HI Christoph,
On 26 September 2016 at 14:20, Christoph Weiss wrote:
> I strongly disagree with the last sentence. It is the most general use case
> possible: using standard C++ features.
Please quite the hyperbole. It does you no favours.
I am been writing C++ programs since 1992, been the p
Hi Robert,
On 09/26/2016 04:35 PM, Robert Osfield wrote:
HI Christoph,
On 26 September 2016 at 14:20, Christoph Weiss wrote:
I strongly disagree with the last sentence. It is the most general use case
possible: using standard C++ features.
Please quite the hyperbole. It does you no favou
HI Christian,
On 26 September 2016 at 15:49, Christoph Weiss wrote:
> Robert, I'm not quite sure what prompts you to bring in personal attributes
> here. Nor do I see any hyperbole to begin with. I stated that I strongly
> disagree. You can in turn disagree. I never was my intention to make t
Hey Robert,
Just let it drop!
Love, Temia
On Mon, 26 Sep 2016 16:38:19 +0100
Robert Osfield wrote:
> HI Christian,
>
> When it comes to perspectives of what is right or wrong for the OSG it
> absolutely has everything to do with my experience. I more than
> anyone else in the community I wit
When reviewing doing a code review of the affinity code in OpenThreads
today I noticed that OpenThreads doesn't fully expose all the
functionality available for setting or resetting the thread affinity,
as OpenThrreads just allowed you to specify a single cpu number for a
thread to have affinity wi
HI Temia,
On 26 September 2016 at 19:41, Temia Eszteri wrote:
> Just let it drop!
Drop what? The project leadership? Doing support for free?
Investigating issues and getting to the bottom of them? If you've
actually followed this thread and read what's been written I've done
far more than ta
Hi all,
I have refined the affinity support in OpenThreads further introducing
an OpenThreads::Affinity class that stores a set of CPU core numbers
that the affinity should be set for, this is then used as input when
setting the the native threading API's CPU affinity mask.
The Affinity class can
Hi All,
I have now implemented the new OpenThreads::Affinity class in Windows,
this is now checked in the the openthreads_affinity_mask branch.
at the same time I spotted a missing feature - I'm not the author of
OpenThreads and hadn't need to touch the Win32 implementation before
so hadn't looke
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::GraphicsConte
Hi Robert,
Thank you very much for spending so much effort on the threading affinity
(re)design. It is very much appreciated.
Christian
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-
35 matches
Mail list logo