Multithreaded Game Engines

[SPS]

I have moved these posts from here as it was going off topic and it is an interesting subject in its own right - feel free to continue the topic.

Originally Posted by NeverBackDown

Obviously but i thought it would be worth a try just to see if it really does do anything at all. Even if the engine made use of even 1 more thread i wonder what it would do to performance. Now i know it won't be much but could try BF4 pretty quickly to see. Or even the StarSwarm demo from steam.

Engines don't just create threads on the fly based on your thread count though. There will be presets, i.e. dual core, quad core, hex core modes and so on. Systems have to be designed to incorporate a particular number of threads and I doubt there are games that use up to 8 threads never mind 48, it can't just dynamically scale based on core count.

[Vicey]

I write software for a living so I guess I can chime in. One of the problems with multithreading a single task is you often times are waiting for the output from a previous part of your code before the next part runs. Like if you're doing a very large series of mathematical calculations where the next calculation depends on the result of the previous one.

What you'll often find with programs that are multithreaded is they break down what they're doing in to smaller pieces that can be executed on their own, self contained, not relying on the data being produced by other threads.

So for example in a game where you have entities, models, sounds, AI, networking, user interface, control input listening, events triggering. Theres a lot of stuff going on there where you can break these out of one thread in to multiple threads. Have one thread dedicated to AI, have one dedicated to networking, have one dedicated to physics calculations. Then you'll have a listening thread / master thread which dishes out the jobs. Like the conductor on an orchestra.

Now obviously this method of threading has a lot of problems with scaling because there are only so many different parts of a game that you can compartmentalise in this way and some jobs are simply not intensive enough to deserve their own thread. The future really is extremely optimised game engines.

The kind of engines where it's no longer textured objects in the game. It's a game engine where everything is a voxel. A volume element representing an object in 3 dimensional space. To put this another way, imagine your display with all its millions of pixels now imagine those pixels in 3D and dedicating a thread of your CPU to manage every single individual pixel represented there.

That is the only way really for the future of multithreading in games. If you treat every single pixel in the game as its own independent object or "voxel" that you can have a dedicated thread manage in every way, if sound is present in that pixel, its physics interactions, its movement trajectory, its shading.

Now there are some games today that use Voxels already like Minecraft (all its blocks are technically Voxels) but I'm talking on a much larger (well smaller) scale obviously where the individual pixels are voxels instead of large textured blocks.

I think we are a long way away from getting any workable game engine of this magnitude. We'll probably get real time raytracing before we get this.

But my point is, for gaming, these kind of high thread counts are not going to be utilised any time soon. And don't even think about buying this to be future proofing because by the time we have game engines that utilise this many cores there will already be consumer grade CPU's with this many or more cores for 1/20th the price making the investment today a waste of money.

For high core amounts like this the best usage is server and workstation software. Rendering obviously like was said in the review. Protein folding, Seti @ Home, scientific calculations, liquid simulations etc

By the way just incase anyone is interested how NVIDIA gets PhysX cloth and water physics simulations to work across their GPU's (which have thousands of CUDA cores now days) they actually just use the voxel method I described above. They use essentially voxels which are tethered together to create (in the case of cloth) a sheet and then each voxel has a certain amount of CUDA cores dedicated to calculating its movement.

Each voxel works completely independently from each other but because they are tethered together (always telling their neighbors their coordinates in space) they can add their neighbour voxels position to their own movement calculation creating collisions and that is what makes the cloth ripple out to the edges when a strong breeze hits the centre.

I hope this was somewhat informative and not too boring :P

[SPS]

Originally Posted by Vicey

[...]

This is my point, scalability, it's doesn't work well with the CPU. What you are essentially referring to there is GPGPU programming, where the programming model switches from, what does each thread do, to, which bit of data does each thread process. So you'd have a one thread process a single data input (kernel) like with fluid simulation. This requires thousands of concurrent threads to be fully effective and this is why the GPU is preferred but it is scalable, less threads means low throughput, more threads means higher throughput. Creating and switching threads one GPU is practically free compared to doing that on the CPU, they can be thought of as lightweight threads in comparison. You can use APIs such as OpenCL/CUDA/DirectCompute (compute shaders) that support this programming model. I find it pretty interesting of how we can make a game massively parallel and so this is why I am actually writing a paper on it.

Minecraft is not a voxel game though, something like cube world is a good example. Voxel engines are not necessarily more efficient either, there are drawbacks.

[Vicey]

Originally Posted by SPS

Minecraft is not a voxel game though, something like cube world is a good example. Voxel engines are not necessarily more efficient either, there are drawbacks.

Well technically Minecrafts not using the traditional voxel model because it doesn't project its voxels based on their proximity to each other but rather dependant on an XYZ grid system. But I feel the comparison is still accurate because everyone hsa heard of Minecraft and no one has heard of Cube World.

And we definitely would do GPGPU tasks on the CPU if we had the cores to do so. We just don't. Intel's Larabe was hopefully going to bridge that gap between wimpy cores like what GPGPU's have and brawny cores that CPU's have allowing more accurate simulations with hundreds of advanced cores.

