PhysX87: Software Deficiency

[pxc]

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

No need to insult him.

 

[dkanter]

welcome to [H]

good article

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

Thanks for the welcome. And speaking as Charlie's friend, I sincerely hope to not turn out like him. He's already gone bald on top : )

David

 

[dkanter]

The fact that you can't use google and find SSE vs. x87 comparisons is kind of embarrassing.

http://users.ece.utexas.edu/~ljohn/wwc/wwc5/2_3.pdf

Try page 25, and note that the gains from SSE2 are larger today than they were 5 years ago, since CPUs can execute SSE and SSE2 operations in a single cycle.

DK

 

[kllrnohj]

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

No there isn't... Care to provide any?

 

[trick0502]

"If Nvidia wants to prove that PhysX is actually faster on the GPU, I will offer them a fair test. Give me the code tree for PhysX and the related DLL, and I will have them re-compiled for GPUs and then optimized the CPU version with some minor threading and vectorized SSE. Then I will run the released PHysX supporting games on both DLLs as a benchmark. How about it guys? If your PR claims are anything close to true, what do you have to lose?S|A"

charlie S/A

what are the chances that happens???

is anyone really surprised?

it is going to be interesting to see what nvidia has to say about this.

 

[Gorankar]

"If Nvidia wants to prove that PhysX is actually faster on the GPU, I will offer them a fair test. Give me the code tree for PhysX and the related DLL, and I will have them re-compiled for GPUs and then optimized the CPU version with some minor threading and vectorized SSE. Then I will run the released PHysX supporting games on both DLLs as a benchmark. How about it guys? If your PR claims are anything close to true, what do you have to lose?S|A"

charlie S/A

what are the chances that happens???

is anyone really surprised?

it is going to be interesting to see what nvidia has to say about this.

It is not going to happen. Besides, I am pretty sure PhysX IS faster on the GPU. It is just that PhysX on the CPU seems to be gimped to make the GPU look even better.

 

[NoOther]

No there isn't... Care to provide any?

You mean besides the links I have already provided? Passages in the article itself, and posts by others here explaining similar things? You have yet to provide even one shred of evidence or one iota of facts period.

But, gee, how about we just look at it rationally this way:

1) If PhysX is so bad, then it doesn't matter, something else will take its place and this is a moot point.

2) If SSE is that much better than x87 than physics engines using SSE rather than x87 will take the place of PhysX and this is a moot point anyway.

3) Also if SSE was so much better than x87 and CPU instructions really were better for processing physics than Larrabee wouldn't be such a dead project and Havoc would be a lot more powerful than PhysX.

4) OpenCL is being looked at and toyed with by both ATI and Nvidia and may replace their current offerings, which guess what? Makes this a moot point yet again.

5) Nvidia makes GPUs last time I checked and does not make CPUs. Which makes this a moot point.

6) If Nvidia is such a horrible company, vote with your wallet and buy something else, which again makes this a moot point.

7) Even if you were to release it with SSE coding, that might make the CPU physics processing twice as fast which still makes it at best twice as slow as PhysX on the GPU and at worst still 4 times slower, even according to the article there are limited times when CPU physics processing might be better than GPU. The best case scenerio in the artilce is CPU processing going up by 4 times and being on par and maybe better in some cases. Really, you guys need to do more reading and research into these technologies and implementations before making judgements. And use a bit more common sense about the whole thing while you are at it. This is all a bunch of hoopla over nothing. It is a way to gain readers and spark interest in another lull in the graphics market news arena.

Really, you should all take your tinfoil hats off now and stop video taping lunar landings from your basement. There is no sense or point for Nvidia coding anything for SSE when it works perfectly well for them under x87. There is no rational reason for them to do anything about it at this point. They have been moving on for some time and looking into other avenues already, same as ATI.

 

[Stoly]

BTW didn't intel just acknowledged recently that a gtx280 was 16 times faster than a core i7?

wouldn't that apply at least in part in physics performance?

 

[pxc]

wouldn't that apply at least in part in physics performance?

Yes. The "2x-4x" number in the article is from the high level framerate, such as 15fps (avg framerate, of course not constant PhysX effects) in some game with CPU PhysX vs say 60fps with GPU PhysX. It was pointed out in another thread that CPU PhysX can dip the framerate down to low single digits, while the GPU PhysX runs along at 40-something fps. And even with a great resullt like a 2x speed up using SSE2, the CPU version is still not good enough to replace a GPU. It would still be better of course if nvidia put some better optimizations into the CPU path.

 

[kllrnohj]

You mean besides the links I have already provided?

You didn't freaking post any. Here, lets look at the GCC one since that was the only link about performance in the first place:

