Physx uses x87 code?

[LAN_deRf_HA]

I didn't see anyone else post this, and I found it entertaining, or depressing. http://realworldtech.com/page.cfm?ArticleID=RWT070510142143&p=1

x87 has been deprecated for many years now, with Intel and AMD recommending the much faster SSE instructions for the last 5 years. On modern CPUs, code using SSE instructions can easily run 1.5-2X faster than similar code using x87. By using x87, PhysX diminishes the performance of CPUs, calling into question the real benefits of PhysX on a GPU.

The bottom line is that Nvidia is free to hobble PhysX on the CPU by using single threaded x87 code if they wish. That choice, however, does not benefit developers or consumers though, and casts substantial doubts on the purported performance advantages of running PhysX on a GPU, rather than a CPU.

There were all sort of reasons to hate physx already, this just makes the whole thing seem like a scam...

 

[W1zzard]

sigh .. already saw discussion of this at xs ..

deprecated? author needs to learn what deprecated means in developer speak. floating point is a feature of x86 cpus and not going away

sse is not just a magical checkbox that you can turn on and off at compile time, you have to actively port your code which costs time and money.

you could make the same argument why microsoft doesnt just compile windows for the iphone

 

[Bjorn_Of_Iceland]

But it sure will be a blast if they rewrite / optimize the code utilizing SSE.. we would see physics effects GPU accellerated-like using CPU.

 

[ahmedz_1991]

that's what i wanted 2 know if NVidia is trying 2 better the graphics or just better the image of its GPU

 

[Kreij]

The fact that the PhysX libraries and drivers use x87 code is really not that big of a deal.

This however ...

Moreover, PhysX code is automatically multi-threaded on Nvidia GPUs by the PhysX and device drivers, whereas there is no automatic multi-threading for CPUs

... would seem to indicate that before Nvidia snatched up Ageia, they (Ageia) perhaps limited the CPU performance (by limiting thread execution) so their PPU's would outperform CPUs. Nvidia seems to just have followed suit.

Nvidia purchased Ageia in 2008, so they would have had time to change the CPU executing code, but that would not really make any sense as they are not promoting CPUs, and it would not have been a wise decision from a (GPU) marketting standpoint.

That being said, Nvidia owns the code and I stand behind their right to do whatever they want with it. They are, after all, in the business to make money.

 

[Static~Charge]

The fact that the PhysX libraries and drivers use x87 code is really not that big of a deal.

Read page 4, "Why x87?", again:

x87 uses a stack of 8 registers with an extended precision 80-bit floating point format. However x87 data is primarily stored in memory with a 64-bit format that truncates the extra 16 bits. Because of this truncation, x87 code can return noticeably different results if the data is spilled to cache and then reloaded. x87 instructions are scalar by nature, and even the highest performance CPUs can only execute two x87 operations per cycle.

In contrast, SSE has 16 flat registers that are 128 bits wide. Floating point numbers can be stored in a single precision (32-bit) or double precision (64-bit) format. A packed (i.e. vectorized) SSE2 instruction can perform two double precision operations, or four single precision operations. Thus a CPU like Nehalem or Shanghai can execute 4 double precision operations, or 8 single precision operations per cycle. With AVX, that will climb to 8 or 16 operations respectively. SSE also comes in a scalar variety, where only one operation is executed per instruction. However, scalar SSE code is still somewhat faster than x87 code, because there are more registers, SSE instructions are slightly lower latency than the x87 equivalents and stack manipulation instructions are not needed. Additionally, some SSE non-temporal memory accesses are substantially faster (e.g. 2X for AMD processors) as they use a relaxed consistency model.

The only reason to use those antiquated x87 instructions in this day and age is to artificially skew the performance differences between PhysX on the GPU versus the CPU. This is as bad as cooking your graphics drivers so they perform better in the benchmarks but not in real-world use. :shadedshu

 

[Benetanegia]

For me that article lacks any relevance since it's the GPU code path that is been used. That code has been optimized to run on the GPU, not on the CPU, so taking it, benchmarking it on a CPU and claiming that it's not optimized for the CPU is totally pointless. Of course it's not.

Until I see the same tests made on a game with the "advanced GPU PhysX" checkbox disabled, I'm not going to take anything seriously. CPU PhysX is in no disadvantage to other physics APIs, so it is very posible that the CPU code path does use SSE. But why should Nvidia optimize for the CPU something that is supposed to run on the GPU, I don't know. I'll wait until he makes the other tests he mentions. Considering that Havok is not any faster than software PhysX, we may even discover that Havok uses x87 too, or that it uses it, but SSE makes no difference.

