I appreciate your comments and forwarding my post from osg-users. It is evident from my comments and from Dirk's that there is significant ignorance about each other's work. (Dirk wrote in respons to your comment:
> It also sounds like they haveOSG has multi-processor support through Producer for years )
> multi-processor rendering
I'm not sure where you got that from, especially in light of Don's
answer to my mt-safety post.
It would seem that OpenSG's multi-threading approach attempts to address some of the significant problems with multibufferring.
If I were to take offense, it would only be to the act of posting to a "competitive" list to recruit users over the use of your own software. The rest of my post attempted to address the misconception that somehow osg was missing something because it was not entirely thread-safe.
The subject of "thread safety" is a broad one and presents a lot of challenges. Many of the problems we saw in Performer are addressed both by OpenSG and OSG, but in different manners, it would seem. In fact, OpenSG's approach is not necessarily thread safe, either, it simply uses the concept of buffers (aspects?) to protect the user from changing a scene graph that is being used to cull/render. To truly make it thread safe, by protecting access to data with mutexes, etc, would have the same performance impact we implied on the osg-users list.
I'm certainly open to learning from one another - that is one of the purposes of open source. But I'm not that interested in having "we are better because we are thread safe and you are not" being posted to our list.
-don
On 9/16/06, [EMAIL PROTECTED]
Message: 6
Date: Sat, 16 Sep 2006 05:53:03 -0500
From: Allen Bierbaum <[EMAIL PROTECTED]>
Subject: Re: [Opensg-users] Fwd: [osg-users] Is OSG threadsafe yet?
To: [email protected]
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
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
End of Opensg-users Digest, Vol 4, Issue 36
*******************************************
------------------------------------------------------------------------- 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
