but according to what we just deciphered, the rendering and physics need to be in the same thread due to occurrences where the physics and updating of an entity could happen mid-rendering...

I suppose AI, sound, and loading assets could be on separate threads. What's everyone's thoughts about that? would that work? AI i'm a little iffy about, but I guess AI would just be changing the absolute velocities and direction of each entities, nothing really too drastic that could mess things up if it happened during mid-render.

A better question is how can they utilize all 4 cores yet have absolutely horrendous performance for what it is doing? ;)

Keep in mind that although it uses 4 cores, it doesn't use them all fully. Also, keep in mind that synchronization between threads, along with having multiple threads, is not free.

How they did it I can not say - I haven't looked into it (I hated the game and found the engine way too over-hyped). It looks like they broke it up mostly into rendering, particle system, physics, audio, AI, and input/output. AI, I/O and audio could probably run at full speed without a concern (maybe not the AI... depending on what it does), but most of it still has to complete before the rendering can go. Also, a few of those things aren't very intensive at all, which seems to be a bit confirmed when I see some benchmarks showing the game mostly using just 2 cores of a quad-core CPU.

When thinking of what you can break into individual threads, just think of what you can isolate from the rest of the code. The more parts of the thread that are dependent on other threads, the more synchronization will be required which will result in more overhead. Combined with thread management on the OS, this can result in multiple threads being slower than just one, especially if theres more threads than CPU cores. You'll want to research a lot of multithreading theory and concepts before attempting to make a game that works across many threads - plenty of people have enough of a challenge just efficiently using 2 main threads for their games.

hmm... so do you think it's just not worth doing multi threading? I was thinking just not caring about the syncing, that way there's no possibility of overhead. which is why is said about the rendering and updating. there's got to be somethings that don't necessarily need to care about what the other one is doing. I've done multi threading before and I get about the concurrency and setting locks and all that. I'm trying to find a way to eliminate all that safely.

Sorry just noticed your previous post. Rendering and updating doesn't have to be in the same thread, you just have to ensure that you don't draw partially updated entities. You could, for example, make a snapshot of the previous scene, render that, then start updating the new scene. This would create a lot of overhead, but they can then run completely independent of one another.

My threading knowledge pretty much ends here. The only threading I really do is with networking, which is nowhere near as complex as threading a whole game.

If its for education, feel free to try out as much threading as you want. If its to actually gain something from, such as better performance, I wouldn't recommend even bothering.

ah, alright, well thanks for your help. I'll investigate further. I'll just add more cons to my notes when thinking about adding multi-threading in the engine.

Quote:Original post by BloodLust666
bah, good point... I thought I thought of all possiblities; never really though of mid-updated rendering. Hmm... well, one reasoning why I decided on trying this is games like Crysis that utilize all 4 cores. What could they possibly be doing that utilizes all 4 cores? and not have the problems that could happen in my situation?

You can very easily keep 4 cores busy (simply scale the play area larger or have more detail within the same area OR improve the AI which can ALWAYS use more CPU than you have available.


You probably want to look into using 'critical sections' to interlock access to data shared between the different threads ('spin locks' are supposed to work on multiple cores and a good implementaion of critical sections should be using them for multicore threading).

Another thing that is done in games is to have the processing for the next render frame already in progress when CPUs would otherwise be idle because of some linear processing chokepoints for a frames data bottlenecking on one CPU.
(as the parts of a cycle for one frame are being completed, processing for the next can be beginning on another thread.

The schemes that I saw had multiple tasks that were scheduled on a turn timeline (some that could be parallelized because of data independance could run on more than one CPU and at other points background tasks could be run to fill in periods where CPUs would be idle (ex- AI pathfinding can be spread out over several frames so could be done as filler...)

Different tasks dont always take the same amount of time from farme to frame so that a flexible scheduling can make use of CPUs which otherwise would be idle in a more rigid task assignment.


Sound processing, network processing, AI (if you have the usual measly amount in most games), input processing, disk processing are all smaller independant tasks which could fill in idle times between the heavy number crunchers like graphics, etc...