Valve makes quad-core relevant to gamers

Sweet! Go Valve!

“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! 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 :-)

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.

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

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

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 )

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.

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.

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.

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?

Lock-free algorithms

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

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.

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.

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

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

“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?

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.

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.

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.