Multithreading in Irrlicht

[Pinic]

I would like to learn about multithreading in Irrlicht.
What is implemented in the multithreading engine? Found a lessonhttp://www.gamedev.ru/community/irrlicht/articles/?id=17
Is it useful?
Are there any other lessons or examples on multithreading?

[devsh]

Absolutely nothing in the Irrlicht engine itself.

You better mutex everything if you're going to play with Irrlicht using threads.

N.B. OpenGL is a b((ch so it actually requires you to do all the OpenGL API calls (everything that calls or uses IVideoDriver) in the same thread which created the OpenGL context (same thread as the one that called createDevice)

[masm32]

Hello, you don't have to multithread the 3D API calls. Without studying the source, we could offload the OnRegisterSceneNode() and OnAnimate(u32 timeMs) to WorkerThreads. This should work without problems.

[devsh]

I think you'll find that OnRegisterSceneNode and OnAnimate are quite hard to parallelize since you're dealing with a scene-tree... also kicking stuff off to worker-threads may give you worse performance because of latency (time for worker thread to get its job, time you need to wait for worker threads to complete)

For this you'd need to implement a well-designed job-system like in the Naughty Dog engine that would actually have to be good enough to be used by the user for scheduling their own threads.

[masm32]

I'am not talking about parallelize the functions itself. The main thread pushes the scene tree nodes in a queue, the worker threads fetch a node from queue and do the OnAnimation and OnRegisterSceneNode. This is not perfect, but it can be parallelized, because this functions do nearly all computing on the node itself. Maybe sorting into different arrays has to be secured. I don't think that there is much speed gain with small or medium projects. But it will speed up rendering. I think I will do some testing...

[devsh]

The approach you're taking about

The main thread pushes the scene tree nodes in a queue, the worker threads fetch a node from queue and do the OnAnimation and OnRegisterSceneNode.

is exactly what I've outlined.

Will cause latency issues, unless the other cores in the system are running no other threads than irrlicht's OnAnimation and OnRegisterSceneNode.
One you throw something else into the mix, like Bullet, or other irrlicht functionality (anything else you may want to thread) you end up with a scheduling problem.
Basically your FPS will go up, but your lag will as well.

I'm not here to bash the idea of multi-threading OnAnimate and OnRegistedSceneNode, just to point out that irrlicht would need to either implement or integrate a good task-based scheduling system.

[masm32]

unless the other cores in the system are running no other threads than irrlicht's OnAnimation and OnRegisterSceneNode

This is actually the same what I was telling. Only do things that have no influence on other nodes. There is a small latency for the queue handling. This amount of time will negate the speedup for scenes with only a couple of nodes. But implement a task switching system will be overkill. We are talking about multithreading not multitasking. As an example, Unity uses an job based multithreading system like I mentioned.

[Noiecity]

That is the problem when trying to implement ECS, the performance can improve, but the synchronization between what is rendered on screen and what the cpu calculates can differ in synchronization, forcing a synchronization in some frames, although it does not affect the logic of the physics, it even benefits in terms of performance, but latency and performance are not always the same.
Even when they implemented ECS in unity and gave examples, these examples also presented these problems, sometimes the models were strongly desynchronized in a frame and re-synchronized in another, making a sudden change in the speed that is observed, of course, for the cpu the model moves correctly.
(almost at the end of the video you can clearly see an example, although it actually happens throughout the whole video)
youtube.com/watch?v=9ADpYQIQg1w

[CuteAlien]

Wow, digging up an old thread :-) But there has actually been a tiny, tiny bit progress in Irrlicht since 1.8. Because it's now possible to get an IContextManager from the Irrlicht device. Which has a function activateContext. So at least passing around the OpenGL context is possible by now. 2 calls:

Code: Select all

// Thread giving up the OpenGL context
device->getContextManager()->activateContext(irr::video::SExposedVideoData());

// Thread takes over OpenGL context
device->getContextManager()->activateContext(device->getVideoDriver()->getExposedVideoData()); 

Basically the way to use that is:
1. Main thread gives up GL context
2. Some background thread takes over and does stuff
Main thread (and other threads) in the mean-time only do stuff not related to opengl
3. Background thread gives up GL context
4. Main thread takes over GL context again

We use that currently to separate Texture and model loading. Texture load thread needs the GL context, the mesh load thread doesn't - so they can run in parallel.Thought you have to be careful to not load models which load textures themselves (either handling the texturing yourself or use the also new IMeshTextureLoader interface which allows splitting this).

Note we only use this so far at load-time (which can speed up loading quite a bit). But being careful about which thread needs and which doesn't need opengl access it might also be used for more stuff. Collisions come to mind, you probably don't even need the context switching for those.

[Noiecity]

Wow, digging up an old thread But there has actually been a tiny, tiny bit progress in Irrlicht since 1.8. Because it's now possible to get an IContextManager from the Irrlicht device. Which has a function activateContext. So at least passing around the OpenGL context is possible by now. 2 calls:

Code: Select all

// Thread giving up the OpenGL context
device->getContextManager()->activateContext(irr::video::SExposedVideoData());

// Thread takes over OpenGL context
device->getContextManager()->activateContext(device->getVideoDriver()->getExposedVideoData()); 

Basically the way to use that is:
1. Main thread gives up GL context
2. Some background thread takes over and does stuff
Main thread (and other threads) in the mean-time only do stuff not related to opengl
3. Background thread gives up GL context
4. Main thread takes over GL context again

We use that currently to separate Texture and model loading. Texture load thread needs the GL context, the mesh load thread doesn't - so they can run in parallel.Thought you have to be careful to not load models which load textures themselves (either handling the texturing yourself or use the also new IMeshTextureLoader interface which allows splitting this).

Note we only use this so far at load-time (which can speed up loading quite a bit). But being careful about which thread needs and which doesn't need opengl access it might also be used for more stuff. Collisions come to mind, you probably don't even need the context switching for those.

thanks, I always learn something new about irrlicht