Povray was compiled using "-pipe -Wno-multichar -O3 -march=k8-mtune=k8 -ffast-math -minline-all-stringops" for SSE.
The result of benchmark run was:
user 27m43.635s

387 benchmark was compiled with -mfpmath=387 added to compile flags.
The result of benchmark was:
user 28m40.049s

and this way many x87->mem->SSE moves were removed. The result of benchmark run is now:
user 27m27.141s

Since you missed it, that shows SSE being *FASTER* than x87 with little more than a compiler flag on a compiler not known for its good optimizations, and that was from 2006.

Like I said, did you even read the links you provided? Because they sure as shit didn't agree with you.

Passages in the article itself, and posts by others here explaining similar things?

All of which say SSE is faster than x87 - nobody but you has claimed otherwise.

You have yet to provide even one shred of evidence or one iota of facts period.

Um, yes, there were. The post right above mine that you quoted had a link that showed a *huge* improvement from SSE on a Pentium 4. Core 2 and i7 have since doubled SIMD performance.

1) If PhysX is so bad, then it doesn't matter, something else will take its place and this is a moot point.

2) If SSE is that much better than x87 than physics engines using SSE rather than x87 will take the place of PhysX and this is a moot point anyway.

You are making the assumption that the better technology will win - that assumption isn't even close to true, unfortunately.

3) Also if SSE was so much better than x87 and CPU instructions really were better for processing physics than Larrabee wouldn't be such a dead project and Havoc would be a lot more powerful than PhysX.

1) Larrabee has nothing to do with this.

2) Havoc very well could be more powerful than PhysX, but that doesn't mean anything in x87 vs. SSE. Havoc could simply have better algorithms than PhysX and vice versa. Havoc being faster or slower than PhysX really provides no evidence whatsoever on x87 vs. SSE.

4) OpenCL is being looked at and toyed with by both ATI and Nvidia and may replace their current offerings, which guess what? Makes this a moot point yet again.

No, it doesn't. This is about unoptimized CPU physics being compared to optimized GPU physics. If PhysX started using OpenCL, the issue doesn't go away.

5) Nvidia makes GPUs last time I checked and does not make CPUs. Which makes this a moot point.

That... is an idiotic statement. That is the reason we have this issue in the first place, because Nvidia has more to gain from keeping the library unoptimized. It isn't moot point at all, it's the core issue.

6) If Nvidia is such a horrible company, vote with your wallet and buy something else, which again makes this a moot point.

Only with articles like these are we able to learn what companies are doing to be able to vote with our wallet. The whole "vote with your wallet" only works if buyers are able to get the facts. You are arguing that we shouldn't know the facts. How the fuck can you make an informed decision then?

7) Even if you were to release it with SSE coding, that might make the CPU physics processing twice as fast which still makes it at best twice as slow as PhysX on the GPU and at worst still 4 times slower, even according to the article there are limited times when CPU physics processing might be better than GPU. The best case scenerio in the artilce is CPU processing going up by 4 times and being on par and maybe better in some cases. Really, you guys need to do more reading and research into these technologies and implementations before making judgements. And use a bit more common sense about the whole thing while you are at it. This is all a bunch of hoopla over nothing. It is a way to gain readers and spark interest in another lull in the graphics market news arena.

And it would make the "advanced" physics effects in games like Batman: AA playable on a CPU. And that only addresses the speedups from SSE, and not the additional speedups to be gained from multithreading.

So the point is that all the shit that Nvidia says a CPU isn't fast enough to handle (like the effects in Mirror's Edge and Batman: AA) isn't necessarily true, and is quite possibly a lie.

Really, you should all take your tinfoil hats off now and stop video taping lunar landings from your basement. There is no sense or point for Nvidia coding anything for SSE when it works perfectly well for them under x87. There is no rational reason for them to do anything about it at this point. They have been moving on for some time and looking into other avenues already, same as ATI.

lol wut? Calling a company out on dishonest behaviors makes you a conspiracy nut? Have fun getting ass raped by companies, I'll be over here trying not getting raped, kthxbai.

BTW didn't intel just acknowledged recently that a gtx280 was 16 times faster than a core i7?

wouldn't that apply at least in part in physics performance?

I'm not sure what you are referring to, but no. There is a huge difference between theoretical speeds and real world results. GPUs are perfect for graphics, not as much for physics. They do some physics faster than CPUs, and some slower, the question is how much faster is the faster stuff - and that is something we don't know at this point.

 

[NoOther]

You didn't freaking post any. Here, lets look at the GCC one since that was the only link about performance in the first place:



Since you missed it, that shows SSE being *FASTER* than x87 with little more than a compiler flag on a compiler not known for its good optimizations, and that was from 2006.


