Valve makes quad-core relevant to gamers

[RepoMan]

Sweet! Go Valve! (http://www.bit-tech.net/gaming/2006/11/02/Multi_core_in_the_Source_Engin/1.html)
"We gravitated towards creating a custom work management system that's designed specifically for gaming problems - its job is to keep the cores 100% utilised. We make it so that there are N-1 threads for N cores, with the other thread being the master synchronisation thread. The system allows the main thread to throw off work to as many cores as there might be available to run on, and it also allows itself to be subjugated to other threads if needs be."

The engine uses lock-free algorithms to solve one of the major problems of threading - access to data.
Check out the scalable raindrops! (http://www.youtube.com/watch?v=EwD6u960joI&eurl=) The demo on the left.

Also note that this fine-grained strategy sounds like it mainly works with symmetric core designs like the 360 and unlike the Cell. Wonder what they'll do for Cell... hope they talk about it at some point :-)

[Linoleum]

Vectorizing their particle renderer is not making that engine multi-threaded.

Also note that this fine-grained strategy sounds like it mainly works with symmetric core designs like the 360 and unlike the Cell. Wonder what they'll do for Cell... hope they talk about it at some point :-)

I am envisioning vSPE and giggling helplessly. An HP Lovecraft kind of giggling, not the giddy schoolgirl kind.

[Qenan]

I think maybe we should await benchmarks showing this actually works well. And a few more games.

[RepoMan]

Shit, tough room. Seems to me the article talked about parallelizing (coarsely or finely) a lot more than just the particle renderer.

[Jason Cross]

Shit, tough room. Seems to me the article talked about parallelizing (coarsely or finely) a lot more than just the particle renderer.

It is, and they are. The simple benchmark app they have now really only stresses particle systems, but the system they have developed for doing multicore optimization is a whole lot more than just that. Loyd did an article on ET about it as well: http://www.extremetech.com/article2/0,1697,2050563,00.asp

[mouselock]

It is, and they are.

Yet there's no substantive example of them doing this. Instead they fall back on parallelizing trivial things like particle engines (as a benchmark, no less!) which epitomizes the OpenMP, data-driven parallelization paradigm and doesn't really address the core difficulties they've talked about.

It's not that I don't believe that they're doing it; rather it's that both articles give zero indication of them doing it other than them saying "We're doing it!" The impact to gamers is a far way from being seen, no matter how many raindrops their new benchmark can draw.

(On the other hand, I look forward to being able to code a Source engine mod that allows me to run my MD code easily. Now to make it look like a game somehow so that everyone will download the mod unknowingly and contribute mad processor cycles to my further quest for scientific insight! :P )

[Jason Cross]

Yet there's no substantive example of them doing this. Instead they fall back on parallelizing trivial things like particle engines (as a benchmark, no less!) which epitomizes the OpenMP, data-driven parallelization paradigm and doesn't really address the core difficulties they've talked about.

They're mixing fine-grained parallelism on stuff where it makes sense (particles) with coarse-grain parallelism where it makes sense (they're giving the sound engine its own core).

Here are some other concrete examples of where they're splitting off work to other threads:

- constructing scene rendering lists in parallel (example - the main world and its reflection in water)
- overlapping the graphics simulation stuff (ropes, sprites, particles)
- parallel computation of character bone transformations in the animation system
- a separate thread for computing character/actor shadows
- letting multiple threads "draw" in parallel, and then having another core serial-ize them so you can send them to the renderer in the expected serial fashion
- computing AI and pathing with multiple threads for mutliple AI objects

Certainly their current benchmark is a limited example, and focuses on particles. But Valve says that even the current HL2: EP1 and such should see some measure of performance improvement when they push the Source engine update, and HL2: Ep2 will scale really well on multi-core CPUs. We'll just have to wait for that to see the real fruits of it - but what they talked about went well beyond splitting out particle systems.

[stusser]

That's all pretty interesting, but are we to believe that epic and id and netimmerse and the rest of the big licensed engine developers totally missed the writing on the wall? It's been obvious for over two years that multicore is a big deal. Seems to me that valve just has better PR.

[wumpus]

HL2: Ep2 will scale really well on multi-core CPUs
Ooh, good thing, because last time I checked, HL2: EP1 already ran at 60fps on any garden variety sub-$100 single core CPU. This is just silly. The GPU is, except in the most absurd and extreme scenarios, always the bottleneck for gaming.

I do think dual core is a nice step forward for multitasking in general, even though it does virtually nothing for your framerates in Half-Life 2 at typical gameplay settings. But quad core goes far beyond the point of diminishing returns into utter absurdity.

[Malderi]

The engine uses lock-free algorithms to solve one of the major problems of threading - access to data.

Alright, I've done some single-thread and multi-threaded programming in my time, but I have no idea what the heck they mean by "lock-free algorithms". Locks (or mutexes or whatever you want to call them) are necessary to prevent race conditions. How are they getting around that?

[Fugitive]

Lock-free algorithms (http://en.wikipedia.org/wiki/Lock-free_and_wait-free_algorithms)

Short version: The data is structured so that it can be passed off between owners (i.e., separate threads) with atomic instructions.

[RepoMan]

This is just silly. The GPU is, except in the most absurd and extreme scenarios, always the bottleneck for gaming.
Um, no. Several years ago the CPU was commonly the bottleneck, back before engineers started optimizing for polygon throughput.

One of the main points of the article (did you read it, by the way?) is that once you can use more CPUs / cores, you can easily find things to do with all the CPU. They specifically call out more gameplay-interactive physics and much more AI. Sure, Half-Life 2 is GPU bound, because it was designed that way. Half-Life 2 episode 2 and beyond? The equation might start to change quite a lot.

So yes, in recent history most games may have been GPU bound. But that may have been because the CPU was actually lagging behind the GPU power-wise. Multi-core CPUs will make the CPU be much better utilized, and eventually hybrid CPU/GPUs (also discussed in the article) will make the very distinction itself start to blur.

[RepoMan]

Seems to me that valve just has better PR.
Well, assuming that any PR is better than no PR... :-)

Sure they're probably all doing it. But this thread is to discuss what Valve (the one company that is actually talking about it) is saying.

[wumpus]

Several years ago the CPU was commonly the bottleneck, back before engineers started optimizing for polygon throughput.
Yes, before there were 3D cards. I remember upgrading from a GeForce 1 SDR to a GeForce 1 DDR and seeing my framerates double. I cannot recall the last CPU upgrade that caused my in-game framerates to double.

Sure, Half-Life 2 is GPU bound, because it was designed that way. Half-Life 2 episode 2 and beyond? The equation might start to change quite a lot
Unlikely. 3D graphics rendering is inherently and highly parallel. AI and physics.. ain't. That's why quad-core chips do so well on a teeny-tiny subset of all computing tasks, eg, rendering. For everything else they're a complete wash.

Multi-core CPUs will make the CPU be much better utilized
Hardware isn't the problem. Dumping a 32-core 3 GHz CPU in a programmer's lap doesn't magically make your game 32 times faster overnight. The human being part of the transition will take at least a decade, if not longer.

http://software.ericsink.com/entries/LarryO.html

[AndrewM]

Tim Sweeney of Epic gave am interesting talk in January on what new programming languages could do for game development, including concurrency:

http://cag.csail.mit.edu/crg/papers/sweeney06games.pdf

[Igor Muravyev]

"We realised that, 95% of the time, you're trying to read from a data set, and only 5% of the time are you actually trying to write to it, to modify it. So, we just allowed all the threads to read any time they want, and only write when the data was locked to that thread."


Valve re-invents read/write locks, and this is news?

[Becoming]

I was under the belief that the Source engine is in fact very cpu bound due to all the physics interactions and so forth, so this would be great (at least once I upgrade). It may be more apparent in some of their games than others (go play CSS online and play with the settings and tell me it isn't cpu bottlenecked), but that was always my impression.

[MatthewF]

I was under the belief that the Source engine is in fact very cpu bound due to all the physics interactions and so forth, so this would be great (at least once I upgrade). It may be more apparent in some of their games than others (go play CSS online and play with the settings and tell me it isn't cpu bottlenecked), but that was always my impression.

But multi-core is specifically designed to improve games that multi-thread. Stopping short of dedicating an entire core to physics, this isn't really going to matter. And then of course you run into all sorts of problems keeping it all synchronous. I would agree that Source is fairly hard on the CPU, but supposedly Havok is going to move a lot of operations to the GPU, and then it becomes even more irrelevant.

[Case]

Ooh, good thing, because last time I checked, HL2: EP1 already ran at 60fps on any garden variety sub-$100 single core CPU. This is just silly. The GPU is, except in the most absurd and extreme scenarios, always the bottleneck for gaming.

I do think dual core is a nice step forward for multitasking in general, even though it does virtually nothing for your framerates in Half-Life 2 at typical gameplay settings. But quad core goes far beyond the point of diminishing returns into utter absurdity.

Then you misunderstand what they're doing. Episode 2 will not just scale well in terms of frame rate, but also because of the stuff they'll be able to add -- more realistic animations, better AI, particle systems that actually affect gameplay rather than just look pretty, etc.

[MatthewF]

Whoa, I totally fail to see how quad-core CPU's are going to improve animation. That stuff's all just keyframed as it is. Are you talking about kinematics? Because, well, a quad-core isn't going to do you any good there. That's all part of the physics core. I'd actually say the same thing about AI -- more CPU power isn't going to miraculously improve it. There have been myriad opportunities for years to write stellar AI. It's just not very easy, though, and that's the primary reason why it usually sucks. Not lack of CPU power.

[wumpus]

Episode 2 will not just scale well in terms of frame rate, but also because of the stuff they'll be able to add -- more realistic animations, better AI, particle systems that actually affect gameplay rather than just look pretty, etc.
Hopefully it'll be less underwhelming than the PhysX stuff.

Because every game will have to scale to legacy single-core CPUs for the next two years (at least), I don't see how they can make dual and quad core features fundamental and integral to the gameplay. It'll have to be fluffy stuff, exactly like PhysX.

It may be more apparent in some of their games than others (go play CSS online and play with the settings and tell me it isn't cpu bottlenecked)
Last time I played, it was heavily GPU bottlenecked. Particularly if you want HDR and antialiasing. Even if you don't, I guarantee you'll be GPU bottlenecked at 1280x1024 or higher at default quality settings. You'd have to turn down all the in-game quality settings and set the resolution to 1024x768 to hit a CPU bottleneck in the source engine.

Take Battlefield 2 as an example, which is much more demanding than Source:

http://www.gamespot.com/features/6127698/index.html?type=tech&page=4

About 1% perf difference going from a 2.8 GHz P4 to a 3.8 GHz P4 at 1280x960.

[Becoming]

Uh no? The gpu is more of a bottleneck if you turn on HDR for sure, but I can have the other regular goodies maxed or not at 1280x1024 and it doesn't matter much for framerate. When you get tons of ragdolls and physics props and whatnot onscreen (as well as dealing with the networking), the cpu takes a beating period and the framerate takes a nice dive. It is much more noticable in a larger server than say, a scrim or any other 5v5. Someone with a better cpu than mine would not take as large or any hit from that in the same situation. If one were to upgrade your cpu exclusively keeping the rest of the hardware the same, they'd notice the difference and it's fairly obvious (I've done it).

[Kool Moe Dee]

That's all pretty interesting, but are we to believe that epic and id and netimmerse and the rest of the big licensed engine developers totally missed the writing on the wall? It's been obvious for over two years that multicore is a big deal. Seems to me that valve just has better PR.

Yep. I kind of rolled my eyes at the article...there's nothing there that a bazillion other developers aren't having to work through as well.

[John Sansker]

I have read about 'em - everything I've read indicates they won't affect game performance, at least for a long time.

Heh heh heh.

[mouselock]

more realistic animations, better AI, particle systems that actually affect gameplay rather than just look pretty, etc.

Of those, only better AI actually has to do with the gameplay. And how does that work exactly?

Single core: The AI blows. The combine couldn't hit me if I had a glowing target on my chest.

Dual core: The AI's decent.. they occasionally flank me.

Quad core: Holy fuck, these guys are smarter than our current four star generals! There's no way a mere human can hope to overcome this type of AI!

How do you make something fundamentally important to the game scale? If you have a quad core the game is smarter, if you have a single core it's dumb. If you have a quad core everything is physically accurate, if you have a single core you can't take out the entire level by shooting the singular lynchpin.

If it matters in the highly parallel environment, then if you don't have that type of setup you're playing an inherently worse game from a gameplay level. If it doesn't matter, then who cares?

[Kyle Wilson]

But multi-core is specifically designed to improve games that multi-thread. Stopping short of dedicating an entire core to physics, this isn't really going to matter. And then of course you run into all sorts of problems keeping it all synchronous. I would agree that Source is fairly hard on the CPU, but supposedly Havok is going to move a lot of operations to the GPU, and then it becomes even more irrelevant.

Physics is a pretty parallelizable problem. No one without a very specialized game is going to be pipelining physics and running it on a separate core, because most games have too many interdependencies with the physics simulation. But physics can make good use of data parallelism, running physical simulation on every available core for some timeslice. Given four cores, you can probably simulate two or three times as many physical objects.

Havok isn't exactly moving a lot of operations to the GPU. They're working on a separate GPU-side physics library that can do simple simulation without most of the features of a real CPU-side physics library, like filters, callbacks, and other things that require execution of general purpose code. It's somewhere between the simplicity of particle simulation and the complexity of a full-featured physics library. I believe it's intended to be used for debris and effects, physical objects that don't interact with gameplay. And it's probably only going to be useful for people with a spare video card that they can dedicate to the task.

[Kyle Wilson]

Whoa, I totally fail to see how quad-core CPU's are going to improve animation. That stuff's all just keyframed as it is. Are you talking about kinematics? Because, well, a quad-core isn't going to do you any good there. That's all part of the physics core. I'd actually say the same thing about AI -- more CPU power isn't going to miraculously improve it. There have been myriad opportunities for years to write stellar AI. It's just not very easy, though, and that's the primary reason why it usually sucks. Not lack of CPU power.

Faster CPUs aren't going to inherently improve animation or art, but extra processing power does make possible things that we can't do today. On the animation side, extra power means we can have more characters on screen, we can make characters with more bones and we can blend more animations playing on a character at once. That adds up to more characters behaving in a more lifelike manner.

The costs of AI--at least in my profiling--are navigation searches and ray-casts against the environment, particularly the latter. The more CPU power we have available, the more an AI can afford to search his environment to plan his movements, maintain cover, and formulate strategy.

None of that means that AI characters are necessarily going to animate or behave any better than they do today. It just means that the ones driven by good animators and AI programmers will. Without CPU limitations, the difference between the best and the worst is going to be more apparent, just as faster GPUs reveal the difference between the best and the worst among artists.

[Kunikos]

Isn't Gabe Newell the person who was complaining not so long ago that multiprocessors were too difficult to be relevant to game developers and that the Xbox 360 was terrible because it had three cores? Talk about an about-face.

[LesJarvis]

Of those, only better AI actually has to do with the gameplay. And how does that work exactly?

I think you're using an unnecessarily narrow definition of gameplay, but even beyond that the bit-tech article articulates a scenario where the particle system could have an effect on gameplay (the wizard in the flaming field.) I'll admit that's not a great example, though, because as you pointed out, that kind of stuff is trivial enough that it doesn't even remotely require that much processing power. The real advantage will come when that kind of fine-grain stuff permates the gameworld. It's a simple example meant to illustrate the type of possibilites opened up by multi-core processors.

But more broadly, I think the stuff Lloyd's talking about where you quoted him does fundamentally effect gameplay, becase it effects the way people play your game and the way they perceive and react to the environments in it. Just because something doesn't change the mechanics of your game doesn't mean it has no effect on the way your game is played. I think Valve is among a relatively small number of developers who have made this realization, and I think it's a big part of their success.

How do you make something fundamentally important to the game scale? If you have a quad core the game is smarter, if you have a single core it's dumb. If you have a quad core everything is physically accurate, if you have a single core you can't take out the entire level by shooting the singular lynchpin.

If it matters in the highly parallel environment, then if you don't have that type of setup you're playing an inherently worse game from a gameplay level. If it doesn't matter, then who cares?

This is a good point, and could end up being a serious hurdle for game developers. At the same time, though, I think you're looking at it backwards. Valve, it seems to me, is not saying "Wow, now that there are quad-core cpus let's be as cutting edge as possible with them." Instead, their approach is "in 3-4 years multi-core cpus will be pretty much ubiquitous. We should start to engineer our core development platform to take advantage of that." In the meantime people with multi-core processors will have a slight performance advantage. But yeah, if this stuff is fundamentally important to how the game operates (not plays,) it's difficult to make it scale back to older single core platforms.

And to those saying that Valve isn't the only one doing this: uh, no shit? They're just the only ones who are actively talking about it with the public right now.

[MatthewF]

Faster CPUs aren't going to inherently improve animation or art, but extra processing power does make possible things that we can't do today. On the animation side, extra power means we can have more characters on screen, we can make characters with more bones and we can blend more animations playing on a character at once. That adds up to more characters behaving in a more lifelike manner.

The costs of AI--at least in my profiling--are navigation searches and ray-casts against the environment, particularly the latter. The more CPU power we have available, the more an AI can afford to search his environment to plan his movements, maintain cover, and formulate strategy.

None of that means that AI characters are necessarily going to animate or behave any better than they do today. It just means that the ones driven by good animators and AI programmers will. Without CPU limitations, the difference between the best and the worst is going to be more apparent, just as faster GPUs reveal the difference between the best and the worst among artists.

The point that I was trying to make is that even now we underutilize processing capabilities when it comes to AI, and I'd submit that there are already games capable of producing a scene with many characters playing asynchronous animations with many bones. I believe that CPU resources have been underutilized for years when it comes to AI especially, and I honestly think that quad core is going to do absolutely nothing to improve it. Start maximizing the resources we currently have available, and then we'll talk stepping it up a notch.

[RepoMan]

Isn't Gabe Newell the person who was complaining not so long ago that multiprocessors were too difficult to be relevant to game developers and that the Xbox 360 was terrible because it had three cores? Talk about an about-face.
Yeah, I noticed that too. I guess he underestimated his engineering team :-)

[Kunikos]

That and he probably likes to whine about how life is, like, hard... and stuff. Then he slowly swats a potato chip lodged in his double chin.

[Jason Cross]

Whoa, I totally fail to see how quad-core CPU's are going to improve animation. That stuff's all just keyframed as it is. Are you talking about kinematics? Because, well, a quad-core isn't going to do you any good there. That's all part of the physics core. I'd actually say the same thing about AI -- more CPU power isn't going to miraculously improve it. There have been myriad opportunities for years to write stellar AI. It's just not very easy, though, and that's the primary reason why it usually sucks. Not lack of CPU power.

If you thread out your skeletal animation system so that each character's bones are updated in parallel in various threads, you can (with multi-core CPU) handle LOTS more bones per character, for more nuanced expression. Or a lot more characters, or both. It gets to be a CPU bottleneck pretty quickly when you're blending animations together, and everyone's on a different animation, etc.

You could say that stuff is keyframed, but in many modern games with really good animation, there's a significant amount of blending and inverse kinematics going on. And I'm not sure that your general physics engine for the game is always what they use for IK - it may be something more animation-specialized.

I wish we could get Valve engineers in this thread to talk about very specific problems and implementations.

[Kunikos]

Even statically defined paths have to be calculated using complex math, since without quaternions you'd end up with some pretty jerky transformations.