This article has been commented in many forums, and quite some people have mentioned that the PhysX that Nvidia is using is the one that came from Meqon, which was developed much sooner than SSE was out and like Wizzard said porting something is not a checkbox you can turn on and off. So again if the GPU code path, the one that kicks off when you turn the "GPU accelerated PhysX" checkbox on, was going to be used on GPUs and the CPU will only be used for small actions, why on earth do they have to spend weeks and loads on money optimizing it for a CPU? What does it matter if 3% (good optimization) or 6% of the CPU (bad) is being used?

 

[EastCoasthandle]

All technical information aside, I think people are fully aware that the the CPU should be able to do what they say can only happen on the GPU without unnecessary performance penalties. For years they've tried to convinced the masses of GPU physics and have IMO not been very successful. Although many do not know the technical aspects of it they clearly see the propitiatory nature and marketing spin of it. And for them that's more then enough to weight in on their opinions to not support such endeavors.

Heck even Nv doesn't want you to support it when they themselves lock out consumers who use their hardware as a PPU when the primary GPU is not their own. Only later to release a beta driver without the lock out. Then later to reinstate the lockout out with future drivers.

 

[Benetanegia]

All technical information aside, I think people are fully aware that the the CPU should be able to do what they say can only happen on the GPU without unnecessary performance penalties. For years they've tried to convinced the masses of GPU physics and have IMO not been very successful. Although many do not know the technical aspects of it they clearly see the propitiatory nature and marketing spin of it. And for them that's more then enough to weight in on their opinions to not support such endeavors.

Heck even Nv doesn't want you to support it when they themselves lock out consumers who use their hardware as a PPU when the primary GPU is not their own. Only later to release a beta driver without the lock out. Then later to reinstate the lockout out with future drivers.

The CPU is NOT able to do it or we would have plenty of CPU implementations for the CPU matching PhysX capabilities already. The fact that Havok does not have something that comes even close to PhysX in terms to particles/bodies used, etc, is proof enough. Intel has been trying hard to say their CPUs are better than the GPU, so if it was as easy as taking a physics API they own and making it run on SSE, well they would have done it. It's been 4 years since PhysX and nothing released in that regards, which means it cannot be done.

That's how I see it and I know I am right.

 

[EastCoasthandle]

The CPU is NOT able to do it or we would have plenty of CPU implementations for the CPU matching PhysX capabilities already. The fact that Havok does not have something that comes even close to PhysX in terms to particles/bodies used, etc, is proof enough. Intel has been trying hard to say their CPUs are better than the GPU, so if it was as easy as taking a physics API they own and making it run on SSE, well they would have done it. It's been 4 years since PhysX and nothing released in that regards, which means it cannot be done.

That's how I see it and I know I am right.

No one cares about what you think the CPU can or cannot do, match or cannot match nor which engine is used. All people care about is the outcome of how the game plays. And so far, no developer can create a game were it is completely dependant on the GPU physics without the help of the CPU. All physx has done in most of the games offered is remove some of the load from the CPU then proportionating it to a specific video card. That is what people don't care for and is why it's IMO so unpopular.

Now if physx was using the CPU more efficiently, allowing everyone with an adequate CPU to play the game as intended (like consoles for example), I don't think so many would put up such a fuss about it all. But with tidbites of news trickling down the interweb that phsyx isn't using the CPU as good as it should only confirms the opinions of others. Who are aware of the already marketing angle of physx and it's propitiatory needs in order to run it.

 

[Kariddi]

sigh .. already saw discussion of this at xs ..

deprecated? author needs to learn what deprecated means in developer speak. floating point is a feature of x86 cpus and not going away

sse is not just a magical checkbox that you can turn on and off at compile time, you have to actively port your code which costs time and money.

you could make the same argument why microsoft doesnt just compile windows for the iphone

Deprecated means that the use of those instructions is discouraged . x87 has been deprecated in 2000 from intel and 2003 from AMD . Physx code is much younger.
SSE2 can be turned off or on at compile time actually. If you write your code in C++ and then enable the compiler to use SSE for floating point operation then the compiler generates only SSE code and no x87 code. In GCC you can use the optimization flag "-mfpmath=sse" to do such a thing.
For hand written assembly code it wouldn't be too hard to port the code from x87 to SSE2. SSE is actually a much simplier instruction set than x87 that has a lot of register stack management. Also ... writing optimized assembly code and using x87 really defeats the purpose of handwriting assembly ...

