I haven't posted in a while, and I suppose I was a little bored today, so...
This app demonstrates both integration of Irrlicht with MFC, as well as running the Irrlicht engine in it's own thread. I suppose it also demonstrates a way of implementing a waving flag.
Should be pretty straight forward from here to say have one thread render into the texture of another. Or the one I really want to try, is having multiple segments of the image rendered in different threads, but I haven't figured out how to set the camera views correctly.
Don't believe that would be a such huge performance increase (if at all).
This is correct, this application is not doing anything faster than a single threaded app would do, although it may keep the Windows GUI from interrupting the rendering.
A benefit would only be realized by splitting up the rendering work into multiple threads. One of my applications targets a 5120x2160 screen that is powered by four graphics cards. I'm hoping I can break the view up into multiple threads as the computer I'm using has eight processors. I'm thinking I'll have to load the same scene up into each thread, then synchronize the scene and rendering. I'll have to let you know how it goes.
I suppose the ultimate would be to enforce a 'write' cycle where the scene was updated, then a 'read' cycle where multiple threads could share the same scene data and render part of the result. Shouldn't be any problem having multiple threads access the scene data as long as nothing is modified. Of course in practice, I'm sure there is lots of 'state data' that would have to be separated before this would work. I'm not sure I'll have time to dig into things this deeply, but sounds like it would be fun.
hah,I just wanted an example other than intels destroy the castle demo for threading stuff. I'm trying to thread physics. So hopefully when I tear apart this code I'll learn how to correctly thread my app.
Also one thing it could be used for: Streaming loaders! (Putting the loader in a separate thread/task) for loading.
So, we could open the screen immediately then open the IRRscene and load the geometry. Also when the character/player get near of another zone, the loader could start and once loaded, the geometry that are not longuer in view be cleared. This could improve loading times and responses a lot.
All of the current loader that we have now, do only that task and it could seem to "freeze" a little if it take more time.
bob wrote:Or the one I really want to try, is having multiple segments of the image rendered in different threads
Translucent objects have to be rendered in sequence or horrible things will occur, and solid objects are sorted by material; if you multithread the rendering, you'll just end up with the GPU thrashing as it switches textures. Either way, you're likely bound by the GPU and bus, not any given CPU core.
So, OK, you could multi-thread the rendering, but why would you?
There could be a flag to tell Irrlicht when to access the new nodes. I don't know all the detail, but it's been done on some engines.
This will only permit a smooth loading of the geometry and textures. And not have to "wait" for loading. It's surely need a flag to tell it's ready to be rendered.
So we could load a tiny scene, then load the big scene after that. The player could navigate thru the tiny scene while the big scene is loaded.
I think there would be to have lots of modification on the source. So I don't think this could be done in the next release. Also this need to be done directly in the source. I doubt this could be "added".
Please note carefully that I'm not disagreeing with you.
Threading to avoid blocking on I/O = good.
Threading when you can't avoid blocking on I/O = pointless at best, harmful at worst.
There's been quite a few independent suggestions for multithreading bits of Irrlicht. I'd be very interested to see one of them taken beyond speculation.
First step: find or write a platform independent threading implementation that's license-compatible with Irrlicht. Given that someone is/was working on a BREW port, it'd be nice if any solution implemented a soft-threading abstraction on co-operative multitasking systems.
zthread is a license compatible threading abstraction.
Best way to introduce threading is on I/O or on separate tasks such as sound, AI, or physics (which even uses additional custom processors nowadays). This is far easier, scales much better, and is render technique independent.
If you want to make use of parallel hardware when rendering you should take care of the software renderers. Tiling render techniques should be a first approach.
bob wrote:Or the one I really want to try, is having multiple segments of the image rendered in different threads
Translucent objects have to be rendered in sequence or horrible things will occur, and solid objects are sorted by material; if you multithread the rendering, you'll just end up with the GPU thrashing as it switches textures. Either way, you're likely bound by the GPU and bus, not any given CPU core.
So, OK, you could multi-thread the rendering, but why would you?
I actually did a test run, I just loaded up the scene four different times and ran it in four different threads. Basically, all overhead x4, but it did offer quite a speed boost. (As mentioned above, the computer I targeting has eight processors and four graphics cards). Unfortunately, I had to move on before I could finish it. I'll try to simplify and post an example here. The only thing I never figured out, for lack of time, is how to align the four viewports so the final result was seamless.
Rogerborg: I agree with you. I have the ideas, but not the programming skills to apply them unfortunatly. hybrid: This is great! So someone had done this! Here a noob question : Can this library can be linked with IRRLicht and we could use it and using the standards IRRLICHT commands, or the source need to be modified to properly use it? (I think we would have a way to syncronise with the threads..)
Using ZThread means to introduce things which are likely unused in most settings. So in case you need additional structures (semaphores etc) in Irrlicht you'd have to change them on your own. But other than that you can use Irrlicht in conjunction with a threading library without any changes. It's up to you (or whoever does it ) to make proper use of threads and synchronize stuff.
As mentioned before, a good idea is to use such things with additional libraries. So it might be a wise idea to add threading abstractions to physics wrappers or the network libraries in use with Irrlicht.
Threading sound/AI/physics is a fine idea, but it's an application issue. Within Irrlicht itself, as well as object and texture loading, as Christian suggests, there may be a benefit to threading processor intensive non-GPU operations, but the only thing that immediately springs to mind is collision detection.
: Can this library can be linked with IRRLicht and we could use it and using the standards IRRLICHT commands, or the source need to be modified to properly use it? (I think we would have a way to syncronise with the threads..)