Seems as though Silent Guy's predictions are going to be on the money.
I wonder how quickly they will be able to port it to CUDA? My guess is very fast. Perhaps on DX10 GPUs acceleration wont be as robust as with DX11, but I can't imagine they won't have something fairly soon.
I'm amazed; it seems as though everyone here is reading something different than I am into NVIDIA/Ageia's public comments. At least the spin from xbitlabs on their own interview is much more compatible with what I'm saying:
http://www.xbitlabs.com/news/multim..._with_Dedicated_Physics_Processors_Ageia.html
I think the fundamental difference in points of view emerges from many people's assumption that PhysX could be ported fully or mostly to CUDA. Errrrr, no. Havok FX can only do one thing: approximate effects physics. There's a very good reason why it doesn't handle more than that: because it couldn't. And that's with plenty of help from the CPU already!
For those interested in the technical details, there's this pretty nice presentation about it:
http://www.gpgpu.org/s2007/slides/15-GPGPU-physics.pdf - the limitations are pretty much as such:
- Integration on the GPU.
- Broad phase (detecting potential collisions) on the CPU.
- Narrow phase (verifying potential collisions) on the GPU for rigid objects but approximated using a "proprietary texture-based shape representation".
- GPU->CPU feedback is really low to improve scalability.
Particles are likely a slightly optimized path where at least one of the two rigid objects is a sphere (->easier), and fluids/cloth/etc. are likely complete separate code paths.
So I'm sorry, but that's so far from being a full physics API it's not even funny. And no, you couldn't port a full physics API to CUDA anyway; the problem is that there is no MIMD control flow logic anywhere on the chip and the PCI Express latency is too high. The PhysX chip is quite different there: many units are basically MIMD (although Vec4) iirc, and there are control cores and a full MIPS core. Larrabee will also handle that problem via on-core MIMD ALUs (since it's a CPU with vector extensions and some extra logic, not a traditional GPU).
The reason why Havok FX is so fast also isn't just the GPU's performance, but also that proprietary texture-based shape representation. I like the idea (a lot), but it's not very precise (by definition) and couldn't be used for anything else. I'm also not sure who owns that IP (NV? Havok?) - either way, I do feel that this is something that's missing in the PhysX API and a new special-purpose path for that would nearly be necessary.
Ideally, in the short-term, NVIDIA would give away a free CUDA-based effects physics mini-engine (with an optimized CPU path eventually?) that developers could use for free and easily integrate. However, one possibility is they'll just extend the PhysX API and add that, forcing everyone to use PhysX if they want to benefit from it. There are both advantages and disadvantages to that approach.
The goal in the longer-term would be to implement a more correct narrow-phase and do broad-phase on the GPU too, along as with more advanced functionality than just basic rigid bodies. This would require on-chip MIMD control ALUs/cores. What I've been trying to imply is that I suspect that's NV's plan in the DX11 timeframe; otherwise, their benefit from the PhysX API would be near-zero. You just can't accelerate much if any of what's currently in PhysX on modern DX10 GPUs.
It is also from that perspective that I suggest it would be a significant disadvantage *not* to release another PPU, because then the PhysX API will likely have become even more irrelevant by 2H09/1H10 when you might be able to accelerate it directly on the GPU. And that'd make the acqusition effectively useless - not a very wise move...