This together with the multithreading limitations makes it seem deliberate ...

 

[Benetanegia]

No one cares about what you think the CPU can or cannot do, match or cannot match nor which engine is used. All people care about is the outcome of how the game plays. And so far, no developer can create a game were it is completely dependant on the GPU physics without the help of the CPU. All physx has done in most of the games offered is remove some of the load from the CPU then proportionating it to a specific video card. That is what people don't care for and is why it's IMO so unpopular.

Now if physx was using the CPU more efficiently, allowing everyone with an adequate CPU to play the game as intended (like consoles for example), I don't think so many would put up such a fuss about it all. But with tidbites of news trickling down the interweb that phsyx isn't using the CPU as good as it should only confirms the opinions of others. Who are aware of the already marketing angle of physx and it's propitiatory needs in order to run it.

Oh wow sorry if something I said offended you. Patethic response. Try making a point instead of attacking me.

PhysX on GPU does much more than off-loading, it adds effects that no other physics API has shown yet (on real time). And years pass and we still have no alternatives. Again if it so easy and the CPU is soooo able to do it, why Havok an Intel owned API and mayor competitor to PhysX (which btw has lost like 20% market share to PhysX in the last 2 years...) does not have something similar, when it's clear that Intel is so desperate to show that the CPU is superior? What's more, why did Havok rely on AMD GPUs to try and make some competence to Nvidia?

 

[EastCoasthandle]

Oh wow sorry if something I said offended you. Patethic response. Try making a point instead of attacking me.

I think it's clear who's upset here and it's certainly not me. Also, disagreeing with your post isn't an attack. But clearly it didn't stop you from making your own.

PhysX on GPU does much more than off-loading, it adds effects that no other physics API has shown yet (on real time). And years pass and we still have no alternatives. Again if it so easy and the CPU is soooo able to do it, why Havok an Intel owned API and mayor competitor to PhysX (which btw has lost like 20% market share to PhysX in the last 2 years...) does not have something similar, when it's clear that Intel is so desperate to show that the CPU is superior? What's more, why did Havok rely on AMD GPUs to try and make some competence to Nvidia?

I think your are missing the obvious, no one care about that. People are simply content with the way physics is currently implemented in games. Just look at how popular console gaming has become. The truth of the matter is simple, evidence has been presented to show that physx on the CPU isn't as optimized as it should be. People been saying that for years regardless if they had proof of it or not. Now that the subject has once again surfaced it's clear that more information has been presented as to what is actually going on.

Regardless of how disdained you are regarding the CPU for physics it is still an important aspect still used in todays games. Be that as it may it's only apparent that we are going to agree to disagree about the subject. Furthermore, since it's clear your replies have started with name calling our conversation has pretty much wrapped up.

 

[Benetanegia]

Saying that no one cares, when it so obvious you do care, or you wouldn't be here, is well...

Playing the console card neither is wise, since we are here, discussing in a tech forum about GPUs and CPUs not consoles.

The fact of the matter is that there's many people who care or wouldn't be upset and so willing to jump onto Nvidia's neck everytime something related to PhysX appears on the net, and it's not as if they waited for any kind of proof or confirmation. The article made by Kanter this time is completely lacking, as he only tested 2 demos and those demos have always been aimed at the GPU. Take Mirror's Edge, take Batman, take a game at least and not a GPU PhysX demo... And test it in all its forms, with GPU PhysX acceleration turned on and off. He has not demostrated that x87 is used by PhysX to run on the CPU, because he has not even run a game with a CPU code path, a game (or setting) that is supossed to run on the CPU. If he at least had used the game Cryostasis instead of the tech demo which was released to show GPU PhysX he would at least have half a point.

 

[PopcornMachine]

If NVIDIA is making claims about the superiority of the GPUs over CPUs based on code that is unfairly ported to each platform, then that is deception. And that is wrong.

 

[slyfox2151]

i for one am NOT happy with the current physics in games at all.... (to say people are happy with current physics is wrong. there not, but no one offers any games that have very nice physics. people havnt seen how much more indepth a game is with working realistic physics.)


if someone offered a much better physics option then physx i would buy it asap.