Like I said, did you even read the links you provided? Because they sure as shit didn't agree with you.

OMG, you really don't read anything do you?

So, at this point x87 code of a real world application (which is BTW the part of a SPEC suite) beats x86_64 SSE, despite the fact that SSE has two times as many non-stacked FP registers and implements register passing convention (thus avoiding memory moves). Following that, implementing x87 register passing convention we would surely remove at least some of more than 1300 remaining movlpds and some of 900 remainign movsd instructions (all with one memory operand)

Stop taking little bits out of context.

All of which say SSE is faster than x87 - nobody but you has claimed otherwise.

Wrong again. It never said SSE is faster than x87. It said that using SSE for multi-core, multi-thread processing would be better than the current x87 setup. It clearly stated that at best you would see about on par for performance in some cases, but in most cases it would still be slower than the GPU. Read the full article, at least the last page.

Um, yes, there were. The post right above mine that you quoted had a link that showed a *huge* improvement from SSE on a Pentium 4. Core 2 and i7 have since doubled SIMD performance.

Yes, SSE for CPU processing is faster than x87 for CPU processing for CISC instructions using simple math and not much trigonometry. That is not true for physics. You keep bringing apples and oranges into the comparisons.

You are making the assumption that the better technology will win - that assumption isn't even close to true, unfortunately.

You are doing nothing but making assumptions about everything. You don't even understand the things at work here. You provide NO evidence, NONE, zilch, nada. No links, no facts, no proof, no statistics, nothing. You are so far out of your depth it is unbelievable. Just give it up.

1) Larrabee has nothing to do with this.

Except it was Intel's answer to the graphics market with a card that could do everything in one and could excel at doing physics. Yeah, other than that...nothing. Right.

2) Havoc very well could be more powerful than PhysX, but that doesn't mean anything in x87 vs. SSE. Havoc could simply have better algorithms than PhysX and vice versa. Havoc being faster or slower than PhysX really provides no evidence whatsoever on x87 vs. SSE.

Except that if SSE was so much better at Physics than x87, then Intel could easily make Havoc much more powerful than PhysX. But Havoc is much less powerful than PhysX.

No, it doesn't. This is about unoptimized CPU physics being compared to optimized GPU physics. If PhysX started using OpenCL, the issue doesn't go away.

In which, yet again, the article says that even at its peak optimization for CPU physics, it at best would only beat GPU physics by a small margin, and in most cases would still be 2-4 times slower than GPU physics. Again, read the full article, especially the last pages.

That... is an idiotic statement. That is the reason we have this issue in the first place, because Nvidia has more to gain from keeping the library unoptimized. It isn't moot point at all, it's the core issue.

So if Nvidia decides to do away with PhysX altogether in the next year, somehow all of this would still mean anything? With only a few games still using PhysX now, this still means anything? Exactly how is this issue so critical in the first place? It is idiotic that you can't even read the articles, and that you believe somehow this is a big deal.

Only with articles like these are we able to learn what companies are doing to be able to vote with our wallet. The whole "vote with your wallet" only works if buyers are able to get the facts. You are arguing that we shouldn't know the facts. How the fuck can you make an informed decision then?

I never argued against knowing the facts. I am providing facts for you, you are the one blindly ignoring them.

And it would make the "advanced" physics effects in games like Batman: AA playable on a CPU. And that only addresses the speedups from SSE, and not the additional speedups to be gained from multithreading.

Games like Batman which is old now, and...how many other games exactly? Please, I want to know how absolutely gut wrenchingly bad this problem is and how far reaching it is that it is affecting soooo many people. Considering out of all the people playing games, how many even care about physics in the first place?

So the point is that all the shit that Nvidia says a CPU isn't fast enough to handle (like the effects in Mirror's Edge and Batman: AA) isn't necessarily true, and is quite possibly a lie.

Here again you are making assumptions, with no facts to back it up.

lol wut? Calling a company out on dishonest behaviors makes you a conspiracy nut? Have fun getting ass raped by companies, I'll be over here trying not getting raped, kthxbai.

How is Nvidia being dishonest, please tell me? How is it dishonest for Nvidia to program THEIR technology for THEIR purposes? Please, I really have to know this one. I really want to know how it is sooooo unfair that PhysX, an Nvidia technology is being exploited by Nvidia the owner of the technology.

I'm not sure what you are referring to, but no. There is a huge difference between theoretical speeds and real world results. GPUs are perfect for graphics, not as much for physics. They do some physics faster than CPUs, and some slower, the question is how much faster is the faster stuff - and that is something we don't know at this point.

