PhysX87: Software Deficiency

[HardOCP News]

Real World Technologies has a very interesting editorial posted today that explains how NVIDIA has hobbled PhysX on the CPU and why. Definitely good reading, click on over and check it out.

In the case of PhysX on the CPU, there are no significant extra costs (and frankly supporting SSE is easier than x87 anyway). For Nvidia, decreasing the baseline CPU performance by using x87 instructions and a single thread makes GPUs look better. This tactic calls into question the CPU vs. GPU comparisons made using PhysX; but the name of the game at Nvidia is making the GPU look good, and PhysX certainly fits the bill in the current incarnation.

 

[ObyTwo]

Is anyone really surprised?

 

[Gorankar]

Is anyone really surprised?

Not really. Hardware PhysX is, and pretty much always has been only a marketing gimmick for selling the ppu and now Nv vid cards. That is is coded from top to bottom to NOT work as well as it could on modern CPUs is hardly surprising considering that.

 

[Brent_Justice]

There is no denying the power of the GPU for such things as Physics, there is also no denying that CPUs are very underutilized for such tasks right now. I think a lot more can be done with the CPU for Physics acceleration before we even talk about using the GPU.

 

[kllrnohj]

Is anyone really surprised?

Nope, but its nice to have proof.

Actually, if you run Nvidia's multithreaded PhysX samples (set to use 8 threads), it STILL isn't multithreaded. It creates 8 threads, but only 1 of them is ever loaded. Even with the number of objects cranked through the roof, you'll see 1 thread at 100%, and the rest bouncing between 0 and 5%. Rather disturbing just how bad the CPU implementation really is.

And before people start defending Nvidia asking why they would optimize for CPU blah blah blah - save it. Nvidia had to *intentionally* do this, as some modern compilers (like the amazing Intel compiler) will *automatically* vectorize code. To get NO sse instructions at all basically requires Nvidia to compile with all compiler optimizations disabled, or to use a subpar compiler.

 

[NoOther]

What I got out of this was, "wah wah wah, physics is coded for the GPU". Umm, okay and? Why would Nvidia rewrite all of their code which is optimized to run on their GPU platforms? That makes no sense at all. And their assertions about x87 and PhysX are just guesses, no hard facts at all. They use a lot of mumbo jumbo to try and make it look like everything is "only" to hobble CPU performance. But the Nvidia GPUs are optimized to run x87 code and other applications for their CUDA and physics processing do use 64bit, so why would they use the SSE if they need to use the longer floating points for other CUDA applications? It makes no sense for Nvidia to create 2 totally separate PhysX engines, just to help out CPUS. That entire article is suspect at best.

 

[Json23]

Another reason I may not be buying an Nvidia card for the foreseeable future. I can understand where they are coming from trying to put their name at the top of the list for features. But as a consumer I don't care about their bottom line and I want a company that at least pretends to care about us little old consumers.

 

[martinmsj]

Great article. I loved that he showed us his data.

In the end I think we all knew this. Just the article gave hard data.

 

[martinmsj]

What I got out of this was, "wah wah wah, physics is coded for the GPU". Umm, okay and? Why would Nvidia rewrite all of their code which is optimized to run on their GPU platforms? That makes no sense at all. And their assertions about x87 and PhysX are just guesses, no hard facts at all. They use a lot of mumbo jumbo to try and make it look like everything is "only" to hobble CPU performance. But the Nvidia GPUs are optimized to run x87 code and other applications for their CUDA and physics processing do use 64bit, so why would they use the SSE if they need to use the longer floating points for other CUDA applications? It makes no sense for Nvidia to create 2 totally separate PhysX engines, just to help out CPUS. That entire article is suspect at best.

You did not read the article.

 

[NoOther]

Nope, but its nice to have proof.

