Hi Paul Jason,
On Fri, Apr 9, 2010 at 1:49 AM, Jason Daly jd...@ist.ucf.edu wrote:
As you indicated, it seems to be hard-coded at the moment. There doesn't
seem to be any way to configure it from the application. You'll have to
either change the hard-coded values in your copy of OSG, or
Robert Osfield wrote:
It's been my plan to revise the way that thread affinity is set up
with the OSG to allow user customization of thread affinity, this
would either have to be done by setting up the GraphicsContext::Traits
and to give hints the DatabasePager prior to the threads starting, or
paul1492 wrote:
Where do I find information on the various threading models of OSG?
I'm using OSG 2.6 and have a custom CullVisitor which handles processing of a
custom node. What can I do within a CullVisitor? Does it need to be thread
safe? Can I update a texture or MatrixTransform
Paul Palumbo wrote:
Any help would be appreciated. I've been fighting with this for many weeks now
and getting nowhere.
I also have a real-time application (using RedHawk Linux) which is doing other things
besides OSG stuff. I tried to shield and set the affinity of my other processes but
Where do I find information on the various threading models of OSG? Also, is
there an easy way to determine what threading model OSG has selected for me?
I'm using OSG 2.6 and have a custom CullVisitor which handles processing of a
custom node. I seem to be getting random segmentation faults
Hi Glenn,
I don't know the answer to why this is happening. Could you try the
same app on another machine with a different graphics driver/hardware
and see what you observe.
As for the stats saying DrawThreadsPerContext - this is almost
certainly means that you are running in
Hi everyone, I am noticing something strange with osgviewer.
When I start up osgviewer (with any old terrain model), and turn on the
stats, I see DrawThreadPerContext mode with an unusually long draw time. In
one case, it's 22 ms and pretty much pegging one of my cores. If I cycle
though the
7 matches
Mail list logo
