multithreading

I believe they say that because the newer CPUs with multiple cores need multithreading in order to be fully taken advantage of.
That's how the development in CPU technology seems to be going - less focus on making them go faster, and more focus on making them run multiple things in parallel. It will probably not be too long until 8 and 16-core CPUs will be mainstream. (Resulting in "a bucketload of threads" as the standard programming practice.)

The rendering pipeline is still strictly single threaded. Even if Dx11 or "was supposed to be GL3.0" would support multithreading, you wouldn't get anything more out of your GPU because the GPU itself will serialize the operations anyhow (actually it could slow down).

Utilizing multiple cores on the other hand is another issue. But that's more useful for non gfx stuff like AI, game logic, physics etc.

Synchronizing it smart however is not simple (so you won't spend more time synchronizing the whole thing than you'd have by going 1thread :D)

In my operating system, there is no graphic card support -- just updates VGA memory directly. I can benefit from multicore. They have to stay out of each other's way, so I made a layer for each core and when it's ready to update VGA memory, it merges the layers using a mask to tell what's been updated. Cached memory is a bitch -- I still haven't mastered how to transfer stuff. There's an instruction "write back and invalidate cache" but doesn't do exactly what I thought. Uncached memory is just too slow -- can't use it. Fortunately, tiny graphic glitches aren't likely to do much harm.

Making something multithreaded hardly makes it multicore!

Quote:

Original post by polymorphed It will probably not be too long until 8 and 16-core CPUs will be mainstream. (Resulting in "a bucketload of threads" as the standard programming practice.)

Intel's next series of CPU archs. comes in 2, 4, 6 and 8 core flavours, each of which supports hyper-threading to allow 4,8, 12 and 16 threads 'active' at once.

Quote:

Original post by phantom Intel's next series of CPU archs. comes in 2, 4, 6 and 8 core flavours, each of which supports hyper-threading to allow 4,8, 12 and 16 threads 'active' at once.

And improved SIMD instruction sets (AVX) are also planned, for even more (albeit somewhat easier to handle) parallel goodness. Much fun(?) lies ahead.

There are several things to do in a modern graphics engine that don't involve submitting data to the GFX card. Second Most high-end renders are software based since hardware isn't 100% accurate.

I believe we are looking at more than 3-5 years before multithreading programming in games becomes more mature. Most programs today are still not good at utilizing even two cores to their full potential. I have seen a few that do quite good job on multiple cores but they are not games.

By then I think we're looking at 16 cores as the norm. But I think it depends on how well they manage to lower the power consumption. Or we might only have 8-16 cores for some time to come.

Quote:

Original post by polymorphed I believe they say that because the newer CPUs with multiple cores need multithreading in order to be fully taken advantage of.

While it has never been more true, it turns out that it has been a really long time [in computer years, at least] since even a single core processor could be properly utilized without use of threading.

Anyway, with respect to graphics explicitly, there is a lot more to graphics than a series of render calls. There is updating of animation/particles/etc, object culling, sorting of objects to get better performance out of your draw calls, etc. Lots to do.

Object culling is a trivially paralellized process as soon as you are hitting multiple branches on whatever sort of spacial partitioning tree you are using. So is sorting for that matter. Updating animation and particles can be done as a series of jobs, frequently in parallel with the object culling. So yes, there is a lot of room for parallelism.

Still though, your efforts are better focused elsewhere. Graphics can be done sequentially without much a penalty. Parallelizing physics will earn you more in terms of performance. Parallelizing AI will allow you to actually do some interesting stuff without grinding your game to a halt [by the way, AI is a great multithreading target, and should really be one of the two first things that are picked to focus on, the other being file/network IO].

On the note of future architectures, machines are only going to get more cores. We are pretty much butting up against the Ghz' limit, and can earn a lot more in terms of performance by adding more weak processors instead of making the processors that are already there stronger.

Quote:

Original post by MichaelT I believe we are looking at more than 3-5 years before multithreading programming in games becomes more mature. Most programs today are still not good at utilizing even two cores to their full potential. I have seen a few that do quite good job on multiple cores but they are not games.

But you do not want 100% utilization.

Let's say your physics simulation utilizes your CPU at 100% (4 cores).

Then you put this on 8 core machine, and you get 8x50%.

