Radeon PhysX GPU Acceleration?

[[H]ocusPocus]

Most important thing is that with CPU physics you're completely CPU-limited.

If you replaced "physics" above with "PhysX" I would agree Call me cynical, but I have a hard time believing those working on PhysX have spent any time optimizing code to run on the cpu, let alone a multi-core cpu. At the end of the day, Nvidia (and Ageia before it) is a hardware company interested in selling their hardware. For hardware companies, software is just a means to sell more hardware. To be broadly accepted, the software may need to run on the competitor's hardware but that doesn't mean it needs to run well.

 

[Scali2]

If you replaced "physics" above with "PhysX" I would agree Call me cynical, but I have a hard time believing those working on PhysX have spent any time optimizing code to run on the cpu, let alone a multi-core cpu. At the end of the day, Nvidia (and Ageia before it) is a hardware company interested in selling their hardware. For hardware companies, software is just a means to sell more hardware. To be broadly accepted, the software may need to run on the competitor's hardware but that doesn't mean it needs to run well.

Except that Ageia just bought it from NovodeX... NovodeX was already a well-optimized physics library running on multicore CPUs and various consoles.
Neither Ageia nor nVidia artificially crippled the original NovodeX code, so it still runs as fast as it did before any hardware-acceleration was added. Which is quite competitive with other solutions, such as Havok.
There is also no reason to cripple it, as CPUs aren't even in the same league of PPUs and GPUs anyway, when it comes to physics.

So, nice try, but you're wrong.

 

[pxc]

This kind of reminds me of years ago when hardware T&L was still new. nvidia was first, then ATI followed, leaving 3dfx and S3 (S2000 had broken T&L) out. 3dfx was on the decline, but still had a fiercely loyal following.

CPU extensions could be used for T&L calculations as before, and while a speedy CPU at the time could nearly equal the T&L thoughput of the GeForce256, that left little available CPU resources left to run the game. Hardware accelerated physics is still in its infancy, but the shift should accelerate to push it off the CPU now that it's becoming mainstream.

Larrabee is a special case since it runs x86 code, but multi-core CPU physics will not catch up to GPU physics. CPU performance increases pale in comparison to what GPUs increase in the same period of time.

 

[Gorankar]

Actually the first GeForce was worse than the high end cpu's of the day for T&L past 1 light. You lost performance with it enabled. They fixed that with the second GeForce. After that pretty much everyone still in business had it or had it coming up soon. So, obviously it was adopted.

It is a matter of whether or not it is accepted. Whether or not the devs will put the xtra work into the code, without Nv paying them. Since, Nv can only afford to pay so much, to so many, for so long. A truly open, unified, api would open the doors a lot faster than 2 competing not truly open api's. Even with PhysX being first to market.

I understand Nv's move, they are trying to make gpu accelerated PhysX the standard b4 Intel comes in and makes hardware accelerated Havock the standard. Unless Ati jumps on, I just don't think it will happen though. Just my opinion.

 

[Scali2]

Larrabee is a stripped x86 with SIMD units bolted on that quite closely resemble the 'stream processors' that AMD and nVidia use.
I think a lot of people are confused by the term 'x86' and think it's just a Core2 with more cores.
Aside from it being able to understand (some of) the same instructions, it will have very little in common with a Core2, and a lot in common with an AMD or nVidia GPU.

 

[Scali2]

Actually the first GeForce was worse than the high end cpu's of the day for T&L past 1 light. You lost performance with it enabled. They fixed that with the second GeForce. After that pretty much everyone still in business had it or had it coming up soon. So, obviously it was adopted.

You needed games that were properly designed to take advantage of hardware T&L. For Direct3D it meant you had to use at least Direct3D 7, else hardware T&L wouldn't be used at all.
For OpenGL the driver could silently pass on the T&L workload to the hardware in some cases, but this could be very suboptimal if the game rendered in small batches and/or changed states often. This wouldn't affect CPUs much, because state changes had little or no extra overhead on CPUs, but GPUs were more like batch processors, and preparing new batches would dramatically decrease output.
As games became more streamlined, T&L became more powerful.

 

