Hi Jan,
On 8/17/07, Jan Ciger <[EMAIL PROTECTED]> wrote:
> > Try forcing different threading models by using the OSG_THREADING env
> > var, or setting it on the command line. See osgviewer --help and
> > osgviewer --help-env for details.
>
> SingleThreaded seems to work, DrawThreadPerContext hangs often,
> CullDrawThreadPerContext didn't hang on me yet,
> CullThreadPerCameraDrawThreadPerContext hanged. However, as this seems
> to be timing-sensitive, take this test with a grain of salt.
CullThreaPerCameraDrawThreadPerContext hangs on my machine new
machine, so this is something I can reproduce and while I don't know
what the problem is I should be able to fix. DrawThreadPerContext is
100% reliable with my test data/apps on my single core to quad core
systems though which is frustrating as tracking down what problems
might exists become much much harder.
Both CullThreaPerCameraDrawThreadPerContext and DrawThreadPerContext
threading models allow the rendering traversal to run in a parallel
with the update traversal and to do this require the scene graphs
static vs dynamic status to be set appropriately otherwise problems
can occur with objects being modified at the same time as being read.
CullDrawThrreadPerContext is similar to osgProducer/Producer's
ThreadPerCamera when there is one camera per graphics window
(RenderSurface), the general sync of the update vs rendering
traversals is similar, and there is never any overlap between the
rendering traversals and update.
Producer can't handle ThreadPerCamera when there is more than one
camera per graphics window so drops down to SingleThreaded, but in
this case osgViewer's CullDrawThreadPerContext will continue being
multi-threaded so the two will diverge. Also osgProducer when there
is one graphics window will fallback to SingleThreaded automatically
as this typically gives best performance on a single card system.
To get Producer working mult-threaded you need to have multiple
graphics windows each with a single camera, any other combination and
you'll get single threaded. So... in your testing of
osgproducerviewer one your system it might well be just running single
threaded, which is equivalent to osgViewer's running SingleThreaded.
osgViewer is a bit more proactive on threading, and if you have
multiple cores available will opt for DrawThreadPerContext as this
threading model will typically provide the best performance - for my
own tests I get between 20 to 80% performance improvement on big
models. The more CPU limited you are the better the improvement will
be.
>
> >
> >
> > Do the hangs always happen at start up? Or any point during rendering?
>
> No, not always at startup. It usually happens after I move the mouse or
> rotate the object. Sometimes it works for 10-15 seconds and then it the
> motions gets jerky, normal again and the usually hangs.
I wonder if X11 could be the problem. osgViewer manages two
connections per graphics window to the X server, one for the graphics
thread and one for the even thread, this in theory should avoid
conflicts. You could you enable thread safe X11 via XInitThreads. In
src/osgViewer/GraphicsWindowX11.cpp you'll find the follow:
#if 0
if (XInitThreads() == 0)
{
osg::notify(osg::NOTICE) << "Error: XInitThreads() failed.
Aborting." << std::endl;
exit(1);
}
else
{
osg::notify(osg::INFO) << "X11WindowingSystemInterface,
xInitThreads() multi-threaded X support initialized.\n";
}
#endif
Just re-enable the XInitThreads block and see how you get on. This
*shouldn't* be required thanks to using two connects, but perhaps
there is certain circumstances when the X server/windowmanager is
screwing up, or osgViewer::GraphicsWindowX11 introducing the problem.
> > If you could provide a datasets then I could try it out on my system.
> > I have a dual core Althon system and a new quad core Intel system,
> > both right now just have a single card in but I can swap things
> > around.
>
> I can send you the ones I have got from Joan off-list, I hope she is OK
> with that.
I'll download load OpenVRML and test it out.
Robert.
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
