:: Back to news index ::

Archive for July 8th, 2010

PhysX SDK 3.0: automatic multi-threading

with 16 comments


As everyone else, we have very little information about next major release of PhysX SDK 3.0, which was rumored as complete rewrite of current SDK, full of new features and extended capabilities, currently kept under straight NDA.

UPDATE: PhysX SDK 3.0 has been released

However, few pieces of information are beginning to leak:

Today, as answer to all the hype about PhysX and SSE instructions, Nvidia’s senior PR manager Bryan Del Rizzo has stated in interview to website, that new SDK 3.0 will feature “a task-based approach that was developed in conjunction with [Nvidia] Apex product to add in more automatic support for multi-threading“.

In generally, SDK 3.0 will automatically take advantage of however many cores are available, or the number of cores set by the developer, and will also provide the option of a “thread pool” from which “the physics simulation can draw resources that run across all cores“. – adds

We will keep an eye on all SDK 3.0 traces and post new info as we’ll find it.

Written by Zogrim

July 8th, 2010 at 3:13 pm

Posted in PhysX SDK

Tagged with ,

PhysX Research: Real-Time simulation of Large Bodies of Water

without comments

Another paper called “Real-Time Simulation of Large Bodies of Water with Small Scale Details” (you can find previous one, Wrinkle Meshes, here) has arrived from Dr. Matthias Müller-Fischer, PhysX SDK research lead at Nvidia Switzerland.

Paper is decribing hybrid grid- and – particle based fluid solver used in latest, and technically most impressive, demo from Nvidia – Raging Rapids Ride.


We present a hybrid water simulation method that combines grid based and particles based approaches. Our specialized shallow water solver can handle arbitrary underlying terrain slopes, arbitrary water depth and supports wet-dry regions tracking. To treat open water scenes we introduce a method for handling non-reflecting boundary conditions. Regions of liquid that cannot be represented by the height field including breaking waves, water falls and splashing due to rigid and soft bodies interaction are automatically turned into spray, splash and foam particles.

The particles are treated as simple non-interacting point masses and they exchange mass and momentum with the height field fluid. We also present a method for procedurally adding small scale waves that are advected with the water flow. We demonstrate the effectiveness of our method in various test scene including a large flowing river along a valley with beaches, big rocks, steep cliffs and waterfalls.

We still hope that this solver will make it into next, 3.x release of PhysX SDK.

In addition, demonstrational video is available (61 mb)

Written by Zogrim

July 8th, 2010 at 2:05 pm

Posted in Articles, Reviews, PhysX SDK

Tagged with ,

PhysX: x87 and SSE

with 11 comments

David Kanter from in his “PhysX87: Software Deficiency” article has hypothesized that origin of slow execution of PhysX content on CPU is fact that PhysX SDK is mostly based on x87 rather than faster SSE instruction set.

“On modern CPUs, SSE can easily run 1.3-2X faster than similar x87 code” – stated Kanter.

However, TGDaily has managed to recieve commentaries from Bryan Del Rizzo, Nvidia spokesperson

[And although] our SDK does [include] some SSE code, we found [that] non-SSE code can result in higher performance than SSE in many situations. [Nevertheless], we will continue to use SSE and plan to enable it by default in future releases. That being said, not all developers want SSE enabled by default, because they still want support for older CPUs for their SW versions.

Update: official responce from Nvidia – We’re not hobbling CPU PhysX

Update #2: some more Nvidia statements at this ars technica article

Update #3: and more at article “NVIDIA Sheds Light On Lack Of PhysX CPU Optimizations

But lets get back to original article. According to David, sole reason for PhysX SDK to rely on outdated x87 instruction is to make “Nvidia GPUs looks a lot better than the CPU“. This idea was inherited other websites, like

The PhysX logo is intended as a selling point for games taking full advantage of Nvidia hardware, but it now may take on a stronger meaning: intentionally slow on everything else.

and Semi Accurate

In the end, there is one thing that is unquestionably clear, if you remove the de-optimizations that Nvidia inflicts only on the PC CPU version of PhysX, the GPU version would unquestionably be slower than a modern CPU.

Unfortunately, previous authors are missing few vital points: PhysX SDK is used in many games running on CPU, and physics level in those titles can be easily compared to physics content in games based on other “non crippled” physics engines, like Havok; nor there are any games, that can offer content, similar to GPU PhysX effects, but running on CPU with stable framerate.

And, most important, GPU can accelerate only few parts of PhysX code – rigid bodies, joints, raycasts, forcefields, broadphase, etc – rely purely on CPU, so what is the reason not to optimize those at the full potential, to make PhysX SDK more attractive for developers (and thus increase number of  games with GPU PhysX support) ?! Something is telling us that reason “just to make GPUs look better over CPU” is not so obvious.

And what do you think ? Tell us in comments.

Written by Zogrim

July 8th, 2010 at 12:47 pm

Posted in Articles, Reviews, PhysX SDK

Tagged with ,

Copyright © 2009-2014. | About project | Privacy Policy
PhysX is trademark of NVIDIA Corporation