:: Back to news index ::

Multithreaded performance scaling in PhysX SDK

with 6 comments

Recent “The Evolution of PhysX” article has unvealed the current situation with performance improvements among various PhysX SDK vesions, however, one interesting case has remained outside the coverage – performance scaling in multithreaded environments.

It is known that, while PhysX SDK 2.8 has rather limited multi-threading capabilities (mostly working on per-scene or per-compartment basis), PhysX SDK 3.x can distribute various tasks across worker threads much more effective, and thus offer better support for multi-core CPUs.

But how well does multi-threading actually work in PhysX 3 (we’ll take the latest 3.3 version)? Using the same PEEL (Physics Engine Evaluation Lab) tool to the record the performance metrics, we will try to shed the light on this question.

Scene #1 – random dynamic primitives in a box

Static container filled with 256 random primitives (sphere, box, capsule).

Scene #2 – random falling convexes

1728 convexes (12×12x12 formation) falling on a plane, forming a pile. Each convex is randomly choosen from 14 predifined objects, of various complexities.

Scene #3 – convexes falling on triangle mesh

4096 convexes (64×64 formation) colliding against tesselated triangle mesh (743 616 triangles in total).

Scene #4 – stacking test with boxes

10 medium-sizes box stacks (10 boxes wide basis).

Scene #5 – spherical joints net

Net, consisting of 40*40 spheres connected with spherical joints, colliding against static object.

Scene #6 – 256 dynamic ragdolls

256 ragdolls, each one comprised of 19 bones connected with hinge joints.

As you may see, multi-threading in PhysX SDK 3.3 is indeed functional and fairly effective, showing significant performance improvements in case of convex-convex collisions (2x times faster in average, 3 threads vs single thread) and stacking (1.88x faster), and lesser, but noticable performance gains in case of collisions between primitives (1.5x faster) and joints (1.2x faster) calculations.

As a downside, additional worker threads are increasing the memory footprint of the scene.

Also, we have discovered that Scene Queries (such as raycasts and sweep tests) are showing same performance regardless to the number of threads.

In any case, improved multi-threading capabilities of PhysX 3.x are making it even more consistent and futureproof, especially when compared with previous generation of the PhysX physics engine.

Appendix #1:

SDK 2.8.4 settings - default, 1 thread. SDK 3.3 settings - default, SAP broadphase, legacy contact generation, 1 - 3 threads.

System: i7 2600K CPU, GTX 580 GPU, 8 GR RAM, Win 7 x64

Written by Zogrim

May 12th, 2013 at 11:08 pm

6 Responses to 'Multithreaded performance scaling in PhysX SDK'

Subscribe to comments with RSS

  1. Hi. Thanks for testing. I want to know why you used only 3 threads and no more. Few moths ago I was speaking with a man who is using PhysX (in that time SDK 3.2). He told me that PhysX has a problem with efficiency in using more than 4 threads. He told that in that way Havok is better. So it should be interesting to test this because in this article we can see that more threads bring us less gain. As we can see there is only small difference just between 2 and 3 threads.



    13 May 13 at 11:24 am

  2. mareknr: I want to know why you used only 3 threads and no more

    PEEL version I have only gives me option to choose between 1-4 threads.
    And with 4 threads it gives me some strange results, but this may be related to how PEEL mahages rendering/physics on my particular 4-core CPU.

    So I decided to go with 3.

    Also, in my opinion, it is more real life situation, since I don’t think many games will have an option to dedicate more than 4 threads only for physics.

    As for possible “issues” with many threads, I’ll try to ask around

    Upd – answer: PEEL was developed and tested on a 2 core machine. Hardly anybody will dedicate more than 3-4 threads to physics anyway and it was not requested so far. However, if any issues with many threads will pop-up, they will be fixed.

    If that “man” of yours requires such functionality, I can try to get him in touch with PhysX devs.



    13 May 13 at 11:41 am

  3. I spoke with him only once some months ago. This was the information which I remembered. I don’t know him but thanks for offer.

    And what about Havok? Does it use more than 4 threads or there is same situation as with PhysX?



    16 May 13 at 11:34 am

  4. mareknr: Does it use more than 4 threads or there is same situation as with PhysX?

    I can assume that actualy usage cases/demand for multithreading in games are pretty similar, but they indeed love to show demos on multi-core Intel CPUs, so I think they are putting more emphasis on feature.



    16 May 13 at 1:40 pm

  5. There is another thing which I am interesting on. Planetside 2, Warframe or Hawken are using new PhysX SDK 3.x. So they should use multicore CPUs better. Is that true? How is it used in these games? Is PhysX using one thread in games instead of more even in his new versions? Are there any tests of PhysX CPU usage in these games?



    21 May 13 at 12:22 pm

  6. mareknr: lanetside 2, Warframe or Hawken are using new PhysX SDK 3.x

    Hawken is still using PhysX 2.8.

    As for Warframe and Planetside 2, if speaking of:

    * Main CPU physics layer – both games are not very intensive on physics calculations (especially Warframe), so I don’t think they are running physics in many threads – it is simply not needed.

    * As for CPU execution of GPU PhysX effects, there is none. GPU effects are all exclusive.

    You must understand, that multi-threading “issue” with SDK 2.8 is a little far-fetched and exaggerated.
    It is mostly related to CPU execution of extra effects (“I don’t want to buy NVIDIA GPU, but I still want to get all”), which has more reasons than just SDK capabilities.

    Plus, there are already much more games running SDK 3.x on CPU – Bioshock Infinite, Arma 3, Natural Selection 2, Star Trek: The Game, etc, etc



    21 May 13 at 12:55 pm

Leave a Reply

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