Thread Safety

Engines, Libraries and Tools Xith3D Forums
#1

I read this thread where it compared Java3D vs Xith3D vs jME thread: http://www.java-gaming.org/forums/index.php?topic=11748.0
It seems like under certain situations, where the a scene graph can be processed in parallel, Java3D has the best performance because it makes less GL calls, and the calls are alot more efficient, so the detrimental performance of synchronization is overcome.
To me, this seems like the right direction to go, since most computers these days can handle multiple threads fairly well, and it’s only going to get better with multiple cores. As I see it, single threaded-ness will probably be deprecated in applications which require the highest performance, in favor of parallelism.
That said…

If someone such as myself were to make contributions to Xith3D that would allow the scene graph to be accessed in a thread safe manner, would the contributions be acceptable, and what would be the best way of going about doing such a thing?
If wrapper classes were created that make everything synchronized, it would allow it to be more of an extention than a recreation, but it would make lots of the scene graph synchronized, which would probably be very detrimental to performance.
If only parts of the code are synchronized, there probably wouldn’t be as much of a performance penalty, but I’m thinking it wouldn’t be as easy to turn on and off, like a wrapper or decorator would be, which would probably force a fundemental change in Xith3D.
Would using a wrapper/decorator be a better approach? Would this be better done in a project fork? Would thread-safety be readily accepted as a new feature?

I think something should also be done about what someone referred to in the thread as GL duplicate calls. Does anyone else think so aswell? Technically they’re not duplicate, but it seems like everything is one-for-one in Xith, rather than lumping blocks of the same GL calls togher into one where possible. Instead of a scene.compile(), maybe there could be an optional sorting flag when a node is added?

If I were to make these changes/additions, how would I go about submitting them?

#2

Humm… although thread-safety would be a great feature to have, it’s the speciality of Java3D… And I don’t really think it’s needed either now nor in the future.

#3

[quote="<MagicSpark.org [ BlueSky ]>,post:2,topic:26426"]
Humm… although thread-safety would be a great feature to have, it’s the speciality of Java3D… And I don’t really think it’s needed either now nor in the future.
[/quote]
So you’re saying I shouldn’t even bother submitting wrapper classes, and I should probably fork my own project?

#4

Hi,

Thread safety is a quite self-contradicting topic in case of 3D rendering, as well as performance comparison. So let me comment on some points from this post, as well as from that performance comparison post on jME.

Significant performance difference may be caused by outdated version of vecmath.jar used by Xith3D. I personally use vecmath by Kenji Hiranabe with minor changes, and this gives MUCH LESS GC and recognizable performance benefit.

JOGL-oriented version of Xith3D was using Java arrays to store vertex data, which has to be changed to NIO buffers in favor of JOGL-JSR231. This process already started, but there is still some array-to-buffer copying for dynamic geometry, which I bekieve the biggest impact to the performance.

Another significant difference is proper implementation of VBO in Xith3D. Current support of VBO in Xith3D is not quite robust, and we have to turn it off in most cases. I can not say if Java3D 1.4.x is using VBO, but, if yes, it would a give great performance benefit. Xith3D does not use display lists at all, and passes all the gepmetry as vertex arrays. I don’t think we should even think about display lists these days in favor of VBO.

State sorting efficiency mentioned in jME thread is a correct point. Xith3D has more-or-less sofisticated state sorting mechanism, especially for those who want to implement their own state sorting (not pulled up to public APIs, but possible to do).

As of duplicate GL calls, we should speak with specific examples.Time ago I made a test to see if there is a big penalty of duplicate calls if there is no GL state change. That time I found that the difference is minor… maybe drivers changed too much since that time.

Now about synchronization. Sure it is great to make GPU and CPU working in parallel, but there are issues: most of OpenGL drivers go mad when you try to access the same context from difefrent threads (see JOGL forum), so we have single-threaded rendering at the end anyway.

So only thing we can run in parallel is scenegraph change/update routines for next frame (physics etc.) and rendering current one. To implement this, Java3D uses a kind of update event mechanism, so scene de-facto stored twice.

Synchronization itself does not mean thread safety - its performance impact is high mostly not due to expensive entermonitor/exitmonitor JVL-level instructions, but because of one thread is waiting for the other (blocking) while it could run without delay in most cases.

Introducing update event mechanism will mean nearly exact replication of Java3D rendering architecture, but as of my personal experience implementing application-specific CPU/GPU parallelizing is way more efficient than using generalized one, especially for multicore and multiCPU systems.

