Simulation and Rendering in Parallel (Multi-Threading)

[ice9]

I wanted to ask about the feasability of using Irrlicht in a game that runs its simulation and rendering in parallel.

To be clear, I am talking about rendering that takes place on the CPU. It isn't uncommon for 50% of the CPU resources to be used for rendering in a frame (for a "cutting-edge" graphics type of game).

If a game is using roughly 50% of the CPU for simulation (input, physics, AI, etc) and 50% for rendering (visibility, shadows, draw calls, etc) -- then you can double your framerate if your game is running on a dual-core CPU.

At a high level, this is how the sequencing would work:

Sim:|----(n)-----|---(n+1)---|----(n+2)---|

Rdr:|----(n-1)---|-----(n)----|----(n+1)---|


Once frame N is done simulating, it sychronizes with the render thread, and moves onto frame N+1. At the same time the Render thread starts rendering frame N.

The rendering lags the simulation by 1 frame, which does introduce some input latency, but that's a small price to pay for a potential doubling of the framerate.

The question is whether Irrlicht would be amenable to such an architecture? I'm just starting to work with Irrlicht, but it seems the rendering is all contained between beginScene/drawAll/endScene. If all the data needed by the scene manager is updated during the sychronization between simulation and rendering threads, perhaps everything would be OK.

If you've read this far, thank-you, and I'd be happy to answer questions or clarify anything I've talked about.

[Dorth]

Input latency? Are you kidding me? The one frame of your suggestion would never affect the reaction of anyone. Just by accepting your own concept, let's say we double a framerate of 24 fps, the bare minimum of nearly any recent game (except on cell). Then let's double that, per your theory. 48 fps.
Now, we take a second and divide it by 48: 20,83333333333333 ms. Right. http://en.wikipedia.org/wiki/Reflex . A reflex, not even an informed decision takes from 150 to 300 ms. Worry about your screen and your graphic card before worrying about that. It's not even registrable. ( And just for kicks, let's say you improve your framerate from an excellent 60 fps to a useless 120 fps, and let's ignore the refreshing issue, that's 8,33333333333 ms.)

[rogerborg]

Who let the Evil Robot Dorth loose?

Irrlicht is not implicitly threadsafe. However, it should certainly be possible to achieve this, if you're prepared to do your own mutexing.

There's no point in multthreading if you're just going to mutex the entirity of the render loop, but you don't want the Irrlicht data changing half way through a render. I'd therefore suggest that you duplicate the entire world state, either by having your own master data, or conceivably by duplicating the Irrlicht scene under another scene manager.

Then your input / physics / AI can operate safely on the master state, while the renderer is drawing from its slave copy of that state. The only point of synchronisation is copying the master state (i.e. position, orientation) to the render state, but that should be a relatively fast operation.

[Dorth]

Sorry, my cat died so I was (still am?) in a very foul mood + I'm allergic to bull. But yeah, what rogerborg said. Actually, you can just reuse that 99% of the time. What rogerborg said.

[ice9]

Who let the Evil Robot Dorth loose?


There's no point in multthreading if you're just going to mutex the entirity of the render loop, but you don't want the Irrlicht data changing half way through a render. I'd therefore suggest that you duplicate the entire world state, either by having your own master data, or conceivably by duplicating the Irrlicht scene under another scene manager.

Then your input / physics / AI can operate safely on the master state, while the renderer is drawing from its slave copy of that state. The only point of synchronisation is copying the master state (i.e. position, orientation) to the render state, but that should be a relatively fast operation.

I think it's a good solution for the simulation to maintain its own state, and then "hand off" what is necessary for the rendering during sychronization.

I will likely be taking this approach, and I will follow up in the future with how it turns out.

[ice9]

Input latency? Are you kidding me? The one frame of your suggestion would never affect the reaction of anyone. Just by accepting your own concept, let's say we double a framerate of 24 fps, the bare minimum of nearly any recent game (except on cell). Then let's double that, per your theory. 48 fps.
Now, we take a second and divide it by 48: 20,83333333333333 ms. Right. http://en.wikipedia.org/wiki/Reflex . A reflex, not even an informed decision takes from 150 to 300 ms. Worry about your screen and your graphic card before worrying about that. It's not even registrable. ( And just for kicks, let's say you improve your framerate from an excellent 60 fps to a useless 120 fps, and let's ignore the refreshing issue, that's 8,33333333333 ms.)

Dorth, I'm sorry about your cat.

When you are feeling better please read this article to enlighten yourself on the issues with input latency:

http://www.gamasutra.com/view/feature/1 ... veness.php

[Dorth]

Ok, good point, but he's talking such an extreme worst case, where someone would introduce every possible lagging figure on top of not doing he's maintenance on the proper order that for his scenario, it does become atrocious. But here, maybe more kindly, is the point I was trying to make. If your system truly doubled the framerate, don't you think a half old frame is a very low cost for that?

[ice9]

Ok, good point, but he's talking such an extreme worst case, where someone would introduce every possible lagging figure on top of not doing he's maintenance on the proper order that for his scenario, it does become atrocious. But here, maybe more kindly, is the point I was trying to make. If your system truly doubled the framerate, don't you think a half old frame is a very low cost for that?

Definitely, I agree it's a low cost to pay for a potential doubling of the framerate. I think we are on the same page, I was just pointing it out as something to be aware of.