Pretty well all the examples in the distribtion are capable running multi-threaded multi-pipe out of the box, I run this way on my dual core, dual graphics card system every day. There is also the database pager which is designed from the ground up to work in a background thread.
The design is such that the updating of the main scene graph is all done single threaded, with a thread per camera running cull-draw pairs in parallel. The database pager works on a seperate subgraph, and when ready merges it with the main scene graph during the update phase. All this is done safely with all the criticial parts syncronized to prevent threading issues.
Now if you a question about general thread safety its a different story, the OSG is very much not thread safe in a totally general purpose way, and we'd be made to try and implement such a scheme as it would totally kill performance having to mutex lock practically all ops on the scene graph.
So if you say what type of operations you want to do in parallel and we'll be able to tell you if that'll fit nicely or you'll need to refactor.
Robert.
Hello everyone,
I just read a message in the archives from 2004 about how to protect the scene graph from external threads. In my application, all heavy computational work is done in another thread than OSG and I want to modify the scene graph asynchronously. You mentionned two solutions : locking the whole tree between frame() and sync() or having a copy of the tree and apply changes when it is appropriate. While the first approach is really bad for performance since the modifying threads will have to wait the end of each frame for every updates, the second one can also be very expensive if the scene graph is large. The compromise solution would be to keep a copy of the data into each node and only apply changes to a specific node when it is appropriate instead of the whole tree at every frame. I know there is still the problem of hierarchy changes (if the parent or children of a node are changed) but it would be easy to do so for states and attributes. I was wondering if this stuff has been done since 2004. If not, I can still do it on a higher level by keeping 2 copies of each displayed node into a group but I think it would be better if the low level code was doing that itself ! I just wanted to know if it was done before doing it myself.
In fact, all this message was only for a simple question : is OSG has been modified in any way to be threadsafe since 2004 ? Is that a feature you want to include in the future ? I understand that it is not necessary to do so if the application is controlled entirely by OSG but it could be interesting to have a threadsafe scene graph for external modules (and threads) integration.
Thanks for your time !
Best regards,
Frederic Drolet
_______________________________________________
osg-users mailing list
[email protected]
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
_______________________________________________ osg-users mailing list [email protected] http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
