PHYSX NEWS PHYSX SDK
PROJECTS TABLE
GPU PHYSX
GAMES INFO
PHYSX
ARTICLES
PHYSX WIKI FORUM
РУССКИЙ ENGLISH


:: Back to news index ::

PhysX: x87 and SSE

with 11 comments

David Kanter from RealWorldTech.com 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 Hothardware.com 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 TechReport.com

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 ,

11 Responses to 'PhysX: x87 and SSE'

Subscribe to comments with RSS

  1. I think semiaccurate is taking it a bit too far. What basis does he use to conclude that the GPU is weaker than the CPU. The fact that they may have crippled CPU could have been just so it doesn’t come close, not because the CPU would win!

      

    P10-17000

    8 Jul 10 at 1:24 pm

  2. There are two sides to this, hand optimized SSE and switching the compiler to generate SSE math code instead of x87.

    As someone who has tried both approaches with physX, the hand optimized approach is not worth it, the gains are not worth the effort(unlike some similar technologies like VMX128). Modern CPUs are very efficient at out of order executing even poor code.

    However switching the compiler to produce SSE is certainly a good idea. The CPU support argument seems like BS. Plus I was under the impression that the x64 build will use compiler SSE code anyway.

    Having said that I still dont see a CPU beating a similar generation GPU for anything but the most complex(difficult to paralize) rigid body stuff.

      

    David Black

    8 Jul 10 at 3:10 pm

  3. I should probably also add that lack of SSE doesnt mean that nvidia are not delibratly creating a slow CPU version, there are many other(more effective) ways:-)

      

    David Black

    8 Jul 10 at 3:14 pm

  4. Plus I was under the impression that the x64 build will use compiler SSE code anyway
    Well, both of those apps tested above aren’t using 2.8.3.

      

    Zogrim

    8 Jul 10 at 3:17 pm

  5. My 2 cents..
    >nor there are any games, that can offer content, similar to GPU PhysX effects, but running on CPU with stable framerate.
    Not sure about smoke and fluids, but i must say that CryEngine2 delivered some great physics including nice realtime destruction of buildings without serious impact to fps. I must say it was the most impressive and real-like feel for physics i ever saw, unlike CPU/GPU PhysX.
    I’m convinced that any serious developer is able to code a great physics engine for his project. Because of the layered nature of PhysX, any custom engine can do the job more effective if created&integrated by the developer himself. It depends on his talent and experience, but the results may be more impressive than any PhysX game.

    I can easily accept what they told about “not hobbling CPU performance”, but again – they put zero effort to better support CPU further, didn’t they?

    >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) ?!
    And that’s why they made those promises regarding 3.x release? Will it really affect developers’ opinion? Maybe it will increase fps for CPU mode by 2-5 frames… or more? Also i’m pretty sure the updated engine won’t change anything for existing released projects.

    If they really want to make PhysX more attracting, why don’t they work further on the engine itself (it didn’t changed much since Ageia times, right?), not porting it to open computing engines like OpenCL, not helping developers with CPU mode, but adding more and more GPU-only content?

    We can speculate further, but they will never answer to these questions. All their defensive responses (marketing again) are addressed only to those articles/interviews to make PhysX look better imo.

      

    GenL

    8 Jul 10 at 9:04 pm

  6. I must say it was the most impressive and real-like feel for physics i ever saw, unlike CPU/GPU PhysX
    Destruction ? Easy:
    http://www.youtube.com/watch?v=fa_S2yA_YaA
    pure CPU PhysX, simulation is more complex, than in Crysis.

    any custom engine can do the job more effective if created&integrated by the developer himself
    Developers must focus on gameplay and content, not on engine and tools creation. That is why all middleware (from UE3 to Havok) does exist.

    And that’s why they made those promises regarding 3.x release?
    I dunno, SDK 3.0 is more than 2 yers in development, and even I know few details – I believe those mulithreading feature was planned from the beginning.

    not porting it to open computing engines like OpenCL, not helping developers with CPU mode, but adding more and more GPU-only content?
    Not sure about OpenCL, but SDK 3.0 will contain many changes ;)

      

    Zogrim

    8 Jul 10 at 9:21 pm

  7. >Destruction ? Easy:
    >http://www.youtube.com/watch?v=fa_S2yA_YaA
    Looks complex, but simulation doesn’t look anywhere realistic to me… In fact, i think it is far too complex for so low-detailed scene.

    >Developers must focus on gameplay and content, not on engine and tools creation.
    Very wrong! Coding is the art too, it is how the game is played and feels, it is a very base of any gameplay and content. Middlewares are mostly for consoles, where developers are lazy and don’t care about technical quality.
    Although Havok at least delivers some basic non-ugly physics without performance hit, i’d still prefer to see a custom well-made engine.

    If a developer ask me, i’d recommend to wait with the release and develop an effective physics solutions, even spend another 6 months but do it right, so it will look&feel really good. Impressive things aren’t always require the most heavy computing simulations, that’s it.

      

    GenL

    8 Jul 10 at 10:01 pm

  8. I think maybe PhysX 3.0 will raise the framerate for ATi from 5-8fps to a more playable 16-18fps with multithreading, but probably only for games that don’t use 2.8.3 or below

      

    P10-17000

    9 Jul 10 at 4:37 am

  9. Knowing how far the can go with adding PhysX content, they are likely to insert enough of stuff to promote their latest faster GPU series, thus leaving it slower on their older GPUs. And this may eliminate any possible fps increase for CPU mode in most games…

      

    GenL

    9 Jul 10 at 8:05 am

  10. BTW, very good technical post at Beyond3D Forum

      

    Zogrim

    12 Jul 10 at 6:11 pm

  11. Hmm I thought AndyTX was an nvidian… but maybe I am confusing him with someone else (or it was just nvidias presentation of VSM that confused me…)

    I imagine bullet did quite well here for SSE, since the code is probably fairly ameanable to compiler optimization and there is only really physics going on(hence the cache is not over loaded).

      

    David Black

    12 Jul 10 at 8:08 pm


Leave a Reply

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