And what proof was that? The whole article was based on conjecture and assumptions why Nvidia would use x87 instructions instead of SSE. It completely leaves out other CUDA development that would use some of the advantages of x87. Not mention there are still tons of legacy programs and code out there that use x87. So if you are porting your code to use GPGPU and CUDA it is much easier to support x87 than SSE. And since the main focus of the newer Nvidia cards is to get more people to use their cards for processing, they can reach far more people with x87 code than SSE.

So really it makes perfect sense for Nvidia to use x87 rather than SSE, and it is not "just" a marketing tool to lockout processors. The real question is why does x87 still perform so much worse on CPUs than GPUs? Why does the focus have to be on why Nvidia uses x87 rather than why do they "have" to switch to SSE coding which may alienate a good portion of their market?

 

[NoOther]

You did not read the article.

Actually I did read the whole article. Perhaps you did not pay closer attention to it.

 

[martinmsj]

And what proof was that? The whole article was based on conjecture and assumptions why Nvidia would use x87 instructions instead of SSE. It completely leaves out other CUDA development that would use some of the advantages of x87. Not mention there are still tons of legacy programs and code out there that use x87. So if you are porting your code to use GPGPU and CUDA it is much easier to support x87 than SSE. And since the main focus of the newer Nvidia cards is to get more people to use their cards for processing, they can reach far more people with x87 code than SSE.

So really it makes perfect sense for Nvidia to use x87 rather than SSE, and it is not "just" a marketing tool to lockout processors. The real question is why does x87 still perform so much worse on CPUs than GPUs? Why does the focus have to be on why Nvidia uses x87 rather than why do they "have" to switch to SSE coding which may alienate a good portion of their market?

PhysX started with Ageia and they wanted you to purchase a PPU card. They originally made the intent to make the CPU look bad compared to a PPU card.

Alienate a good portion of the market? Please, cut the bullshit. If Ageia didn't want to alienate the market they would of made PhysX run the best it could on CPUs instead of trying to make people in 2008 buy proprietary PPU cards.

Anyway, have fun responding to every post. I know your little heart is up to it.

 

[Json23]

Actually I did read the whole article. Perhaps you did not pay closer attention to it.

Me thinks I smell a fanboy in our midst..

 

[NoOther]

In fact, PhysX probably only uses single precision on the GPU, since it is accelerated on the G80, which has no double precision. The evidence all suggests that PhysX only needs single precision.

PhysX is certainly not using x87 because it contains legacy x87 code. Nvidia has the source code for PhysX and can recompile at will.

PhysX is certainly not using x87 because of a legacy installed base of older CPUs. Any gaming system purchased since 2005 will have SSE2 support, and the PPU was not released till 2006.

That is from the article. Words such as probably and suggest are not facts. They are making all conjectures here. They significantly leave out the fact that Nvidia would have to recompile everything to use SSE, when it is working perfectly find for x87 and supports legacy applications using x87, which it would not if they switched to SSE. The last saying that any gaming machine purchased since 2005 will have SSE support does not mean anything. Those systems may support SSE, but many not run the applications any better. While all machines should still support the x87 still, and applications which have been developed using x87 code are the key. Just because machines can support SSE doesn't mean everyone programs their applications to use SSE. That is the key. When you make a chip to do more GPGPU programming, and are asking people to port their applications over to it, you have to realize that many of their applications are probably still using x87 instruction sets. So again, I do not see the big deal here.

The real question will be answered when other physics development starts to take over the market from CUDA and PhysX on whether SSE is a bigger advantage.

 

[kllrnohj]

What I got out of this was, "wah wah wah, physics is coded for the GPU". Umm, okay and? Why would Nvidia rewrite all of their code which is optimized to run on their GPU platforms? That makes no sense at all. And their assertions about x87 and PhysX are just guesses, no hard facts at all. They use a lot of mumbo jumbo to try and make it look like everything is "only" to hobble CPU performance. But the Nvidia GPUs are optimized to run x87 code and other applications for their CUDA and physics processing do use 64bit, so why would they use the SSE if they need to use the longer floating points for other CUDA applications? It makes no sense for Nvidia to create 2 totally separate PhysX engines, just to help out CPUS. That entire article is suspect at best.