games with well done physics really stand out for me.

If NVIDIA is making claims about the superiority of the GPUs over CPUs based on code that is unfairly ported to each platform, then that is deception. And that is wrong.

they coded for the GPU not CPU. nvidia dosnt make CPUs. why would nvidia code physics for cpus?
nvidia is not going to go out of there way to optimise the code to run on a cpu as best that it can.... and its obvious that they cant run the code as well on cpus as gpus... its been said twice further up in this thread.

Physx is ahead in what it can do compared to havok. if what Physx can do on a GPU can also be done on a CPU.... why cant havok do it?

 

[PopcornMachine]

they coded for the GPU not CPU. nvidia dosnt make CPUs. why would nvidia code physics for cpus?

OK, then why was the article written? Is the author just making up the fact that there is CPU Physx code?

 

[mastrdrver]

The fact that the PhysX libraries and drivers use x87 code is really not that big of a deal.

This however ...


... would seem to indicate that before Nvidia snatched up Ageia, they (Ageia) perhaps limited the CPU performance (by limiting thread execution) so their PPU's would outperform CPUs. Nvidia seems to just have followed suit.

Nvidia purchased Ageia in 2008, so they would have had time to change the CPU executing code, but that would not really make any sense as they are not promoting CPUs, and it would not have been a wise decision from a (GPU) marketting standpoint.

That being said, Nvidia owns the code and I stand behind their right to do whatever they want with it. They are, after all, in the business to make money.

That's the first thing I thought of when I saw the article and saw some interjections by others. nVidia bought the company lock stock and barrel. Ageia developed the code for their stuff, and if I'm not mistaken, rolling the code over to nVidia hardware was effortless.

So nVidia has been keeping the proprietary API code updated for their hardware. Why is this a shock? I'd be much more pissed over something like no AA for ATI cards in Batman than this. Did 3Dfx optimize Glide for other cards? Why would they?

Btw on the physics of games thing, I'm sure that everyone who plays games would agree that in general it has made gameplay better. With that said, I'd take Crysis type physics over nVidia's version any day of the week. In my opinion the Crysis team did a better job and still is compared to what nVidia has. nVidia's physics through Physx just does not look natural in comparison. Saying that I realize that this is relative though and others may disagree on this last part.

 

[ctrain]

Deprecated means that the use of those instructions is discouraged . x87 has been deprecated in 2000 from intel and 2003 from AMD . Physx code is much younger.
SSE2 can be turned off or on at compile time actually. If you write your code in C++ and then enable the compiler to use SSE for floating point operation then the compiler generates only SSE code and no x87 code. In GCC you can use the optimization flag "-mfpmath=sse" to do such a thing.
For hand written assembly code it wouldn't be too hard to port the code from x87 to SSE2. SSE is actually a much simplier instruction set than x87 that has a lot of register stack management. Also ... writing optimized assembly code and using x87 really defeats the purpose of handwriting assembly ...

This together with the multithreading limitations makes it seem deliberate ...

No, that's not what the flag does. MSVC will not pump out vectorized SSE code. It WILL use handwritten SSE versions of runtime functions though. You're not going to see fast SSE stuff magically popping up by flipping a switch.

MS provides intrinsics to help keep you out of assembly land, but you're still writing it yourself anyway. The compiler will attempt to optimize SSE stuff if you used intrinsics, but it won't optimize inline assembly ever.

 

[Mussels]

they coded for the GPU not CPU. nvidia dosnt make CPUs. why would nvidia code physics for cpus?

because if it doesnt run well on a CPU, game devs arent going to risk integrating it in their games properly.

If a game wont work on older hardware, ATI hardware, intel GPU hardware, etc... why make it neccesary to the game?

This attitude of "nvidia GPU or nothing' is what forces PhysX to be nothing more than a gimmick for things that dont change gameplay at all.

If it runs on all systems acceptably and faster/more detailed on Nvidia hardware, then it will be more widely supported.

 

[Bjorn_Of_Iceland]

Can they do the same test on Havoc, Bullet, etc? Because if those apis use SSE, then Id say Physx is quite optimized for an x87 laced app..

 

[Benetanegia]

Can they do the same test on Havoc, Bullet, etc? Because if those apis use SSE, then Id say Physx is quite optimized for an x87 laced app..

That's my reasoning too. If PhysX on CPU is so crippled, how is it that it runs just as well as any other game using other APIs like Havok or Bullet? Before any claim is made all three APIs have to be compared and the CPU PhysX has to be used.

