A Closer Look At PhysX: Our Take On The PPU

Game Physics and the PhysX PPU

One of the properties of graphics that made the feature a good fit for a specialized processor inside a PC is the fact that the task is infinitely parallelizable. Hundreds of thousands, and even millions of pixels need to be processed every frame. The more detailed a rendering needs to be, the more parallel the task becomes. The same is true with physics. As with the visual world, the physical world is continuous rather than discrete. The more processing power we have, the more things we can simulate at once, and the more realistically we can approximate the real world.

But as we’ll see, there is more to it than simply parallel compute power.

In the beginning there was collision detection, and it was good. And then came some semblance of gravity. Over the years, more and more objects in the game world have become interactive and affected by the world around it. Now the game physics world has culminated in the ability to bowl for oil drums with floppy dead people.

Fast, efficient, rigid body simulation has been well developed over the past couple years. A rigid body is basically a single unit that does not deform due to physical interaction. Think of two billiard balls slamming into each other: the balls retain their shape. If one were to drop a billiard ball on a beach ball, we would see a much different reaction: the beach ball would contract and expand a great deal. In current games, we would treat the beach ball, and indeed everything else, as a rigid body object.

Any rigid body object can have a number of forces acting on it at a time depending on the complexity of the simulation. Each object also has its own properties that are used to determine how these forces affect the object. This can scale from simple (mass and shape) to complex (like data to describe how shape and mass distribution affect angular velocity) depending on how accurate the developer wants to make things.

Not much interesting happens if a rigid body is sitting on flat ground and not moving with nothing touching it. Interesting things start to happen when either the user interacts with an object, or multiple rigid bodies interact with each other. We can easily see how these interactions could get complex. Think of bowling or billiards. Now think a little more complex. What happens when a rocket hits a brick wall and all the bricks go flying? Currently, games generally use tens to about a hundred rigid body objects in any given scene. This is somewhat limiting when the game calls for large scale effects or destruction.

So, here’s the real question. Why won’t Intel’s vision of multi and many-core processors be good enough to handle what a discrete PPU could handle?

Of course more parallel processing power will help no matter how it comes. But the deeper issue is data movement. The example AGEIA gave us to think about was a huge pile of bricks; when you push down on one brick near the top, forces are transferred to all other bricks in the stack. This may not be difficult on the scale to hundreds, but how about 30000 objects in a stack? How about keeping track of that while handling deformable (soft body) objects, fluids, and all collision detection in the scene?

The was all this needs to be handled is not simply with lots of parallel independent floating point power, but with lots of parallel floating point power connected by huge bandwidth. The fact that some initial Intel dual core chips will have to go off chip and back on to communicate, not as much performance is gained as possible. Certainly more parallelism is better no matter what, but it’s the high bandwidth that clenches the deal.

AGEIA’s background is in switched fabrics and networking hardware. The one of the keys to their chip is in the way PhysX is able to move high volumes of computed data internally. In order to find the forces on a brick in the middle of a stack that’s been kicked, the forces on all the bricks around it need to be updated.

Getting data into and out of the chip as fast as possible is important as well. For now, AGEIA is sticking with GDDR3 in order to benefit from the high volume (and lower costs) generated by the graphics market. It would be possible for the PhysX to benefit from higher bandwidth solutions like XDR, but for now it is important for AGEIA to minimize the cost/benefit ratio in order to succeed. The company philosophy at the outset is to follow what the graphics market does in terms of on card RAM.

We really don’t know a great deal about the intimate details of the architecture, but a light weight parallel floating point with lots of communications is a good start. We’ve had several guesses at how the hardware works that have been confirmed wrong. But to paraphrase Edison, eliminating all incorrect paths leads to the goal.

It does seem obvious that all physical properties of objects can be uploaded to the hardware initially (like a graphics card does with textures and such) and manipulated/updated every time something changes. We’ll be bringing out as many details as we can as soon as we are able.