Excuse me, but why are so many major physics processing plants and data modeling companies switching over to GPGPU enabled supercomputers if CPUs are sooooo much better for physics? Where did anyone ever say that CPUs are far superior for physics? You are starting to mix things up a bit here. There is a difference between having passable physics affects using the CPU, which is what the article is talking about, and having dedicated physics devices designed for crunching physics. The article is not at all saying in any shape or form that CPU physics are much faster than GPU. In fact it claims just the opposite, that in almost all cases, GPU physics will still be faster, but the margin would be slimmer than it is now.

Again, READ the articles.

 

[kllrnohj]

OMG, you really don't read anything do you?

Unfortunately for you, I did read it.

Stop taking little bits out of context.

How can the results possibly be out of context? Test A took X long, Test B took Y long, X > Y, thus, B is faster.

His conclusion was also not supported by the data. For both the 32bit and 64bit tests, SSE was faster.

Also, did you read the follow ups to that message? I'm guessing not:

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

As I said, GLIBC doesn't have fast routines for x86-64. SUSE and others do, but neither FSF nor RH do.

...

That's not the correct conclusion. As I said, you haven't isolated x87 microcode vs. GLIBC math functions...

And again, that is from 2006 with code that only had a compiler flag change on a compiler that does not do automatic vectorization, and does not produce well optimized code. Basically, that test doesn't mean jack shit. It is entirely useless.

Also, you don't seem to be understand what is going on. Povray wasn't using vectorized SSE, hence the very minor speedup:

http://abinstein.blogspot.com/2007/05/pov-ray-benchmark-and-amds.html

It turns out that none of these questions is appropriate. Because - (1) PoV-Ray's usage of SSE2 is not SSE (Stream SIMD Execution) at all, but really double-precision FP with random register access; (2) PoV-Ray SSE seems to be optimized more specifically for Core 2 than anything else, where on K8 it is only about 5% faster than PoV-Ray x87. This is also not going to change with K10.

First, there is no actual usage of vectorized (or packed) instructions in PoV-Ray SSE. The only packed instructions I see from the binary are register conversions between x87 and SSE2 formats. PoV-Ray SSE basically treat the SSE2 as a faster [sic] x87 engine which can access xmm registers randomly (rather than stack-based in x87). For example, a simple double-precision division in PoV-Ray SSE is performed by the following instruction sequence:

Wrong again. It never said SSE is faster than x87. It said that using SSE for multi-core, multi-thread processing would be better than the current x87 setup. It clearly stated that at best you would see about on par for performance in some cases, but in most cases it would still be slower than the GPU. Read the full article, at least the last page.

There are *TWO* problems, you are mashing them together as if they are linked, they aren't.

Problem 1: PhysX is using x87, which is slower than SSE

Problem 2: PhysX isn't multithreaded

The two problems are *NOT* linked in any way. SSE has *nothing* to do with threading. Oh, and FYI, thread switches are *faster* if you *don't* have SSE enabled.

And from the article:

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 accessses are substantially faster (e.g. 2X for AMD processors) as they use a relaxed consistency model. So why is PhysX using x87?

SSE2 vectorized blows the doors off of x87. SSE2 scalar is still slightly faster, although not as much.

Notice that there is no mention of threads in that paragraph, because threads have NOTHING TO DO WITH THIS. This is about making each individual thread go faster.

Yes, SSE for CPU processing is faster than x87 for CPU processing for CISC instructions using simple math and not much trigonometry. That is not true for physics. You keep bringing apples and oranges into the comparisons.

You keep claiming apples and oranges, but again, it isn't. x87 and SSE both tackle the exact same thing. They are both about doing floating point on CPUs. SSE is the faster, better replacement for x87.

Now you are also throwing around buzwords like CISC to further highlight your own ignorance about instructions. Seriously, "SSE is faster than x87 for CPU processing for CISC instructions" literally makes no sense. I'm pretty sure you just looked up some cool sounding words and abbreviations and decided to mash them together, because that statement doesn't work at all. Also, "simple math" - hehe, nice one.

You are doing nothing but making assumptions about everything. You don't even understand the things at work here. You provide NO evidence, NONE, zilch, nada. No links, no facts, no proof, no statistics, nothing. You are so far out of your depth it is unbelievable. Just give it up.

Sorry, but you claimed CUDA ran x87. Claiming that I don't know what I'm talking about after making that claim pretty much gives you zero credibility. I mean really.

I fully understand the things at work here. I've worked with them. I've coded SSE. Have you?

Except it was Intel's answer to the graphics market with a card that could do everything in one and could excel at doing physics. Yeah, other than that...nothing. Right.

Exactly, nothing to do with this because this is about PhysX running on a CPU.