[quote]If someone such as myself were to make contributions to Xith3D that would allow the scene graph to be accessed in a thread safe manner, would the contributions be acceptable, and what would be the best way of going about doing such a thing?
[/quote]
Sure yes, all contributions to Xith3D are welcome. I persomally think that it MAY be a separate package that has synchronized peers that extend appropriate nodes in main scenegraph. I personally use set of extension classes on top of Xith3D that allow to keep and defer scenegraph updates until the end of frame rendering, so rendering itself is 100% non-synchronized, change generation itself is also non-synchronized and does not interfere with rendering, and after each frame rendered rendering thread updates changed nodes by replacing references only, i.e. with minimum overhead.

Most important, this is done not to achieve high parallelizm (this is a side effect anyway), but for being able to update scenegraph from input processing thread while keeping current frame consistent.

[quote]Would using a wrapper/decorator be a better approach?
[/quote]
Up to implementor. Can be discussed.

[quote]Would this be better done in a project fork?
[/quote]
No, I don’t think so. I think it can go either in the core (I think it should go in the core, because of some core changes are also neccessary I know), or in xith-tk.

[quote]Would thread-safety be readily accepted as a new feature?
[/quote]
As optional feature - yes. But it should be possible to run unsynchronized way too, even more, synchronized classes should be optional if some does not want to use them and put in his own distribution.

[quote]I think something should also be done about what someone referred to in the thread as GL duplicate calls. Does anyone else think so aswell?
[/quote]
As I noted above, I would be happy to have better state sorting, but I would know first what numbers we are speaking about. If this is few percent, then I am not really sure. What we need is a good demo that shows the best of Xith3D because of you know that what is the best for one engine (from the app design) is the worst for the other.

[quote]Technically they’re not duplicate, but it seems like everything is one-for-one in Xith, rather than lumping blocks of the same GL calls togher into one where possible. Instead of a scene.compile(), maybe there could be an optional sorting flag when a node is added?
[/quote]
scene.compile() does NOTHING in Xith3D - it is simply empty… kept for “compatibility” with Java3D, but may be dropped. Again, as I mentioned above, there is a state sorting mechanism in Xith3D. It is rather complicated but also extremely flexible. I would suggest to make more detalied analysis of what is going on and where these duplicated calls are, how much do they eat of CPU time alone and in comparison with other engines (say, Java3D). And, of course, all the features and suggestions can be discussed here. This forum is a right place for this.

[quote]If I were to make these changes/additions, how would I go about submitting them?
[/quote]
There are many options: post your changes to IssueZilla (should be diffed against the latest CVS version), post them here as attachment, etc. etc. etc. Xith3D community is really open for cooperation, so all the options acceptable.

Yuri

P.S. If you need some more details on how Xith3D works internally, there are three options:

  1. Look at the source code.
  2. Search in this forum - I already explained a lot of conceptual topics time ago (don’t be surprized to find some posts 1-1.5 years old but still up to date.
  3. Ask me. Post in this forum is the best way. I don;t guarantee fast response, so if you need write to my dev.java.net address.
#5

Also one thing that Java3D benefits from is that it’s JNI functions are much more powerful (complete state setup) compared to the many native calls that are performed by Xith3D to archive the same thing.

One possible solution would be to move away from the fixed function pipeline with it’s many states to a shader based redering - which would also allow for more graphic effects.

Also one thing that I currently dislike in Xith3D but was not able to change is that for static textures, which are only used by the graphics card, the image is still present in java memory. A kind of texture producer pattern could allow for creating a OpenGL only texture wihile still being able to reload the texture if need be.

I read somewhere about performance benchmarks which compared VBOs with display lists. The result was that for static geometry display lists where a few percent faster (probably because the driver can better optimize them). While VBOs are the best solution for dynamic geometry (e.g. Adaptive terrain tesselation). In order to handle both a split the the class hierarchy may be needed:
Geometry -> StaticGeometry -> …
Geometry -> DynamicGeometry -> …
GemetryBuilder
where the GeometryBuilder contains methods to create the geomety in a OpenGL immedate stile (texCoord, Normal, Vertex, …)

As for thread safety - I think it’s enough if it is possible to build scenegraoh objects outside the rendering thread. Except maybe for textures - which would need a 2 pass construction (1. load image, 2. create texture object).
Also simultaneous read access to the data is required in order to have physics (collision detection) and rendering happen in different threads. This would only require that the scene graph update is done while both threads are sleeping (reader/writer lock introduced by java 5). The locking would then only be needed around the View.renderOnce() call and not within the rendering code.

These are just some of my ideas - I didn’t had time to implement or verify these yet.

#6

Hi,

[quote]Also one thing that I currently dislike in Xith3D but was not able to change is that for static textures, which are only used by the graphics card, the image is still present in java memory. A kind of texture producer pattern could allow for creating a OpenGL only texture wihile still being able to reload the texture if need be.
[/quote]
Yes, this is very important feature. I also was thinking to add this several times, but every time was able to reduce memory footprint another way. It really makes sense to add this feature as an extension for Texture2D, Texture3D etc.

Yuri