Where did you get this crazy idea that CUDA runs x87 code?

The simple fact is that NOBODY recommends using x87, EVERYBODY says to stay away from it, and PhysX uses it. There is *NO* technical reason to use x87.

And what proof was that? The whole article was based on conjecture and assumptions why Nvidia would use x87 instructions instead of SSE. It completely leaves out other CUDA development that would use some of the advantages of x87. Not mention there are still tons of legacy programs and code out there that use x87. So if you are porting your code to use GPGPU and CUDA it is much easier to support x87 than SSE. And since the main focus of the newer Nvidia cards is to get more people to use their cards for processing, they can reach far more people with x87 code than SSE.

So really it makes perfect sense for Nvidia to use x87 rather than SSE, and it is not "just" a marketing tool to lockout processors. The real question is why does x87 still perform so much worse on CPUs than GPUs? Why does the focus have to be on why Nvidia uses x87 rather than why do they "have" to switch to SSE coding which may alienate a good portion of their market?

No, it was based on data obtained using a profiler. Not conjecture and assumptions at all. And PhysX isn't a legacy program, so that excuse goes out the fucking window.

Also, you seem to be ignoring that PhysX is fully capable of using other vectorization approaches - since it does for both the xbox 360 and PS3 - neither of which support x87.

As for your comment about investigating why x87 performs worse - that just highlights your complete lack of any knowledge about the topic at hand. You clearly have no clue what any of this stuff means.

 

[NoOther]

Me thinks I smell a fanboy in our midst..

It isn't fanboyism here, my current setups include ATI graphics. I also am a big fan of OpenCL progressing. I am just calling BS on the shoddy guess work done in the article.

 

[92miata]

i own a geforce 295 and it is pretty nice. that said, i will never puchase another nvidia card again because of this kind of thing.

not to mention thee 400 series is a complete fail for what i am interested in, LOW NOISE!!!!!

goodbye nvidia, hopefully.

 

[kllrnohj]

That is from the article. Words such as probably and suggest are not facts. They are making all conjectures here. They significantly leave out the fact that Nvidia would have to recompile everything to use SSE, when it is working perfectly find for x87 and supports legacy applications using x87, which it would not if they switched to SSE. The last saying that any gaming machine purchased since 2005 will have SSE support does not mean anything. Those systems may support SSE, but many not run the applications any better. While all machines should still support the x87 still, and applications which have been developed using x87 code are the key. Just because machines can support SSE doesn't mean everyone programs their applications to use SSE. That is the key. When you make a chip to do more GPGPU programming, and are asking people to port their applications over to it, you have to realize that many of their applications are probably still using x87 instruction sets. So again, I do not see the big deal here.

The real question will be answered when other physics development starts to take over the market from CUDA and PhysX on whether SSE is a bigger advantage.

FYI, "recompiling everything" is as simple as hitting "ctrl-b". It is something done hundreds of times *per day*, it is not a complex task. Telling the compiler to use SSE is literally an option - one that they can probably change through a GUI, depending on the compiler and IDE they are using.

It isn't fanboyism here, my current setups include ATI graphics. I also am a big fan of OpenCL progressing. I am just calling BS on the shoddy guess work done in the article.

The only "shoddy guess work" being done is you trying to understand an article that is clearly way above your head.

 

[caveman-jim]

@NoOther - you're talking about machines that feature very old hardware, for gaming. If NVIDIA were to optimize the CPU routines of PhysX (and don't forget, not all PhysX can be GPU accelerated - only subsections, some runs only on CPU no matter what) then they would likely pick to optimize to SSE2, as that would give enough features and performance benefit to give a meaningful increase. This still gives as a massive amount of support hardware. Only AMD processors before Athlon64. Pentium processors before P4 wouldn't support SSE2. Very few of those processors will be able to run modern games, with or without PhysX enhanced content.