But Havoc is much less powerful than PhysX.

[Citation Needed]

In which, yet again, the article says that even at its peak optimization for CPU physics, it at best would only beat GPU physics by a small margin, and in most cases would still be 2-4 times slower than GPU physics. Again, read the full article, especially the last pages.

Yes, and? The point is to improve the lowest common denominator.

So if Nvidia decides to do away with PhysX altogether in the next year, somehow all of this would still mean anything? With only a few games still using PhysX now, this still means anything? Exactly how is this issue so critical in the first place? It is idiotic that you can't even read the articles, and that you believe somehow this is a big deal.

What is idiotic is you arguing about instruction sets when you clearly don't have the slightest clue what is going on.

I never argued against knowing the facts. I am providing facts for you, you are the one blindly ignoring them.

But you haven't provided facts. The things you have provided have had flaws pointed out (major ones) by not just myself but others here.

Here again you are making assumptions, with no facts to back it up.

The ARTICLE is the fact to back it up. And I didn't assume anything. My statement didn't have any assumptions in it at all.

How is Nvidia being dishonest, please tell me? How is it dishonest for Nvidia to program THEIR technology for THEIR purposes? Please, I really have to know this one. I really want to know how it is sooooo unfair that PhysX, an Nvidia technology is being exploited by Nvidia the owner of the technology.

Because Nvidia is artificially increasing the performance difference between CPU and GPU to try and sell more of their product. Dishonest. They are inflating the numbers to try and sell product.

Excuse me, but why are so many major physics processing plants and data modeling companies switching over to GPGPU enabled supercomputers if CPUs are sooooo much better for physics?

Excuse me, can you read? Really truly, can you? I'm begging to have doubts, because I never said "CPUs are sooooo much better for physics". I never even said CPUs were on par with GPUs.

Where did anyone ever say that CPUs are far superior for physics?

Apparently only in your head. Nobody in this thread has said anything of the sort.

You are starting to mix things up a bit here. There is a difference between having passable physics affects using the CPU, which is what the article is talking about, and having dedicated physics devices designed for crunching physics. The article is not at all saying in any shape or form that CPU physics are much faster than GPU. In fact it claims just the opposite, that in almost all cases, GPU physics will still be faster, but the margin would be slimmer than it is now.

Which is a claim *I* am defending, and *YOU* were refuting. You originally were claiming the article was wrong and I was claiming it was right. Now it seems you are trying to switch your viewpoint to agree with mine while still trying to disagree with me so that you don't have to admit you didn't have a clue what you were talking about when you first entered this discussion.

 

[Cobalt35]

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.

What advantages would these be, exactly?

Back to the actual article, things like this are why, at least at this stage, I never plan to purchase anything from nVidia again. They have deliberately gone out of their way (and continue to do so) to fudge the results to make their product look better and other products look worse. They're deliberately crippling PhysX on the CPU to artificially make their product look better.

While this is their right, as the owner of PhysX, it doesn't make it right.

 

[Stoly]

What advantages would these be, exactly?

Back to the actual article, things like this are why, at least at this stage, I never plan to purchase anything from nVidia again. They have deliberately gone out of their way (and continue to do so) to fudge the results to make their product look better and other products look worse. They're deliberately crippling PhysX on the CPU to artificially make their product look better.

While this is their right, as the owner of PhysX, it doesn't make it right.

Interesting. So you'd rather have a gpu that doesn't accelerate ANY physics at all that one that does.

Yeah, that makes sense.

 

[pxc]

They're deliberately crippling PhysX on the CPU to artificially make their product look better.

Not necessarily.

It's not like nvidia made CPU PhysX any slower, just that they haven't used an obvious optimization. But yeah, that decision does make GPU PhysX look better by comparison.

What annoys me about the article is the suggestion that there's only a 2-4x difference between PhysX calculations on the CPU and GPU. That's just not true. The revered Velocity Engine (with Infernal CPU physics engine) "handles" 3500 simple boxes and one force actor by maxing out 8 threads on a Core i7... at a very low double digit fps rate. GPU physics (old Havok FX demonstrations and GPU PhysX) can handle dozens of times more *complex* shapes (i.e., meshed models) at a time at a very high framerate.

 

[GotNoRice]

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.

Dude none of that is accurate at all.

I worked with Ageia at one point and i'll tell you straight-up they were about the Engine, not the PPU. They didn't even make it. PhysX evolved out of an older Physics engine that Ageia bought called Novodex. Their #1 goal from the very beginning was to get the engine out on as many platforms and for as many games as possible, and in that sense they succeed. PhysX runs on the PS3, XBox360, and even the Wii and is used on quite a few games for those platforms. In many cases they were able to optimize the engine to each console's particular hardware, and on some consoles like the PS3 results in some pretty amazing performance.

