-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello,
Robert Osfield wrote: > > 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. CullThreaPerCameraDrawThreadPerContext was always hanging for me, I believe that it may not be related to the problems I am seeing right now. I will try to track the deadlock down from my side. If you cannot reproduce it, it is impossible to fix it. > > 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. I am not setting this. Isn't the dynamic status the default one? But even if it wasn't, I am getting hangs with pure viewer too where nothing is being modified. > 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. OK. > 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. That is possible, and then it means that there is a race condition somewhere. > 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. Yes, that is what I see here too. This mode is the default for me. > 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: > ... > 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. > Thanks for the tip, I am going to test it. Regards, Jan -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD8DBQFGxykan11XseNj94gRAmMxAJ9RWQHxYR4l+fdOjHBzJual6rDnCACeI1vb rVP7qbshRGI4jvfyY15YcqQ= =AojA -----END PGP SIGNATURE----- _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