But Intel axed the project. Anyway my point was we don't have these engines, current games and even future games are not going to take good use of this kind of CPU threading. I wasn't arguing against anything you said in your past post.

[SPS]

Originally Posted by Vicey

Well technically Minecrafts not using the traditional voxel model because it doesn't project its voxels based on their proximity to each other but rather dependant on an XYZ grid system. But I feel the comparison is still accurate because everyone hsa heard of Minecraft and no one has heard of Cube World.

And we definitely would do GPGPU tasks on the CPU if we had the cores to do so. We just don't. Intel's Larabe was hopefully going to bridge that gap between wimpy cores like what GPGPU's have and brawny cores that CPU's have allowing more accurate simulations with hundreds of advanced cores.

But Intel axed the project. Anyway my point was we don't have these engines, current games and even future games are not going to take good use of this kind of CPU threading. I wasn't arguing against anything you said in your past post.

Yeah exactly and I know I was merely elaborating on a few points

[Jinxxter]

Originally Posted by Vicey

I write software for a living so I guess I can chime in. One of the problems with multithreading a single task is you often times are waiting for the output from a previous part of your code before the next part runs. Like if you're doing a very large series of mathematical calculations where the next calculation depends on the result of the previous one.

What you'll often find with programs that are multithreaded is they break down what they're doing in to smaller pieces that can be executed on their own, self contained, not relying on the data being produced by other threads.

So for example in a game where you have entities, models, sounds, AI, networking, user interface, control input listening, events triggering. Theres a lot of stuff going on there where you can break these out of one thread in to multiple threads. Have one thread dedicated to AI, have one dedicated to networking, have one dedicated to physics calculations. Then you'll have a listening thread / master thread which dishes out the jobs. Like the conductor on an orchestra.

Now obviously this method of threading has a lot of problems with scaling because there are only so many different parts of a game that you can compartmentalise in this way and some jobs are simply not intensive enough to deserve their own thread. The future really is extremely optimised game engines.

The kind of engines where it's no longer textured objects in the game. It's a game engine where everything is a voxel. A volume element representing an object in 3 dimensional space. To put this another way, imagine your display with all its millions of pixels now imagine those pixels in 3D and dedicating a thread of your CPU to manage every single individual pixel represented there.

That is the only way really for the future of multithreading in games. If you treat every single pixel in the game as its own independent object or "voxel" that you can have a dedicated thread manage in every way, if sound is present in that pixel, its physics interactions, its movement trajectory, its shading.

Now there are some games today that use Voxels already like Minecraft (all its blocks are technically Voxels) but I'm talking on a much larger (well smaller) scale obviously where the individual pixels are voxels instead of large textured blocks.

I think we are a long way away from getting any workable game engine of this magnitude. We'll probably get real time raytracing before we get this.

But my point is, for gaming, these kind of high thread counts are not going to be utilised any time soon. And don't even think about buying this to be future proofing because by the time we have game engines that utilise this many cores there will already be consumer grade CPU's with this many or more cores for 1/20th the price making the investment today a waste of money.

For high core amounts like this the best usage is server and workstation software. Rendering obviously like was said in the review. Protein folding, Seti @ Home, scientific calculations, liquid simulations etc

By the way just incase anyone is interested how NVIDIA gets PhysX cloth and water physics simulations to work across their GPU's (which have thousands of CUDA cores now days) they actually just use the voxel method I described above. They use essentially voxels which are tethered together to create (in the case of cloth) a sheet and then each voxel has a certain amount of CUDA cores dedicated to calculating its movement.

Each voxel works completely independently from each other but because they are tethered together (always telling their neighbors their coordinates in space) they can add their neighbour voxels position to their own movement calculation creating collisions and that is what makes the cloth ripple out to the edges when a strong breeze hits the centre.

I hope this was somewhat informative and not too boring :P

There were such engines back in the days where cpus had only one core and less than 1GHz in speeds. One engine was used by Comanche up to Comanche 4 I believe and the other one was used in Outcast.
I'm not entirely sure though if both engines were voxel only or if were mix-engines using voxels and textured polygons. Outcast was limited to 512x384 at that time but until today there are community-mods for resolutions up to 720p as I remember.

If I'm not mistaken there can't be a raytracing-only engine because you can't have all effects using that technology. Please feel free to creect on that. But imagining a combined engine using voxel and raytracing should give some really heavy eyecandy graphics there.

[SPS]

There some interesting stuff here to do with voxel engines being used on this game.

But cube world is pretty impressive.

[yassarikhan786]

Thanks for the information guys. I don't know much about game development so this was really an interesting insight.

[SPS]

I'm currently working on a massively parallel particle system, it's amazing what you can get out of it. I can have millions of particles interacting with a terrain and still retain 60FPS, I'll upload a vid if people are interested.

[yassarikhan786]

Originally Posted by SPS

I'm currently working on a massively parallel particle system, it's amazing what you can get out of it. I can have millions of particles interacting with a terrain and still retain 60FPS, I'll upload a vid if people are interested.

I'd be interested in seeing it. I've developed a few games using the XNA framework (I'm aware it's not proper, fully-fledged game development), so I know a little about particle effects and the sort. Nothing at the level you're working at.