Also consider the CPU market at the time the PPU was released (2006). Conroe/kentsfield was still pretty much brand new and the average gamer was probably still milking their Athlon64 or Pentium4 systems at that point.

Yet they actually did optimize for the CPU. I remember vividly how PhysX would max out all four virtual cores of the Dual-Xeon rig I had at the time, and was able to do the same on my Q6600 also when I got it a year later. I remember cellfactor being able to max out all the CPU cores also without a PPU in the system. They were interested primarily in making the engine as attractive as possible to developers, including making it run well on systems without a PPU.

PhysX being gimped on the CPU is something that happened after Nvidia bought it.

 

[NoOther]

Unfortunately for you, I did read it.


Which is a claim *I* am defending, and *YOU* were refuting. You originally were claiming the article was wrong and I was claiming it was right. Now it seems you are trying to switch your viewpoint to agree with mine while still trying to disagree with me so that you don't have to admit you didn't have a clue what you were talking about when you first entered this discussion.

Dude, just stop, you don't make any sense at all. I was never saying the article was right. I was saying that the article YOU were defending, wasn't even agreeing with you. You are the one that keeps waffling around with viewpoints. And you still are taking everything out of the context in which it was written and tested. You keep claiming you know what is going on, but you still provide ZERO facts or examples. You still keep spouting off claims with no proof and waffle around with your words. There is a very well informed user on AnandTech that DOES work in the field and explained a lot of it and I provided that link as well.

The facts still remain:

Is SSE faster than x87 for physics on CPUs, yes. Is doing physics faster on CPUs than GPUS, no. Is Nvidia trying to hobble the CPU intentionally? That is all conjecture with no real proof. Nvidia has NO obligation to improve PhysX performance for CPU, because it is a tool for Nvidia's GPU cards. That is what they are selling. So again, that is the point being made here. For the already incredibly small market that PhysX is, to make claims that Nvidia is being the bad guy by hobbling CPU PhysX is pretty lame. And even if they were intentionally doing that, who cares? It is THEIR product, they can do what they want with it. It doesn't make them evil at all. It also doesn't make me want to buy or support PhysX, though.

 

[Elledan]

I love it when people without a clue state that it 'only takes a recompile'. Unless you're very lucky, changing from x87 to SSE will take some serious debugging/rewrites, especially if ASM is used and/or assumptions are made. The resulting code will hardly be optimized as well.

Yes, PhysX could be faster on CPUs, but that's not what it is meant for. It's aimed at running physics calculations quickly on GPUs. It's also free, so if you have a problem with PhysX not running too fast on CPUs, use Bullet instead. It's free and supposedly an OpenCL-based GPU-accelerated version will be out some time as well. There's no reason to use Havok or other non-free physics libraries unless they have something very specific you need.

 

[kllrnohj]

I love it when people without a clue state that it 'only takes a recompile'. Unless you're very lucky, changing from x87 to SSE will take some serious debugging/rewrites, especially if ASM is used and/or assumptions are made. The resulting code will hardly be optimized as well.

Not necessarily. PhysX can use AltiVec, which is the SIMD instructions for PPC (PS3 uses it) that is *very* similar to SSE. It shouldn't take some serious debugging/rewrites at all, given the multiplatform nature of PhysX in the first place. If PhysX was only on the PC, then you'd have a point, but it was designed to run on multiple platforms, meaning any PC-specific ASM optimizations would be at least partially abstracted so that the low level optimizations can target the specific platform, be it x87, AltiVec, or CUDA.

Also, things like Intel's compiler support automatic vectorization, so even just a simple recompile would likely give some improvement from SSE. Probably not much, but some.

Dude, just stop, you don't make any sense at all. I was never saying the article was right. I was saying that the article YOU were defending, wasn't even agreeing with you.

But it DOES agree with me. Please point out where it doesn't. Preferably with quotes from the article.

You are the one that keeps waffling around with viewpoints.

No, I'm not. My viewpoint hasn't changed at all.

And you still are taking everything out of the context in which it was written and tested.

No, I haven't, I refuted the link you provided. Nothing was taken out of context.

You keep claiming you know what is going on, but you still provide ZERO facts or examples.

Yes, I have, and so have others - you just chose to ignore them or shrug them off claiming they were "simple maths".

You still keep spouting off claims with no proof and waffle around with your words. There is a very well informed user on AnandTech that DOES work in the field and explained a lot of it and I provided that link as well.

I work in the field too, so if that's all it takes to become an expert, well, sucks for you.