Btw on the physics of games thing, I'm sure that everyone who plays games would agree that in general it has made gameplay better. With that said, I'd take Crysis type physics over nVidia's version any day of the week. In my opinion the Crysis team did a better job and still is compared to what nVidia has. nVidia's physics through Physx just does not look natural in comparison. Saying that I realize that this is relative though and others may disagree on this last part.

I agree that Crysis does a better use for physics than other games including those with PhysX, but it uses the CPU to run them and everybody knows how the fps drop when there's just a bunch of explosions and such.

Also: http://www.youtube.com/watch?v=YG5qDeWHNmk - Crysis PhysX 3000 barrels: read the description the actual framerate with 3000 barrels falling was 0.2 FPS or 1 frame every 5 seconds.

Or if you prefer Havok: http://www.youtube.com/watch?v=7f33GYOC2as

Compare compare those to: http://www.youtube.com/watch?v=s_2Klve_2VQ - PhysX screensaver running off a 9500GT doing both graphics and physics at smooth fps.

To date PhysX screensaver continues to be the best example of what could be done with PhysX. For example, if Bad Company 2 used GPU physx instead of what it uses, the buildings could be destryed more realistically and not the same crappy way every single time, just as the piles of bricks in the screensaver, the walls could be destroyed into realistic bricks. Everything would be the same as it is in BC2 except that every explosion would have different results and the bricks could be thrown away off the building and cause damage like real explosions do, where it's not the explosion what makes most damage, but the shrapnel which reahes a far greater radius than the blast.

 

[ctrain]

Can they do the same test on Havoc, Bullet, etc? Because if those apis use SSE, then Id say Physx is quite optimized for an x87 laced app..

Pretty sure Havok is threaded and has been optimized by both Intel and AMD.

Intel owns Havok now so I'd expect that it's pretty fast under the hood.

For example, if Bad Company 2 used GPU physx instead of what it uses, the buildings could be destryed more realistically and not the same crappy way every single time, just as the piles of bricks in the screensaver, the walls could be destroyed into realistic bricks. Everything would be the same as it is in BC2 except that every explosion would have different results and the bricks could be thrown away off the building and cause damage like real explosions do, where it's not the explosion what makes most damage, but the shrapnel which reahes a far greater radius than the blast.

This would be hellish from a rendering standpoint, let alone physics. How do you plan to get that working online?

 

[Benetanegia]

Pretty sure Havok is threaded and has been optimized by both Intel and AMD.

Intel owns Havok now so I'd expect that it's pretty fast under the hood.

Havok is as threaded as PhysX is (that is completely multithreaded), but in every single game using Havok that I have tested only one core is used. I have tested all the Source engine games, Oblivion, Fallout, Assassin's Creed, Bioshock, Company of Heroes, Ded Space and many many others. See it's not as if I only tested a bunch and ALL of them used only one core on my Quad for physics* and most used 1 core for everything.

*If at all. I mean 2 cores were used on my quad so I assume havok was using one of them...

This would be hellish from a rendering standpoint, let alone physics. How do you plan to get that working online?

The rendering part is being done already and are you telling me that a LAME 9500GT can do what it does on the screensaver, but a mainstream DX11 card would not be able to run BC2 plus what I said??

Also what I'm asking for is that they stop trying to improve graphics and they improve physics instead. BC2 requires much much more resources than i.e. L4D and it doesn't look so much better. I refer to the fact that we can say it looks 2x times better which is a lot certainly, but it requires a card that is 8 tims faster for doing so. Give me a game that requires 6x times more GPU for the graphics and uses the other 2x for proper physics. That won't ever happen probably, because they would have to work. Uggg! Work! Vade retro!

 

[Bjorn_Of_Iceland]

Pretty sure Havok is threaded and has been optimized by both Intel and AMD.

Intel owns Havok now so I'd expect that it's pretty fast under the hood.

Precisely.. then why dont we see ludicrous amounts of debris, smoke, movable clothe in other physics middleware utilizing titles? If sse would theoretically bump up Physix performance on software rendering (2x like they said it should), then Id say they should go for it.. but 2x more physics calculating power wont show an equal amount of processing as to what a dedicated physics calculating add on card would do.. as it was evident (cant find that graph on that liquid physics thing), it would require more than twice the processing power... not just the 2x benefit of the sse.