Quote:Famous last words

Yeah, I hear you.

It does have a few things going for it. To PS2 engine programmers, it should look pretty familiar. To PC programmers, it's probably like a bad dream :) But IBM is heavily invested in Cell, and their big payback isn't the PS3 but in supercomputers, servers, render farms, research programs... and they have a big interest in teaching the programming public as much as possible.

IBM has a bunch of very informative articles about cell, along with a full system simulator, so that people who don't have the processor yet can start writing code.

Quote:Non-static geometry would be cool though. Like in the old all-CPU games. But then again, DX10 has been specifically designed for that

I'm not sure what support DX10 has, but I'm sure it's still a one-way street. With Cell, instead of the huge bulk of processing power being used to generate an image, it can be used to generate the game. Besides rigid-body physics, you could use it to do more proximity queries, line-of-sight tests, real-time terrain erosion, cloth, water, swaying trees, particles that collide and iteract, better pathfinding, animating raytraced sky textures, simply put-- anything. The computation feeds back into the game.

And each of those individual things may seem trivial, but combine them... proximity queries, LoS, and pathfinding, and suddenly you have a way smarter AI that has the cycles to evaluate the terrain, run back and duck behind a tree for cover. Or twenty of them in a team. Communicating. Each aware of everything around. Believe it or not, but most AI cycles are spent just in evaluating what's around rather than figuring out what to do next!

And, (my original point) the only way to get all this is with lots of super-fast memory and huge bandwidth. Just adding more cores or increasing Ghz is like upping the speed limit on a road that has a stop sign at every block.

[Edited by - ajas95 on January 2, 2006 3:30:03 AM]

Well, two things.

First, there are two categories of tasks-- things that are processing bottlenecks and therefore are worth spending time optimizing, and those tasks that aren't processing bottlenecks and aren't worth optimizing in the least. Most tasks aren't worth optimizing, BUT some are. In fact, in the days I was doing demos I found it was best to focus on a single hard problem... optimize the crap out of it and make it look better than even commercial games, and make that the focal point of the demo ignoring everything else.

Second, in a multi-processing environment, there is another consideration called a "dependency chain" (this might be familiar if you're into asm). Where if task C depends on task B, which depends on task A, and they can all run concurrently with task D.... Even though A, B and C individually take less time than D, their combination can be the bottleneck; therefore optimizing D before A,B,C is pointless. This can be very complicated and more importantly, this "dependency chain" concept won't go away in 10 years or 100 years, and even given a million processors the algorithm will never run faster than the combined duration of A, B, and C on a single one.

Only one thing is certain for the next 10 years: Processors won't get faster, there will simply be more of them. So if you want to take a future-proofing approach to design, your best bet is study concurrency within a frame. Figure out which tasks can execute independently and which tasks form dependency chains... the goal is to get many tasks executing at the same time, shortening the longest dependency chain.

Here's an example. Say you want to do stencil shadows. Well, the dependencies looks something like-- first game logic has to run so all characters know which animations to play, then all skeletons are computed from the animation data, collision detection and resolution execute and IK dynamics are applied so the final skeleton is known, the shadow mesh has to be skinned and only from THAT can the silhouette be computed and the stencil shadows rendered! Your goal (10 years from now) isn't to make each of those things run faster, it's to figure some way to make most of them run at the same time. Much harder stuff, your brain is important here, programming language is irrelevant.

The CELL processor only performs really well on pipelined SIMD data problems where it can make use of the capabilities of the SPEs (the hyped 'theoretical 256GigaFlops). There are more than a few game problem spaces that can make use of this, but there are many that cannot.

Alot of AI processing is not pipeline oriented and faces the "dependency chain" problem mentioned above (waiting for semaphores...). As I mentioned before, real AI in games will have requirements for CPU that will DWARF the physics/graphics needs. Irregular access to a large data space (both world data AND script code) requires the SPEs to constantly access the main memory data bus which causes constant delays (each SPE only has 256KB data/instruction store, so has limited use for batched local data processing jobs). Irregular processing suddenly causes the CELL to perform at a tiny fraction of the special cases.

A non SIMD oriented design might allowed 50% more processors in the same space.
OR
A larger data store per CPU might significantly increase the versatility for more irregular processing ( but how much is ever enough??).

Intel is also working on multiple CPU on die (supposedly 16 CPU versions are already being tested). I havent seen the spec yet for that design, but it probably wont be any 'Solves All' solution either.