http://www.ageia.com/technology.htmlPerhaps it won't be so processor intensive in the future.
The principle is the same as the Math Coprocessor.
Basically, the thought behind it is:
If Graphics Processors can take offloaded vector calculations from the processor and
Math Coprocessors can handle offloaded floating point calculations from the processor
Why can't something offload physics calculations from the processor?
Currently in games, vector processing for 4d (don't ask, but yes, it is 4d vector calculations due to rotations about a 2d axis plane (the monitor, 'player point of view')) is done by the GPU (Graphics Processing Unit) located on the graphics card.
Most of the rest is done by the processor.
It is estimated that something like 45% of the work done by the processor is simulated physics within the game environment. Collision Detection and Reaction is a HUGE amount of the 'physics' work. This physics chip is designed to offload that work.
Hey! I added something intelligent to a conversation

I personally don't really game anymore, but I have studied 3d game programming (primarily in C++ with vector processing algorithms, collision detection algorithms as opposed to world design and graphics design... basically from a programmers stand-point, not a graphic design stand-point) and design fairly extensively and read a few very good books on the subject. Basically, the only thing I see as a problem is communication between the processor and physics coprocessor. It will add delay as it will have to communicate via a bus of some sort. The PhysX chip will have to be compatible with existing architecture which means that regardless of how fast your processor is or how fast the PhysX chip is, they will still have to communicate across a fixed length bus (I believe current lines are 64 line bus's but I might be wrong) therefore, regardless of the speed of the processor and the physX chip, you are still limited by the speed of communication between the two. Additionally there will have to be protocols in place specifically for the communication between the two which will be sort of a "interpret -> decode -> transmit -> decode -> interpret model which could result in additional overhead between the two. Then the GPU will have to be able to communicate simultaneously with the processor AND the physics chip. Since it has to be backward compatible with existing technologies, the only way to do that is to have the physX chip communicate to the GPU in the same language as the processor AND along the same bus as the processor, which means the GPU could very well get bogged down in the additional communication.
I have not seen how they have addressed these problems in communication and am leary of jumping in and saying yes, this is great. I have not seen their communication model (which I am sure is proprietary).
Oh... well... sorry for rambling.... I guess I am saying, it is a really neat idea if it is implemented properly.
Sorry for all the technical talk, I'm a computer programmer, it's what I do bestest! <tigger>
Jessica