And others have already claimed Scali is wrong, by the way, but even then, he only disagrees with the article on how much faster SSE would be, not whether or not it is faster.

Is Nvidia trying to hobble the CPU intentionally? That is all conjecture with no real proof.

There IS proof - that is what the article is!

Nvidia has NO obligation to improve PhysX performance for CPU, because it is a tool for Nvidia's GPU cards. That is what they are selling.

Agreed...

So again, that is the point being made here.

By who? You? Or the article? Because nobody is arguing that point.

For the already incredibly small market that PhysX is, to make claims that Nvidia is being the bad guy by hobbling CPU PhysX is pretty lame. And even if they were intentionally doing that, who cares? It is THEIR product, they can do what they want with it. It doesn't make them evil at all. It also doesn't make me want to buy or support PhysX, though.

*sigh*

Because they are comparing GPUs to CPUs using PhysX as the benchmark to demonstrate how much faster the GPU is, yet the CPU path isn't optimized. That is *DISHONEST*. THAT is what the article is about. Why are you unable to understand that? WHY?

What annoys me about the article is the suggestion that there's only a 2-4x difference between PhysX calculations on the CPU and GPU. That's just not true. The revered Velocity Engine (with Infernal CPU physics engine) "handles" 3500 simple boxes and one force actor by maxing out 8 threads on a Core i7... at a very low double digit fps rate. GPU physics (old Havok FX demonstrations and GPU PhysX) can handle dozens of times more *complex* shapes (i.e., meshed models) at a time at a very high framerate.

True, but software PhysX and Havok can both handle complex shapes (cloth, deforming objects, etc...) as well. The article seems to be basing its 2-4x difference claim on the comparisons between PhysX on the CPU and PhysX on the GPU in actual game usage, and not tech demos.

 

[XMAN245]

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

Right, and this is why every game that uses havok has preprogrammed, prerendered, constantly repeating crap. please. If havok was truely utilized, it would devasted even the i7 980X

 

[pxc]

nvidia responded to the article: http://arstechnica.com/gaming/news/...cpu-gaming-physics-library-to-spite-intel.ars

If you're not going to read it, the take away is that AAA developers have the source code to PhysX and they still compile it to x87. The 2.x codebase is from before 2005. A 3.0 rewrite is coming next year with SSE and other optimizations. Even with a 2x speed boost, it will not be competitive with GPU PhysX.

 

[Gorankar]

^^^^^If true, then the devs are being lazy again?
Well, that kind of makes sense, since GPU acceleration is almost never used unless Nv implements it for the dev. Why would devs care about gpu or even decent cpu physics on PC when they are coding primarily for the consoles with maybe a quick and dirty port over to PC afterward anyway? It is not like they think they are loosing any sales over it since piracy is the reason for every game failure in their eyes.

 

[Elledan]

^^^^^If true, then the devs are being lazy again?
Well, that kind of makes sense, since GPU acceleration is almost never used unless Nv implements it for the dev. Why would devs care about gpu or even decent cpu physics on PC when they are coding primarily for the consoles with maybe a quick and dirty port over to PC afterward anyway? It is not like they think they are loosing any sales over it since piracy is the reason for every game failure in their eyes.

As the Arstechnica article says, an average PC CPU is much more powerful than current console CPUs, so even a sluggish CPU physics thread is likely to perform at least as good as multiple threads on these consoles. Don't forget that the current generation consoles are from 2005-2006. Is anyone seriously playing current high-end games on a PC from that time?

 

[pxc]

^^^^^If true, then the devs are being lazy again?

Not really. IMO the developers understand something that the armchair programmers won't accept: CPU physics are limited. Single digit FPS while heavy CPU PhysX effects are running (in Batman AA, for example) aren't going to be fixed by teasing out 1.3-2x gains.

I pointed it out earlier. Take the Velocity Engine, which has the Infernal physics engine, as an example. It's fully multi-threaded. Maxing out 8 threads on a Core i7, you get CPU physics for 3500 simple boxes and one force actor... at very low double digit framerates (see the Velocity Engine Tornado demo from late 2009). Even four year old GPUs can do much, much better than that, with more objects, more complex objects and at a much higher framerate (see the ATI and nvidia Havok FX GPU physics demos from 2006).

I'm glad RWT posted the analysis. It finally got nvidia to officially address the problems in a more open way. But there's no simple or even complex fix that's somehow going to make CPU physics competitive with GPU physics.

 

[kllrnohj]

^^^^^If true, then the devs are being lazy again?

No, it means that the devs are just sticking to Nvidia's instructions and build scripts. It means that the devs aren't interested in improving PhysX for Nvidia.