NVIDIA doesn't sell PhysX to consumers, it sells them to Developers. On that basis, it would benefit them to offer better performance for all the target platform consumers, no matter if they had a GeForce or not. Developers would feel better about using PhysX, increasing adoption and helping drive sales of GeForce cards as gamers decide the want the extra effects and eye-candy/game-candy GPU accelerated PhysX allows. Optimizing PhysX CPU performance is the way for NVIDIA to fight the Open Physics Initiative and make PhysX the de-facto Physics API.

IMO.

 

[TheBuzzer]

they prob can compile it to all processor base if they wanted to.

 

[sbuckler]

The article was a lot of whine.

Read the wiki page: http://en.wikipedia.org/wiki/SSE2
It says:
1) there are cpu's that don't support it (e.g. anything pre A64, P4) which are still supported in games so therefore physx can't drop x87, they would have to have 2 code paths. Do you really want to be downloading 2 copies of physx with each nvidia driver?
2) it's not that much quicker - read the wiki it explains why.
3) some of the articles arguments (e.g. 16 registers vs 8) are wrong. The 16 registers are 64 bit only, for 32 bit games (ie. nearly all of them) you only get 8. 64 bit has SSE2 by default - so any 64bit physx would automatically get compiled to use SSE2.

If physx really was hobbled then other solutions like havok/bullet would be much faster. They talk about comparing it to other physics libraries (e.g. bullet) but don't actually do it - probably because none of the other ones are any faster then physx so it wouldn't suit the authors aims - wouldn't surprise me if they weren't using SSE2 either for backwards compatibility. Fundamentally if physx was rubbish developers wouldn't use it, even if nvidia paid them (of which there is no proof they ever have - just conspiracy theories).

Multithreading works fine but the devs have to code to use it. e.g. 3dmark Vantage uses it and that works perfectly - it'll bring any cpu to it's knees in the physics processing bit. If devs don't use it (and they don't because most games are console ports, and the consoles only want one physics thread) then that's not physx's fault. Is havok/bullet any different - I doubt it?

