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.