Not really. IMO the developers understand something that the armchair programmers won't accept: CPU physics are limited. Single digit FPS while heavy CPU PhysX effects are running (in Batman AA, for example) aren't going to be fixed by teasing out 1.3-2x gains.

We all understand that CPU physics are limited, but the CPU isn't the bottleneck with PhysX, which is what people are complaining about. Batman AA, for example, is x87, scalar, and single threaded physics. That leaves boatloads of CPU resources unused.

Improve single threaded performance 1.3-2x with vectorized SSE. Then add multithreading, and you can improve performance another 2-4x. All that adds up in hurry. 10fps can suddenly turn into 40fps.

I pointed it out earlier. Take the Velocity Engine, which has the Infernal physics engine, as an example. It's fully multi-threaded. Maxing out 8 threads on a Core i7, you get CPU physics for 3500 simple boxes and one force actor... at very low double digit framerates (see the Velocity Engine Tornado demo from late 2009). Even four year old GPUs can do much, much better than that, with more objects, more complex objects and at a much higher framerate (see the ATI and nvidia Havok FX GPU physics demos from 2006).

The Velocity Engine could also do 1500 boxes and 200 ragdolls with very smooth framerates from the same demo. Also, you claim "very low double digit framerates", but where did you get that information from? Any stutters in the video could just as easily be from the recording, encoding, or whatever crap viddler did with it - which happens all the time. 3500 boxes looks pretty smooth to me.

Do you have any GPU examples that are similar? A quick google search didn't pull up anything interesting, and nothing with any actual numbers. Also, the CPU can do more complex objects as well: http://www.youtube.com/watch?v=daZoXzBGea0

But yes, GPUs can do much, much more than that - but can they do it WHILE rendering the game? Quad core CPUs are shipping in the $500 HPs you buy from office max, high end video cards aren't. The point is that there is essentially free untapped CPU power, power that could be used for improved physics.

But there's no simple or even complex fix that's somehow going to make CPU physics competitive with GPU physics.

Of course, but there are plenty of fixes to greatly improve CPU physics. GPU will still be faster, but we are talking about some huge improvements with the CPU are possible.

 

[pxc]

Improve single threaded performance 1.3-2x with vectorized SSE. Then add multithreading, and you can improve performance another 2-4x. All that adds up in hurry. 10fps can suddenly turn into 40fps.

Your example is unrealistically optimistic, and starting at a point much higher than is actually seen. I was being nice about not calling it a pitifully low single digit fps. Who cares if it goes from 2-3 fps when heavy effects are running on the CPU to 8 or 12 fps. It's still majorly unplayable. The most optimistic "fix" does not really fix the problem. If you want faster high PhysX in Batman AA, there's already a solution. Wishing and whining about it doesn't change that fact.

And don't forget those CPU core(s) also needs to run other game code.

Just watch the Tornado video before you start making excuses. As more objects are added, you can see it going from smooth animation to struggling when 3500 simple boxes and one force actor are on screen. My best guesstimate is that the framerate appears to be 15fps or so, while the less demanding load were running smoothly at 30fps or higher.

 

[Elledan]

CPU: 4-8 SIMD units.
GPU: 50+ SIMD units.

GPU wins

 

[kllrnohj]

Your example is unrealistically optimistic, and starting at a point much higher than is actually seen. I was being nice about not calling it a pitifully low single digit fps. Who cares if it goes from 2-3 fps when heavy effects are running on the CPU to 8 or 12 fps. It's still majorly unplayable. The most optimistic "fix" does not really fix the problem. If you want faster high PhysX in Batman AA, there's already a solution. Wishing and whining about it doesn't change that fact.

I'm pretty sure it isn't 2-3 fps, though. I'll test it tonight, but people were getting ~30fps with the advanced physics on the CPU with reduced simulation quality.

And don't forget those CPU core(s) also needs to run other game code.

Sure, but that still leaves 3 cores free, give or take.

Just watch the Tornado video before you start making excuses. As more objects are added, you can see it going from smooth animation to struggling when 3500 simple boxes and one force actor are on screen. My best guesstimate is that the framerate appears to be 15fps or so, while the less demanding load were running smoothly at 30fps or higher.

I did watch the Tornado demo, and there were some FPS drops but it looked like the FPS was easily in the 20s to me, if not higher at points. This is also with textures, lighting, shaders, etc... (like a real game) and not just an empty gray room with a bunch of solid color boxes like most physics demos have. So the FPS drops could have even been from the graphical side of thing - that was a lot of dynamic shadows to crunch through. Just to clarify I'm not saying that that was what happened, just that you really can't make the claim that Velocity can only do low double digits with 3500 boxes - you really don't know what the bottleneck was or what the FPS was.