it would be great if some developers can form a group to create a multithreaded 2.0 and output some hard data which proves the multithreaded advantages.
i feel like making jme multithreaded is some what a high priority task, since, first java natively supports multithreading, second most commercial game engines now support multithreaded rendering now days.
i think i can list a ton of other features that commercial engines has that jME doesn't, which i believe is higher priority. after all, pretty many games has managed to do well single threaded s
i do think that multithreading is really cool though, and agree that we should try to get somewhere with it in 2.0, together with the other proposed core changes.
hmm, what i'm trying to say is that with all the games i've worked on using jME, performance has never been the issue… 
llama said:
Of course I can only hope someone else will finish the somewhat easier branch, that simply splits up each part of the render cycle (animation, culling, collisions).. and then we'll see :)
Im still inclined to think that to split up and share the render cycle is the starting point, also look at what can be done with Threadlocal
What I originally proposed and continue to think is the best idea was to create an abstraction layer around LWJGL (that could perhaps be used for other implementations in the future as well) that uses very simple Objects (it is Java after all and we love OO coding, right?) that represent the state of the OpenGL screen at any given time. By using objects that are processed in another thread we gain complete thread-safety (if written properly) and just need to handle the scenarios llama mentioned to prove that it can actually improve performance rather than hinder. Honestly I think this really should not touch jME at all except that jME could then use this instead of directly relying on LWJGL. We could also simplify a lot of things via this abstraction layer.
I'm just a frog though and spend far too much time in the theoretical and very well could be totally wrong about the idea…only way to verify is to give it a shot.
darkfrog said:
What I originally proposed and continue to think is the best idea was to create an abstraction layer around LWJGL (that could perhaps be used for other implementations in the future as well) that uses very simple Objects (it is Java after all and we love OO coding, right?) that represent the state of the OpenGL screen at any given time. By using objects that are processed in another thread we gain complete thread-safety (if written properly) and just need to handle the scenarios llama mentioned to prove that it can actually improve performance rather than hinder. Honestly I think this really should not touch jME at all except that jME could then use this instead of directly relying on LWJGL. We could also simplify a lot of things via this abstraction layer.
I'm just a frog though and spend far too much time in the theoretical and very well could be totally wrong about the idea...only way to verify is to give it a shot. :)
Didn't Java3D do something like this? In fact I think they do it not just for OpenGL but for the whole scenegraph:
http://java3d.j3d.org/implementation/architecture.html
All I can say is that I wish all the best to the people that are going to implement this, it really will be incredibly complicated to get right. Also, I'm not sure that the theoretical performance gain will weigh up to all the work that is needed for this. Also, making things such as jME multi-threaded is not common yet. For example, can anyone name a multi-threaded GUI framework? (in any language)
Well, the first multithreaded UIs came in the 70s. They were actually quite revolutionary because they had a dedicated thread for handling user input and therefore were more responsive than older UIs.
keeskist said:
For example, can anyone name a multi-threaded GUI framework? (in any language)
jseamless.org :)
llama said:
Didn't Java3D do something like this? In fact I think they do it not just for OpenGL but for the whole scenegraph:
http://java3d.j3d.org/implementation/architecture.html
Indeed, but their failure was that they put way too much into it. They tightly coupled the whole system versus a more modular design that I'm suggesting. The fact that Java3D saw the benefit to the idea gives it promise I would say as well...
Further, just because a framework is all but dead and kinda sucks in several ways doesn't mean we can't learn anything from it.
I would just be concerned that the overhead is not too large.
It's one thing to speed up the core engine, but it's another to benefit real games, where those cores might already be put to good use. The overhead is essentially wasted CPU time, so the benefits of multithreading must outweight that.
I guess prototyping is the only way to see the real benefits.
darkfrog said:
llama said:
Didn't Java3D do something like this? In fact I think they do it not just for OpenGL but for the whole scenegraph:
http://java3d.j3d.org/implementation/architecture.html
Indeed, but their failure was that they put way too much into it. They tightly coupled the whole system versus a more modular design that I'm suggesting. The fact that Java3D saw the benefit to the idea gives it promise I would say as well...
Further, just because a framework is all but dead and kinda sucks in several ways doesn't mean we can't learn anything from it.
Well I'd say it's more proof that Java3D was overengineered from the start :)
I'm still not sure what your exact plan is, but it sounds like instead of invoking methods you want to do messaging passing for each method to an OpenGL thread, because you want to do out-of-your-own-thread invokations of Open GL methods from within the scope of your current block of code? (and pressumably wrap methods around the message passing)
If so, sounds like you're trying to work around a syntax/language problem with Java.. you're going to introduce a whole lot overhead just cause you don't have something like closures.
The fact of OpenGl being native should give some direction…
I don't believe it would really add much overhead and gains would out-weigh that I think. However, you made a very good point that this is all just theory until it has been written and proven. With that I'll defer to a later date when I have the time to write a complete proof-of-concept that show what I have in mind.
Really interesting thread. I've been following it.
I can't add too much. Splitting in two for update/render, using copying, would definitely be an easy way to go and the easiest to test, I guess.
I totally agree with llama and others. This should be proved before and changes should be optional.
Also I believe that a good improvement can be obtained from multithreading the "business logic", network and in some applications, loading. Multithreading LWGLJ could be interesitng for this but I wouldn't go that way… I would abstract and multithread at jME level for that sake.
More exotic multithreading models have been discussed so I am asking myself…
What is the state of the art on the multithreaded games field?
Multithreaded game engines are indeed the route of the future, and many game companies (including the one I used to work for) are trying to build that perfect game engine that is capable of taking advantage of the blossoming number of cores out there. That said like MrCoder, I would have to argue that we are far behind other commercial game engines in many more immediately useful areas, including areas that would improve performance.
I would cite several reasons for us not to go whole hog on MT… 1. Performance may go up some, but anyone who says adding MT to an engine would scale performance by some factor similar to the number of cores on the machine knows next to nothing about complex MT applications. 2. Making an API inherently MT is a HUGE undertaking to do right (especially to do right for everyone) 3. You can already use jME in multi-threaded apps and we can spend some effort instead to make that easier and safer rather than trying to write a "works for every situation" API. I believe the inclusion of members from the old Java3d team on our ARB will help us use some of the good experience of what to (and not to) do.
My 2 cents on what would I rather see happen: 1. Make it easier to call everything in jME from any thread. That would probably mean adding deferred calls/callbacks in some places and probably some context management (which would be a good thing anyway…) 2. Add more threadsafety, either in the form of read/write locks, etc. or in general contracts. 3. More base app types that incorporate MT concepts. (I know of a MTGame base type being worked on) allowing new users to plug in without knowing everything up front. 4. Thread pool usage for certain tasks (maybe updating skins on the CPU, etc.)
darkfrog said:
keeskist said:
For example, can anyone name a multi-threaded GUI framework? (in any language)
jseamless.org :)
Perhaps I should have said 'widely used GUI framework' :P
Because Swing, SWT, QT and WinForms are all single threaded (at least, when you are programming for it you're working with one thread) I made this post.
They may default to a single thread, but the majority of UI developers break out into multiple threads when possible anyway. Multi-threading a UI is a complex thing, which is why so few APIs do it. However, that is not to say it's not incredibly beneficial to do. The single-threaded nature of Swing coupled with many developer's lack of understanding of multi-threading is the main reason that people believed that Swing was slow and crappy. The majority of the time it was because people were doing "work" in their UI thread that caused the UI updates to stop until it was done. This is really the same problem that exists in OpenGL games, but fortunately most game developers realize this problem and either do more asynchronous work or they are more tactful about how and when they cause those pauses to occur.
I agree with Renanse. As pro-multi-threaded as I am, I have no delusion that it will magically make our games run ten times faster than they already did. In many cases you'll get no gain at all, but in a well designed, thread-safe game engine the arena is then open to divide games into more modularized parts and simplify design.
Before multi-processor and multi-core machines existed threads…why? Did they make things faster? No, not inherently. It was purely for developers that these things existed because it decoupled and simplified development of modular aspects of an application. This is still true today and is the primary reason I want to see jME have full thread-safety (not necessarily enforced multi-threading). jME is designed with an update and render loop primarily because it's one of the few ways you can work in a single-threaded environment and decouple the work that needs to be done. By making jME thread-safe we can then break away from this mentality (at least have the option to) and go for a more simplistic and more powerful architecture.
Ranting ends now… :o
I'm against multithreading JME. I'm sceptical that it will increase rendering performance, even on multi core cpus. Most likeley the overhead would be greater than the benefit and you'll end up burning cpu that the game could use on other things. Thats just my subjective opinion. Please prove me wrong
Multithreading JME will make it much more complicated. This is bad. There will be more bugs. The bugs will be more difficult to fix. The code will be more difficult to understand, wich will make it more difficult for the community to improre the api.
I've used Java3D at work for the last year and a half, and one if its biggest problems is that it is multithreaded. According to the docs all changes should be done in Behaviors, wich is called from one of the many j3d threads. However the changes will not be shown before 1 or 2 frames. Even 2 changes made in the same behavior may take effect at 2 different frames. Because of bugs the api is not even thread safe in any way. Call 2 get methods on a non live branch may crash j3d. And there are lots of other MT issues.
It may be possible to improve JME performance without resorting to multithreading. OpenGL is a pipeline. Things can (in theory) be done in parallel with the rendering.
tom said:
I've used Java3D at work for the last year and a half, and one if its biggest problems is that it is multithreaded. According to the docs all changes should be done in Behaviors, wich is called from one of the many j3d threads. However the changes will not be shown before 1 or 2 frames. Even 2 changes made in the same behavior may take effect at 2 different frames. Because of bugs the api is not even thread safe in any way. Call 2 get methods on a non live branch may crash j3d. And there are lots of other MT issues.
It may be possible to improve JME performance without resorting to multithreading. OpenGL is a pipeline. Things can (in theory) be done in parallel with the rendering.
I like people who experienced things... it is wise to listen/read them :)
By the way, one solution to improve performance may also be to wait for new JVM generations. I found this page particularly interesting :D