But here's the real problem. If you *need* 4x100%, then the simulation will not run on anything with 2 cores. Obviously, you cannot lower fidelity, like changing time-step from 100Hz to 50Hz.

With real time, 100% utilization becomes a binary condition. Simulation either runs in real-time, or it doesn't. if anything, the greatest benefit multi-threading can bring is lowering the utilization.

The only thing that can fill the remaining resources is fluff. More particles, for example, but definitely nothing that affects the state of simulation.

Alternatively, you have fixed hardware (consoles). There, you do not need some magic techniques, since you can hard-code the system layout, and lose a lot of fat coming from infinitely scalable design.

But as far as real-time goes, the system either is powerful enough to do the work, or it isn't. But 100% utilization for this purpose is a moot point for the useful work.

Quote:

Original post by Antheus But you do not want 100% utilization. Let's say your physics simulation utilizes your CPU at 100% (4 cores). Then you put this on 8 core machine, and you get 8x50%. ...

100% ?

Well it depends doesn't it? If you have an application that needs full performance, then you would typically want it to use 100%. Anything less would be a waste.

If I put my app on an eight core I would fully expect it to scale to use all eight 100% if this is what is needed by the application. Likewise, if I put it on a dual core I would expect it do scale down and maximize usage on that situation also.

Either you missed my point, or you had some ideas of your own and saw my post as an opportunity. In any case it was not my point to discuss 100% utilization. In fact, I did not even mention it. Honestly, I am a bit confused on how my post could even be interpreted in that way.

Quote:

Original post by reoxthen I mean, I read an article about 3dsmax sdk that says a good renderer should support multithreading.

Offline renderers, such as the one(s) 3DSMax use, should most definitely use multithreading (not doing this would almost be a crime ;)

Realtime renderers, however, don't have to be multithreaded at all. In a well designed realtime 3D engine, pretty much everything will run on the GPU anyway. The CPU does only basic housekeeping while filling the GPUs command pipeline.

Quote:

Anyway, with respect to graphics explicitly, there is a lot more to graphics than a series of render calls. There is updating of animation/particles/etc, object culling, sorting of objects to get better performance out of your draw calls, etc. Lots to do.

Not really. Low level animation and particle system updates run entirely on the GPU nowadays. The CPU is relegated to only update the matrix hierarchy, and that's lightning fast. High level object culling is something that will only get you a few yawns from a modern CPU core. There's no need to multithread spatial tree traversal. I've tried it on scene with tens of millions of faces. The (highly optimized) multithreaded implementation was slightly slower than the single core implementation, because the two cores would get into each other ways while reading data, and generate stalls. Sorting is also something that can be done so quickly on a single core that MTing it doesn't make sense.

Actually, one single core is perfectly fine to feed a modern GPU-heavy 3D engine. The remaining cores can then be used to perform more heavy work, such as physics.

Or AI. I'm really sick of new games with NPCs that have the IQ of a tapeworm. Geez, you essentially have two cores entirely available to do complex AI (assume a quad core CPU, with one core on graphics, one on physics, and game logic shared between both). Use them !

Quote:

Original post by Yann L Not really. Low level animation and particle system updates run entirely on the GPU nowadays. The CPU is relegated to only update the matrix hierarchy, and that's lightning fast. High level object culling is something that will only get you a few yawns from a modern CPU core. There's no need to multithread spatial tree traversal. I've tried it on scene with tens of millions of faces. The (highly optimized) multithreaded implementation was slightly slower than the single core implementation, because the two cores would get into each other ways while reading data, and generate stalls. Sorting is also something that can be done so quickly on a single core that MTing it doesn't make sense.

Thanks for the info. Judging from your work, it seems like you'd know a bit [lot] more about this than I would. My experience parallelizing a rendered has pretty much resulted in neutral effect as well [outside of special circumstances]. Was just pointing out that there is plenty of things that could be done concurrently. Still though, good to know that some beefier renderers than I've ever dealt with see similar results.

In total agreement though. There are other things in much more urgent need of attention than the renderer when it comes to multithreading.

Quote:

Original post by Antheus If anything, the greatest benefit multi-threading can bring is lowering the utilization.

