I thought this e-mail thread from the OpenSceneGraph list may be of interest to some of you on this list that have used or currently use both scene graphs.
A little background: An OSG user asked if OSG was thread-safe yet or if there plans to make it so. He was interested in ways to do heavy computational work in other threads and sync with the graph asynchronously. Robert responded that OSG is capable of rendering multi-threaded and can support sychronous (locked) updates to the graph but to make it fully thread safe would kill performance because it would require locks on every op to the scene graph. Dirk then chimed in (see below) saying that OpenSG is threadsafe if he is interested. It looks like Don took offense to this posting and wrote the following description of why a thread-safe scenegraph like OpenSG can't work without suffering significant disadvantages. I know many people have been confused in the past about these issues and how well OpenSG can scale relative to a single-threaded scene graph like OSG. I do *not* want to start any sort of a flamewar here. Far from it, I would like to see if there is anything OpenSG can learn from OSG and to make sure that all of these concerns have been covered by the current design. So without further ado, here is Don's e-mail with my comments... (and please correct me if my comments are inaccurate on OSG or OpenSG) > ---------- Forwarded message ---------- > From: *Don Burns* <[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>> > Date: Sep 15, 2006 8:13 AM > Subject: Re: [osg-users] Is OSG threadsafe yet? > To: osg users <[email protected] > <mailto:[email protected]>> > > No, let's talk about the details here. OpenSG, like other scene graphs > of the past, uses a multi-bufferred approach to effect thread safety. > OpenSceneGraph has avoided this route for the multiple disadvantages of > a multi-buffered system. > > A multi-buffered system requires that there be a buffer for each phase > (Update/Cull/Draw) multiplied by the number of threads. That means that > there is a non-linear relationship between number of threads and numbers > of buffers that need to be allocated. By buffers I mean entire copies > of the scene graph. OpenSG is not Performer. It is important that people understand that OpenSG is not "like other scene graphs of the past". Performer et al had problems. SGI recognized this and created Fahrenheit, Intrinsic recognized this and created Alchemy. OpenSG is built from the ideas of this next-generation of scenegraphs that address multi-threading and extensibility. As I hope all OpenSG users know, the number of buffers used (aspects) is completely independent from the number of phases and number of threads. In most cases OpenSG users probably only use two aspects. One for application updates and one for cull/draw from any number of threads. This design scales linearly (or more precisely, it scales however you want it to since the number of aspects are independent of the application scale). > This has at least three distinct disadvantages: 1) Synchronization of > buffers is complex - Complexity adds more possible pitfals and > overhead. 2) Memory footprint 3) multi-threaded complexity for single > theaded applications - What I mean here is that single threaded > applications get all the complexity of multithreaded applications > whether they want it or not. These are definitely issues that caused major problems with Performer but I think OpenSG solves most of them very nicely. Also keep in mind that these issues only crop up if you use multiple aspects. Unlike Performer, you only pay these costs if you use aspects to multi-thread parts of the application. 1. Buffer synchronization is nearly entirely hidden from users. You just have to call sync/update with the id of the aspect to sync from. Everything else is handled by the field containers automatically. The other nice thing about this is that since it is using a changelist the only cost is the cost of copying the fields that changed. Normally this will be very little data and has effectively no overhead. 2. OpenSG only duplicates the skeleton of the graph so not much memory is consumed. And as we already said it doesn't need a copy per thread so it already scales much better then something like Performer. 3. This one can be a problem. In OpenSG 1.X this only really shows itself to the user in the form of begin/endEdits. With OpenSG 2.0 this will go away. The other place you can see it is the use of .fcd file and the use of a purely reflective core. I find this part to be a strength of OpenSG and it seems that other next-gen scene graphs like Fahrenheit and Intrinsic Alchemy did similar things so I don't think it can be all bad. It is something to try to minimize if possible though. > OSG uses a read-only protection of data on a single copy of the scene > graph for each of the downstream phases. The advantages of this > approach, at least meets the problems of a multi-buffered approach > mentioned above. The one rule that this imposes, is that you cannot > modify the scene graph during the cull/draw phase. What I think this means is that when multi-threads are cull/rendering, just don't touch the graph. > But this is an easy rule to live with. If one really, really needs to > modify the scene graph during this time, it is a simple exercise to > effect double buffering of the scene graph, allowing a separate thread > to work on the buffer that is not being used by cull/draw pairs. Double > buffering is a far cry from Multi-buffering and it retains nearly the > linear scalability of a non-buffered approach. If I understand correctly this is really just the same as using OpenSG with 2 aspects. Use the first aspect for application updates and sync to a second aspect that is used for rendering. > One other disadvantage of a mult-buffered system is increased latency. Latency is only increased if you use multiple stages. If you don't want the latency increase, then just don't use multiple aspects. > I write this to counter the perception that adding full thread safety to > a scene graph is somehow a superior approach. One need only take a few > minutes to try and design a fully thread safe scene graph to realize the > amount of complexity and overhead this introduces. Full thread safety > comes with an expensive cost. OSG was designed purposely the way that > it has been because of the clear advantages of a single copy scene graph. I don't see the clear advantages of a single copy of the graph. I do see that designing a fully thread safe scene graph is more complex, but happily the OpenSG developers figured out a way to do this that scales and hides the details from users. There is some overhead to support this capability but it definitely does not require locking of synchronization for each frame. From what I have seen the overhead boils down to a multiply and add to offset the field container pointers when you access the graph. This doesn't seem like to much overhead to me since it is basically the same thing needed to access an array and is so common that compilers and CPUs probably optimize the operation. In OpenSG 2.0 it will be possible to compile the multi-aspect support out (to support embedded platforms or single-threaded applications) so it should give the best of both worlds. Use multi-aspect if you want it and disable it if you don't. For the cost of this overhead OpenSG gives full thread-safety, simple multi-threading of computation and rendering, and transparent clustering. To me the advantages far outweigh the minor overhead caused. > And, Dirk, I'd be quite happy to post this explanation to opensg-users > if you'd like. I guess I already did. :) So following up this e-mail: - Has anyone used both OSG and OpenSG and run into any of these issues? - Does anyone have any concrete numbers for scalability? - Does anyone have any concrete numbers for overhead? - Are there any ideas for how to address Don's concerns about multi-buffered scenegraphs? -Allen > > -don > > On 9/14/06, *Dirk Reiners* < [EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>> wrote: > > ObPlug: OpenSG is threadsafe. Mail me for details. > > (Sorry, couldn't resist ;) > > Dirk > _______________________________________________ > osg-users mailing list > [email protected] <mailto:[email protected]> > http://openscenegraph.net/mailman/listinfo/osg-users > http://www.openscenegraph.org/ > > > ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Opensg-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/opensg-users
