Hi Csaba, On Wed, Oct 15, 2008 at 5:30 PM, Csaba Halász <[EMAIL PROTECTED]> wrote: > 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. > 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. _______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