Bottom line is it obviously works just fine as a software solution (hardware is a different story but that's not in the scope of this article).

 

[NoOther]

Where did you get this crazy idea that CUDA runs x87 code?

The simple fact is that NOBODY recommends using x87, EVERYBODY says to stay away from it, and PhysX uses it. There is *NO* technical reason to use x87.

Really? Most of the programmers and engineers I know would completely call your BS here. There is tons of code written well before SSE that is still used today. SSE is a newer development still.

No, it was based on data obtained using a profiler. Not conjecture and assumptions at all. And PhysX isn't a legacy program, so that excuse goes out the fucking window.

Right, the fact that is uses far more x87 instructions than SSE instructions was shown. Not WHY they are using x87. That was all conjecture as I explained.

Also, you seem to be ignoring that PhysX is fully capable of using other vectorization approaches - since it does for both the xbox 360 and PS3 - neither of which support x87.

As for your comment about investigating why x87 performs worse - that just highlights your complete lack of any knowledge about the topic at hand. You clearly have no clue what any of this stuff means.

Right, and you clearly have such advanced knowledge?

Try reading some of the comments in this thread:

http://forums.anandtech.com/showthread.php?p=30095721

or some of the info here:

http://stackoverflow.com/questions/1844669/benefits-of-x87-over-sse

or here:

http://gcc.gnu.org/ml/gcc-patches/2006-10/msg00580.html


Remember the first assumption is that SSE would be faster if gaming programing was multi-threaded which most of it still isn't. Secondly, there are no actual direct comparisons to make between x87 physics and SSE physics as stated in the article. So again, all conjecture and assumptions.

 

[MrLonghair]

If only those people (and the EU) suing Apple for every little thing would turn their eyes on Nvidia and try a suit they have a chance at winning :/

This is some tasty pudding to read, even though it is basically my second serving of this truth behind Nvidia's PhysX.

 

[Stoly]

SSE is no automatically nor magically faster than x87. Code has to be optimized for it. and even then it may not be twice as fast.

And AMD could support physx if they wanted to. But they won't, so don't blame nvidia on that one.

BTW I'm still waiting for HW accelerated HAVOK physics, which was announced 5 years ago IIRC

 

[ShamisOMally]

SSE is no automatically nor magically faster than x87. Code has to be optimized for it. and even then it may not be twice as fast.

And AMD could support physx if they wanted to. But they won't, so don't blame nvidia on that one.

BTW I'm still waiting for HW accelerated HAVOK physics, which was announced 5 years ago IIRC

Difference is that Havok/DX11 physics is free, while using PhysX requires a license fee to use

So if ATI was going to use PhysX, they would have to pay nvidia to use it

And FYI, Havok with a quad core from 2008 CPU does 5x the physics a Geforce 280 does with PhysX, to give you an idea of how bloated PhysX actually is

 

[Navilor]

HardOCP has already covered CPU accelerated physics. Ghostbusters uses the Infernal Engine by Terminal Reality. It runs really well on my system.

The direct link to the PC demo link is broken on HardOCP (Infernal Engine VELOCITY Physics Tornado PC Demo). Working link can be found on Gameguru. Try this PS3 link for more fun.

Nvidia gives PhysX away for free to everyone. Why? To get more video cards sold.

With ATI you can have up to six monitors per ATI card. I cannot recall how many you can have with one Nvidia card.

My next video card will see my return to the ATI fold. Nvidia has done nothing but annoy me lately with their crappy drivers, proprietary physics and proprietary CUDA support.

Hopefully OpenCL and something like the Infernal Engine can break through. After all Glide (proprietary) was the best thing to hit 3D until OpenGL and DirectX (standards) killed it.

 

[arthur_tuxedo]

NVidia is making a bone-headed move here, and in fact is repeating AGEIA's mistake. AGEIA set themselves up for failure by creating an intractable chicken and egg problem (which I believe I pointed out on this very forum shortly after the PHYSX card was released ). Developers won't program for it without a base of customers + Customers won't buy it without games that take advantage = AGEIA loses.

With an NVidia card instead of a discrete one you have an installed base of 50% instead of 0% (generously ignoring gamers who use integrated or the fact that ATI has been outselling NV lately). This is an improvement, but if you're going to really wow people, the physics have to be made a part of the core gameplay, yet if it's part of core gameplay and doesn't work on ATI cards, you just shut yourself out of at least 50% of potential buyers. No sane developer of a big name game would ever do this.

NVidia should have licensed the software cheaply to ATI and pushed it to become the dominant standard for physics. With one standard that works on all modern GPU's and consoles, developers would almost universally write for it and NVidia could collect a licensing fee for every big name title. Instead they made sure their intellectual property will remain as irrelevant as it was under AGEIA.

 

[pxc]

BTW I'm still waiting for HW accelerated HAVOK physics, which was announced 5 years ago IIRC

That one was cancelled. I have a feeling that Intel may drag its feet with the newer acceleration it was working on now that Larrabee for GPUs isn't coming out any time soon. I'm not even holding my breath for an OpenCL/DirectCompte compatible on-die GPU from Intel either.

I agree with a couple of points in your post, but in this case, SSE2 is perfect for accelerating PhysX over x87. The matrix math behind the type of physics it uses is a case where SSE2 would help tremendously. I'll take nvidia's word that it optimized the CPU version, but DK's profiling shows that optimization would only be on the sole x87 CPU path. That's not good enough, even for "compatibility" reasons.

 

[Stoly]

Difference is that Havok/DX11 physics is free, while using PhysX requires a license fee to use

So if ATI was going to use PhysX, they would have to pay nvidia to use it

And FYI, Havok with a quad core from 2008 CPU does 5x the physics a Geforce 280 does with PhysX, to give you an idea of how bloated PhysX actually is

-The license is free

and how do you figure havok is faster then physx?

 

[pxc]

And FYI, Havok with a quad core from 2008 CPU does 5x the physics a Geforce 280 does with PhysX, to give you an idea of how bloated PhysX actually is

LOL, no it doesn't.

 

[kllrnohj]

1) there are cpu's that don't support it (e.g. anything pre A64, P4) which are still supported in games so therefore physx can't drop x87, they would have to have 2 code paths. Do you really want to be downloading 2 copies of physx with each nvidia driver?