Wait, what? The entire point of multithreading is to increase utilization. If you have one thread, then on every I/O call, every cache miss, every little hickup along the way results in the processor just sitting there. Mulithreading allows you to actually do something constructive while those wrinkles get ironed out, thus increasing utilization of the processor.

Quote:

Original post by Drigovas Wait, what? The entire point of multithreading is to increase utilization. If you have one thread, then on every I/O call, every cache miss, every little hickup along the way results in the processor just sitting there. Mulithreading allows you to actually do something constructive while those wrinkles get ironed out, thus increasing utilization of the processor.

My point was simple, that for real-time, there is X work you need to do per time slice.

Whether you then use 1 core or n, there's a threshold that you must meet.

While for some purposes throwing more power at it may improve the fidelity, I would venture a guess that doing the same for physics or AI would not be beneficial. For example, AI being 16 times smarter when running on 16 times as many cores would bring little benefit. Same for physics accuracy, where two different computers would run the simulation completely differently.

And here is the core of the problem. If an algorithm behaves the same, except once utilizing 1 core, and on other occasion 4, in all cases 100% utilization total, then it makes sense to use the "faster" algorithm, since there's no difference in end result.

Expanding field of view may help, but there GPU becomes the problem, and again, there is a minimum distance to which one must be able to process to make things playable, and that turns out to be the required distance.


Obviously having more power (either single core but very fast, or n cores) is beneficial. But the defining factor in how much can be done will always be the minimum requirements.

At very least for with current game genres. Again, my reply was based in context of game engines. For scientific computing, clusters have been a reality for a very long time. Real-time however is still about the LCD. In case of consoles, all consoles happen to offer same resources, so worrying about scalability may not necessarily be beneficial, as long as given resources are adequately utilizied.

Well, I'd chime in with the thought that you shouldn't undershoot your product just because you want to run on a single core machine (or dual core.. or whatever your lowest target is). Just because you want the game experience to be the same for everyone doesn't mean that you can't make the system scale.

16x the AI processing? usless? nope. Just don't design your campaign around it. Someone is going to come along and mod the game (if you designed it right) and they are going to be all: "i got this nice 256core processor, I bet I can drop in a million guys in this level!". And if you didn't write your code to scale, well nope, they can only put 40 guys in the level, cause your AI only ever ran on one core.

Just because you have the processor power, doesn't mean you have to use it, but you should be able to scale to use it so that your engine/game can grow with the hardware.

Quote:

Original post by stonemetal Second Most high-end renders are software based since hardware isn't 100% accurate.

You got to be kidding?

On what do you think the software solution runs on? air? mind?, no it runs on hardware, the accuracy the GPU and CPU have these days is the same, they both do float and double if you ask them to.

The GPU used to not be flexible enough and didn't support floats in those days, but that has changed.

And you seem unaware that there is SGI hardware that goes with there software.

Quote:

Original post by Drigovas On the note of future architectures, machines are only going to get more cores. We are pretty much butting up against the Ghz' limit, and can earn a lot more in terms of performance by adding more weak processors instead of making the processors that are already there stronger.

Your partly right, processor will be getting more cores, for now and for some years, but that like all other method of improvement, it will see diminishing returns and so the trend will end.

About the Ghz limits, thats not true at all, you can take any 3.2 ghz quad core intel has and overclock it to 4 ghz. If they wanted to, they could sell all steps up to that. They don't do it in part because of what you point to next, it's more efficient to do it with more core, to be correct, it's much easier for them, less for the software programmer. They will reach the same limit the GPU maker are reaching with this, power input, output.

Once they have reached enough core/thread active, what will they do? does any other easy solution exist?

There are many ideas to get the most from a multicore architecture. As some already pointed out, rendering is not an area that you want to do in a multithreaded way because everything gets serialized once it's sent to the GPU. Anyway, you can prepare everything in multiple threads.

When I was at the GCDC last year, Intel/Crytek did a talk on how they used multithreading in the CryEngine2 game engine (see here). At the Paris GDC this year, Lionel Lemarié did a talk on how to take advantage of the multicore architecture to handle game tasks. You can also find many gamasutra articles that deal with this particular subject.

All of these article assumes something: you don't deal with multithreading at the rendering level, but at the game engine level. This way, you're free to do whatever you want.