[pxc]

Actually the first GeForce was worse than the high end cpu's of the day for T&L past 1 light.

Nope. The GeForce256 was ahead on triangle throughput and lighting. Typical results at the time showing the advantage of hardware T&L: http://www.nvnews.net/reviews/geforce_256/3dexercizer.shtml and http://www.nvnews.net/reviews/geforce_256/3dwinmark_2000.shtml

You may be thinking of S3's disasterous T&L implementation that was slower than software T&L. If you're not confusing it, thanks for demonstrating the (wrong) thinking at the time.

 

[Gorankar]

Nope. The GeForce256 was ahead on triangle throughput and lighting. Typical results at the time showing the advantage of hardware T&L: http://www.nvnews.net/reviews/geforce_256/3dexercizer.shtml and http://www.nvnews.net/reviews/geforce_256/3dwinmark_2000.shtml

You may be thinking of S3's disasterous T&L implementation that was slower than software T&L. If you're not confusing it, thanks for demonstrating the (wrong) thinking at the time.

Links to a comparison on synthetic benches against itself and a TNT2 are not really convincing. I can do that too though. http://www.hardocp.com/article.html?art=MjQzLCwsaGVudGh1c2lhc3Q= ,http://www.hardocp.com/article.html?art=MjQyLCwsaGVudGh1c2lhc3Q=, and one more using an actual game http://www.hardocp.com/article.html?art=MjQxLDIsLGhlbnRodXNpYXN0 But we are off topic. T&L was adopted, will PhysX?

I'm not arguing whether the current cards have the power to run physics along side their traditional duties or not. It seems they do. I am saying it is meaning less, or will be painfully slow to be adopted if there is not a truly open API involved. Intel may make the whole thing a royal mess if Ati and Intel start using gpu accelerated Havoc. All three need to get together and cross license everything if we want this universally adopted within a reasonable time frame. I don't see it happening though.

 

[Scali2]

Well, it seems that nVidia has already won a lot of developers over, because their solution already has a large installed base... and a lot of developers are part of the TWIMTBP program anyway.

So I think there's a good chance that PhysX will become the most popular solution simply because it was the first on the market.
Intel doesn't even have the hardware in production yet...
As for ATi, it's still unclear what they will do in the end... Will they team up with nVidia and become PhysX-compatible? Will they team up with Intel and become Havok-compatible?
Or will they come up with their own API?
All we know is that they don't have a working solution yet, and it may take a while before they do. Which means nVidia will be trying to take over the market in the time they have.

 

[pxc]

Links to a comparison on synthetic benches against itself and a TNT2 are not really convincing. I can do that too though. http://www.hardocp.com/article.html?art=MjQzLCwsaGVudGh1c2lhc3Q= ,http://www.hardocp.com/article.html?art=MjQyLCwsaGVudGh1c2lhc3Q=, and one more using an actual game http://www.hardocp.com/article.html?art=MjQxLDIsLGhlbnRodXNpYXN0 But we are off topic. T&L was adopted, will PhysX?

Just to go over [H]'s results, see this old B3D article: http://www.beyond3d.com/content/articles/50/3

The points are important, besides nvidia trying to wiggle out of the test (see the conclusion). The simple lights used in 3DMark2000 are more favorable to the custom T&L engine used in 3DMark, not using the engine in DX like most games did. More complex lighting like specular highlights, also used in games, favored hardware T&L. It's funny how you can go back 8 years and see in perspective that 3DMark was not a good tool even back then.

[H]'s results were interesting and unique, and at least it led to a good exploration here and other sites. In general, hardware T&L was a good thing because it freed up the CPU (my initial point).

 

[Scali2]