Actually, there wouldn't need to be 2 copies of physx to handle that, just two paths in the same DLL. Many, many programs already do this. Video players, for example, will often switch on what level of SSE is supported and choose the best - it isn't hard. Rather trivial, actually.

Or they could just drop support for CPUs without SSE - CPUs that can't run modern games anyway.

2) it's not that much quicker - read the wiki it explains why.

Yes, it is much quicker.

3) some of the articles arguments (e.g. 16 registers vs 8) are wrong. The 16 registers are 64 bit only, for 32 bit games (ie. nearly all of them) you only get 8.

Kind of. With 32bit you only get 8 SSE registers, yes, but each register can hold 4 single precision floating point numbers, so you can still operate on a larger data set at once than with x87

64 bit has SSE2 by default - so any 64bit physx would automatically get compiled to use SSE2.

Doesn't work like that.

Multithreading works fine but the devs have to code to use it. e.g. 3dmark Vantage uses it and that works perfectly - it'll bring any cpu to it's knees in the physics processing bit.

I'll have to try out Vantage, but all the multithreading PhysX I've seen (including the official demos and samples) have *TERRIBLE* multithreading to the point of it simply not working.

Really? Most of the programmers and engineers I know would completely call your BS here. There is tons of code written well before SSE that is still used today. SSE is a newer development still.

And what does that have to do with PhysX? Oh, right, not a goddamn thing. PhysX isn't a legacy application, it was not written before SSE was used (not even close), etc..

Right, the fact that is uses far more x87 instructions than SSE instructions was shown. Not WHY they are using x87. That was all conjecture as I explained.

Actually, PhysX didn't use *ANY* SSE instructions, not a single one. Meaning all the floating point work was either emulated in software (stupidly slow) or was done with x87. Those are the only two possibilities. There isn't any other option.

Right, and you clearly have such advanced knowledge?

Try reading some of the comments in this thread:

http://forums.anandtech.com/showthread.php?p=30095721

or some of the info here:

http://stackoverflow.com/questions/1844669/benefits-of-x87-over-sse

or here:

http://gcc.gnu.org/ml/gcc-patches/2006-10/msg00580.html

