ATI... 3 Card Solution for Physics

[Redeemed]

btw, what is "getting physics right?"

A lot more technical terminology than I have the brain power to willingly understand. :) :D :D

[Sound_Card]

http://www.ati.com/technology/crossfire/promotions/physics/Computex_2006_Crossfire_Press_Presentation.pdf


here is a pdf that explains the ATi/Havok approch to Phyx.


According to ATi, and the benches provided, the ATi x1k cards such as the x1600xt can perform Phyx 2 times faster than the Ageia solution. Keep in mind the x1600xt is much much cheaper. This is really good news for us ATi owners that already have a x1k series card. We won't have to throw it away, we can use it on our next system that has the Havok api. It would also seem that the nvidia cards are really not that good at phyx.

[noko]

So ATI solution creams PhyX, sounds like Aegia won't be around long. Now that was ATI spin. Microsoft is supposenly making API using GPU for physics, if so then Aegia is probably going to have a hard time advancing.

[Soylent]

So other than AI what is the CPU going to be doing once we offload GFX and physics to dedicated processors?

A CPU does a LOT more in games than just AI. e.g.:

You have to do some occlusion culling(but it doesn't need to be anything heavy weight so it's probably only a small slice of CPU usage for this).

Switching shaders, textures and other render settings costs quite a lot of CPU in DX9. Submitting batches is also quite costly. These will get better in DX10 but I don't think anyone knows by how much yet. This is a VERY important issue for DX9, as you can very easily eat most of your CPU by not optimizing your batching. Batching is more or less a sorting process, where you sort after various criteria(e.g. which vertex shader and pixel shader are to be used) and try to minimize state changes. This is often so important that you forgo sorting front to back to sort after shader use instead(often in combination with a z-only pass to get some of the benefits of sorting front to back).

The CPU has to manage resource loading. And in modern games this isn't an easy task. Preferably you wish to predict where the player is headed and asynchronously load the resources before the player gets there. This can cut out loading screens/stuttering all togheter if implemented well. This can also probably be made to eat quite a fair chunk of CPU, especially if the CPU has to do decompression or mip-mapping(the standard box filter can be done automatically on most GPU's AFAIK. But that's not always the best filter to use for generating mip-maps).

You might do high quality CPU based model skinning. If you do it in the vertex shaders you are fairly limited AFAIK. But it will work just fine for blending a couple of animations and you can even combine it with tweening for facial expressions and things which aren't practical to model with bones. Which makes it fine for most games. If you want to use an inverse kinematics method or even blend several different behaviours based on IK and tweening for facial expressions and so on with different priorities(such that lower priority tasks do not interfere with the motions of higher priority tasks) or other advanced techniques your best bet is by far the CPU AFAIK.

AI is, as you've probably noted from numerous games, is very rudamentary and it's not an easy problem to solve. Especially not detecting conflicts with other NPCs or the players in advance and attempting to move out of the way. And search algorithms like a* can eat a huge chunk of performance if you place the nodes densely and there's a lot of obstacles that a lot of NPCs need to traverse and can't be grouped(if they're grouped like in an RTS you can have them follow roughly the same path). AI is something you can easily throw CPU usage at, but clever optimizations will still be much more important to improving the quality than brute forcing it.

Keeping track of the gamestate, doing networking(closely related to keeping track of the gamestate) and user input probably isn't a big slice in most games but it's not negligible if there are a lot of gameplay entities 'touched' each frame.

If you are talking about the possible uses of the extra CPU power:

In DX9 it's a good bet that a lot of the "excess" is being eaten up by rendering lots of particles and chunks of stuff. So there might not be much of an excess in the first place or it might require a fair deal of optimization(primarilly batching I think) to get that excess.

But if you had that excess it's practically a law that giving developers more resources(across the board, not just high end) they'll eventually figure out a use for it.

And there's a lot of possible uses for an excess amount of CPU power.

The default use is to not bother optimizing a resource that's not a constraint(developers are 'lazy', AKA under an enormous pressure to ship and working obscene hours under the motto of "an aspirin a day keeps the heart attack away") until someone comes up with a real use that everyone has to have. So you can be slightly nicer to your game devs or have them spend time doing other things such as polishing the gameplay rather than the performance.

You can procedurally generate stuff on the fly(like animation of arbitrary creatures), which would have the huge benefit of animations not looking 'canned' or 'scripted'.

Simulate the gamestate of a large chunk of the game world instead of just the stuff a player touches/observes.

You can try to have the AI predict conflicts in advance instead of reactively(which would be hugely noticable to anyone who's ever played a shooter where you have to lead an NPC along in a cramped environment) or try using a more advanced model for AI behaviour rather than the extremely simple 1 dimensional behaviour in most games. You might spend more CPU on determining things like visibility and audibillity(there's nothing players hate more than being seen through walls or heard from thickly insulated places where they expect not to be).

You can have more varied objects now that your CPU is freed up to handle more batches off stuff(what you can batch is limited by the shaders, textures and render state it uses. Identical things are very easy to batch).

Eventually someone will stumble on a really cool use for whatever kind of performance you have an excess of. It kind of brings back things closer to the balance we had years ago. GPUs have been far outstripping CPUs in performance gains for many years now. So now we can afford to spend a lot of resources on each pixel, use higher resolution, AA, AF, try to simulate higher quality meshes using various hacks such as normal mapping, relief mapping, parallax occlusion mapping and using more advanced lighting and shadowing models. "So what do we do with the extra GPU power now?" has been continually solved and I don't expect "So what do we do with the extra CPU power now?" to be much different.

[Soylent]

btw, what is "getting physics right?"

If you've played HL2, or better yet Garry's mod you'll see just how bad the state of CPU based physics is. It's not nescessarily that it can't be easily done in high quality on the CPU, but it's probably too performance demanding in HL2 so they opted for low quality settings.

If you play around with garry's mod for a bit you'll quickly see a lot of odd behavior, clipping, things getting hitched on each other and shooting sparks. Things spontaneously starting to oscillating and so on. For current CPU based physics a great deal of care has to be taken to give the physics engine constraints that are easy to simulate without instabillity. That may well be the case for physX or ati's solutions as well.

But getting physics "right" probably refers to this.