Lots of drama and news in the world of NVidia’s PhysX GPU-Accelerated physics simulation toolkit. It all started earlier this month with an interview with AMD on game development and DirectX11 support where AMD has, of course, taken the lead since NVidia has no DirectX11 hardware available (yet). The comment was something like this:
The other thing is that all these CPU cores we have are underutilised and I’m going to take another pop at Nvidia here. When they bought Ageia, they had a fairly respectable multicore implementation of PhysX. If you look at it now it basically runs predominantly on one, or at most, two cores. That’s pretty shabby! I wonder why Nvidia has done that? I wonder why Nvidia has failed to do all their QA on stuff they don’t care about – making it run efficiently on CPU cores – because the company doesn’t care about the consumer experience it just cares about selling you more graphics cards by coding it so the GPU appears faster than the CPU.
Basically they accuse NVidia of crippling PhysX, reducing it to a single CPU core so that it ‘appears’ faster when run in combination with a GPU. NVidia was quick to refute the claims in a response by Nadeem Mohammad, PhysX director of product management.
I have been a member of the PhysX team, first with AEGIA, and then with Nvidia, and I can honestly say that since the merger with Nvidia there have been no changes to the SDK code which purposely reduces the software performance of PhysX or its use of CPU multi-cores.
Our PhysX SDK API is designed such that thread control is done explicitly by the application developer, not by the SDK functions themselves. One of the best examples is 3DMarkVantage which can use 12 threads while running in software-only PhysX. This can easily be tested by anyone with a multi-core CPU system and a PhysX-capable GeForce GPU. This level of multi-core support and programming methodology has not changed since day one. And to anticipate another ridiculous claim, it would be nonsense to say we “tuned” PhysX multi-core support for this case.
So they basically say that thread management is left up to the developer, so whatever situation AMD witnessed was not NVidia’s fault but rather the fault of the programmer that developed it. (Probably hoping it was an internal AMD engineer). Of course, the bulk of this entire argument is that AMD wants to break NVidia’s grip on GPU physics simulation so that their own Bullet product will have an easier path to market.
Sadly tho, Bullet is still unreleased and under development. This means that developers will have to stick with what’s available, and in a new announcement from the developers of RayFire, the popular 3dsMax shatter & physics simulation tool, that means PhysX.
Hey everyone.
Well, what can I say, RayFire Tool 1.49 Beta with 64 bit PhysX support is ready to use.
Due to some new PhysX plugin restrictions some old features are not available atm, that is why it is 1.49 Beta. For now there is no Glueing and Imposible to use Grouped objects. But the most needed features like dynamic simulation and Interactive demolition work fine.
Can’t wait to see what it does when it’s fully released.
NVidia’s Response, refuting the claims via exPreview and TomsHardware
@szlevi
1) I don’t see where I claim it’s the “only available physics middleware”. It is, to my knowledge, the only free widely available GPU-accelerated physics engine, as Havok is pretty pricey and Bullet is non-GPU Accelerated right now.
2 & 3) True, you got me there. Although, the currently available version is not GPU accelerated, which was kinda the point of the article (and VizWorld in general).
Hate to do this but you’re wrong on almost all counts:
1. you know, for a “visualization scientist” to claim ‘PhysX is the only available physics middleware’ borders being hilarious… first and foremost Intel’s Havok is a fully professional package that’s not only older but probably more popular than PhysX (not sure, juts guessing) and, of course, there other, lesser known/newer projects as well.
2. Bullet is *not* AMD, it’s an independent open source project, led by Erwin Coumans, currently at Sony, former Havok dev. AMD simply supports it, just like they support Havok etc – Bullet’s main bulletpoint 😉 is probably its open source/MIT license, something you’ll never see from Nvidia
2. Bullet is *available* for long time now – one would think a “scientist” knows the difference between v0.xx/not released/beta and under development/v1.xx and higher, stable and dev releases etc.