Did you read those? The stackoverflow one basically said the same thing the article said - only use x87 if you have to support embedded devices (which PhysX doesn't). The GNU mailing list one showed that pure SSE is faster than SSE + x87 which is faster than x87, and was from 2006. That *supports* the claims of the article, doesn't counter them at all.

Also, the comments at anandtech are disputing the articles idea that it could be 1.5-2.0x faster, NOT that SSE isn't faster. Anandtech's comments generally agree that SSE should be used.

Remember the first assumption is that SSE would be faster if gaming programing was multi-threaded which most of it still isn't. Secondly, there are no actual direct comparisons to make between x87 physics and SSE physics as stated in the article. So again, all conjecture and assumptions.

No, that isn't an assumption at all. PhysX would be faster if it used SSE full stop. It is entirely irrelevant whether or not it is multithreaded, SSE is superior to x87.

And it isn't conjecture and assumptions. SSE and x87 both due floating point work. SSE is much faster for single precision. That isn't conjecture, that is fact.

 

[NoOther]

And it isn't conjecture and assumptions. SSE and x87 both due floating point work. SSE is much faster for single precision. That isn't conjecture, that is fact.

This alone shows how ignorant you are about the technologies. The article, plus many other sources blow this idea totally out of the water. SSE is faster in some respects, but not in all respects. They are totally different tools for different purposes, just like GPUs and CPUs operate differently. You are trying to compare apples and oranges and claim superiority. You didn't even bother reading any of the links or gathering any other facts before posting. You just keep posting FUD.

 

[dkanter]

I happen to agree with most of what kllnohj is saying here.

1. x87 is almost always slower than scalar SSE on a modern CPU. There are assuredly some corner cases where x87 is faster, but they are going to be exceptionally rare.
2. On some older processors (i.e. 130nm P4) there are more cases where x87 is faster than scalar SSE.
3. Intel and AMD have strongly recommended against using x87 for years now. Intel and AMD probably have a good idea of how to write good code for their CPUs.
4. I explained in my article why SSE is faster than x87.
5. Vectorized SSE is obviously going to be faster than x87, since you can double or quadruple your throughput (for 32b or 64b values).
6. There are good reasons to use x87 (which I listed), but none of them apply to PhysX.

That being said, there are a lot of compilers that don't generate SSE code. However, it's quite trivial to fix that problem, and it's usually a simple compiler flag (e.g. march=prescott). As I said in the article, it would take about a day to do that, and perhaps a couple of weeks for compatibility testing. Moreover, there have been about a dozen different versions of PhysX, and each one must be compiled. It's not really hard to get SSE into a newer version.

NoOther: I don't think you understand the difference between x87 and SSE. x87 does not 'run on a GPU', so GPUs do not run x87 faster than a CPU. Porting to CUDA is vastly more difficult than simply changing a compiler flag to generate SSE code. And last, just because a bunch of moron developers still write code using x87 doesn't make it a good idea. It's a problem because many developers are lazy, don't care about performance, etc. However, Nvidia has good developers and you can be damn sure that their drivers make good use of SSE code...

DK

 

[aaronspink]

And what proof was that? The whole article was based on conjecture and assumptions why Nvidia would use x87 instructions instead of SSE. It completely leaves out other CUDA development that would use some of the advantages of x87. Not mention there are still tons of legacy programs and code out there that use x87. So if you are porting your code to use GPGPU and CUDA it is much easier to support x87 than SSE. And since the main focus of the newer Nvidia cards is to get more people to use their cards for processing, they can reach far more people with x87 code than SSE.

So really it makes perfect sense for Nvidia to use x87 rather than SSE, and it is not "just" a marketing tool to lockout processors. The real question is why does x87 still perform so much worse on CPUs than GPUs? Why does the focus have to be on why Nvidia uses x87 rather than why do they "have" to switch to SSE coding which may alienate a good portion of their market?

Perhaps, one such as yourself, would do better with learning something about computers, programming, instruction set, etc before making comments that make it clear that you know nothing about computers, programming, and instruction sets.

Heres a hint CUDA has nothing to do with x87. GPGPU has nothing to do with x87. Neither CUDA nor any other GPGPU API can utilize x87. They cannot run code for x87. They cannot even calculate the same numbers.

 

[BallerX]

If you think about it, it was never intended to run on Nvidia hardware either. This could run just as well on ATI hardware also. I think we all knew from the very beginning that the CPU was sandbagged in this situation. Havok physics seem to work quite well. Ghost Busters pretty much proved the whole PPU thing was a sham.

 

[kllrnohj]

This alone shows how ignorant you are about the technologies. The article, plus many other sources blow this idea totally out of the water. SSE is faster in some respects, but not in all respects. They are totally different tools for different purposes, just like GPUs and CPUs operate differently. You are trying to compare apples and oranges and claim superiority. You didn't even bother reading any of the links or gathering any other facts before posting. You just keep posting FUD.

No, actually, SSE is the *replacement* for x87. They are not totally different tools at all. x87 is old busted, SSE is new hotness. It isn't apples and oranges at all. And I did read the links, and pointed out how and where they completely disagreed with you.

I know SSE, I've coded for SSE. Have you? I'm going with "you've never developed low level code in your life" (perhaps you aren't even a developer at all) given your earlier claims about GPUs running x87 (still good for a laugh).

 

[aaronspink]

Really? Most of the programmers and engineers I know would completely call your BS here. There is tons of code written well before SSE that is still used today. SSE is a newer development still.

Which has little bearing on the article in discussion.

Right, the fact that is uses far more x87 instructions than SSE instructions was shown. Not WHY they are using x87. That was all conjecture as I explained.

if by far more you mean all.

Try reading some of the comments in this thread:

http://forums.anandtech.com/showthread.php?p=30095721

Scali has his head on backwards on this one.

http://stackoverflow.com/questions/1844669/benefits-of-x87-over-sse

which is mostly incorrect

http://gcc.gnu.org/ml/gcc-patches/2006-10/msg00580.html

which merely proves yet again that GCC is the compiler to go to when you want slow.

Remember the first assumption is that SSE would be faster if gaming programing was multi-threaded which most of it still isn't. Secondly, there are no actual direct comparisons to make between x87 physics and SSE physics as stated in the article. So again, all conjecture and assumptions.

Unless you are serially limited, SSE will be faster. We have multiple proof points that the calculations aren't serially limited (PPU, GPU), therefore, SSE will be faster. I don't think anyone can seriously debate that point except from the standpoint of ignorance.

 

[NoOther]

Perhaps, one such as yourself, would do better with learning something about computers, programming, instruction set, etc before making comments that make it clear that you know nothing about computers, programming, and instruction sets.

Heres a hint CUDA has nothing to do with x87. GPGPU has nothing to do with x87. Neither CUDA nor any other GPGPU API can utilize x87. They cannot run code for x87. They cannot even calculate the same numbers.

Sure, I will start learning more when any one of you arguing that SSE is that much better provides facts and proof that it is better...

Anytime now... I have been waiting...

Meanwhile there is tons of proof and evidence to the contrary.

 

[bigdogchris]

I love this article because it shows you how much of a scam PhysX in it's current form is.

 

[trick0502]

I happen to agree with most of what kllnohj is saying here.

1. x87 is almost always slower than scalar SSE on a modern CPU. There are assuredly some corner cases where x87 is faster, but they are going to be exceptionally rare.
2. On some older processors (i.e. 130nm P4) there are more cases where x87 is faster than scalar SSE.
3. Intel and AMD have strongly recommended against using x87 for years now. Intel and AMD probably have a good idea of how to write good code for their CPUs.
4. I explained in my article why SSE is faster than x87.
5. Vectorized SSE is obviously going to be faster than x87, since you can double or quadruple your throughput (for 32b or 64b values).
6. There are good reasons to use x87 (which I listed), but none of them apply to PhysX.

That being said, there are a lot of compilers that don't generate SSE code. However, it's quite trivial to fix that problem, and it's usually a simple compiler flag (e.g. march=prescott). As I said in the article, it would take about a day to do that, and perhaps a couple of weeks for compatibility testing. Moreover, there have been about a dozen different versions of PhysX, and each one must be compiled. It's not really hard to get SSE into a newer version.

NoOther: I don't think you understand the difference between x87 and SSE. x87 does not 'run on a GPU', so GPUs do not run x87 faster than a CPU. Porting to CUDA is vastly more difficult than simply changing a compiler flag to generate SSE code. And last, just because a bunch of moron developers still write code using x87 doesn't make it a good idea. It's a problem because many developers are lazy, don't care about performance, etc. However, Nvidia has good developers and you can be damn sure that their drivers make good use of SSE code...

DK

welcome to [H]

good article

ps: you're going to be the new charlie!!!