The points are important, besides nvidia trying to wiggle out of the test (see the conclusion). The simple lights used in 3DMark2000 are more favorable to the custom T&L engine used in 3DMark, not using the engine in DX like most games did. More complex lighting like specular highlights, also used in games, favored hardware T&L. It's funny how you can go back 8 years and see in perspective that 3DMark was not a good tool even back then.

Actually, most games did write their own custom T&L routines. Firstly because they were more flexible than what D3D offered (especially in earlier versions), secondly because it could be optimized further.
Also, specular lighting wasn't used much, if at all, in games until recently.

 

[pxc]

Why do you say either one? It's easily shown that even older DX 7 games got boosts from hardware T&L. And specular lighting has been around a lot longer than recently in DX games.

 

[[H]ocusPocus]

Except that Ageia just bought it from NovodeX... NovodeX was already a well-optimized physics library running on multicore CPUs and various consoles.
Neither Ageia nor nVidia artificially crippled the original NovodeX code, so it still runs as fast as it did before any hardware-acceleration was added. Which is quite competitive with other solutions, such as Havok.
There is also no reason to cripple it, as CPUs aren't even in the same league of PPUs and GPUs anyway, when it comes to physics.

So, nice try, but you're wrong.

So NovodeX optimized this several years ago before Ageia (and thus Nvidia) were involved. Ok, great. I specifically mentioned my doubts about Ageia and Nvidia working on cpu optimizations so I don't see that as wrong. But lets just go with the assumption that PhysX is fairly well optimized for todays multi-core cpus. Why then does the cpu usage chart from the article show little to no impact on average cpu utilization when PhysX is running on the cpu? It just seems very odd.

 

[Scali2]

Why do you say either one? It's easily shown that even older DX 7 games got boosts from hardware T&L. And specular lighting has been around a lot longer than recently in DX games.

Specular lighting itself has been around since the 70s at least... But in most games it wasn't used much until recently, or it could be enabled as a high quality setting.
Games like Quake 1, 2, 3 or HalfLife 1 didn't make much use of specular highlighting, if at all.
It's not like modern games, where specular lighting is used on everything. So even though hardware T&L didn't scale that well with specular lighting, that doesn't mean that it would actually hamper performance in actual games.

 

[Scali2]

So NovodeX optimized this several years ago before Ageia (and thus Nvidia) were involved. Ok, great. I specifically mentioned my doubts about Ageia and Nvidia working on cpu optimizations so I don't see that as wrong. But lets just go with the assumption that PhysX is fairly well optimized for todays multi-core cpus. Why then does the cpu usage chart from the article show little to no impact on average cpu utilization when PhysX is running on the cpu? It just seems very odd.

Average CPU utilization is not a measure of efficiency or performance.
You have to look much deeper into what kind of workloads are being used and how they can be distributed, before you can draw any kinds of conclusions about CPU utilization at all.
I'm getting a bit tired of people who think something is not optimal when you don't get 100% CPU all the time. They've criticized some of my routines on that aswell, without knowing the first thing about them. The reason why my routines didn't get 100% CPU time is because the Direct3D portion of the code must run in a single thread, and the other threads have to wait on it. So in that case, the only way to get 100% CPU is to disable the Direct3D portion, which defeats the purpose.
There are various other perfectly valid reasons why a very efficient and optimized routine will never get 100% CPU.

 

[kllrnohj]

So NovodeX optimized this several years ago before Ageia (and thus Nvidia) were involved. Ok, great. I specifically mentioned my doubts about Ageia and Nvidia working on cpu optimizations so I don't see that as wrong. But lets just go with the assumption that PhysX is fairly well optimized for todays multi-core cpus. Why then does the cpu usage chart from the article show little to no impact on average cpu utilization when PhysX is running on the cpu? It just seems very odd.

CUDA requires the CPU to feed it, which likely ate up any leftover CPU cycles that using GPU accelerated PhysX freed up.