View Full Version : bit-tech Richard Huddy Interview - good Read
http://www.bit-tech.net/bits/interviews/2010/01/06/interview-amd-on-game-development-and-dx11/5
Some good questions there, interesting read.
Broken Hope
06-Jan-2010, 14:54
What I don't understand is after the following Quote
The bottom line is we have enough; we don't let triple-A or double-A titles go through the net and in fact it's extremely rare for a Saboteur situation to come up. It's very rare for titles as a whole to go past us without seeing our QA and testing labs along the way. Our team is big enough and actually exceedingly good at some of the things they do. I believe it is smaller than the Nvidia team that's directly related to developer relations, but I have some of the best engineers in the world doing some really great stuff in terms of R&D with graphics optimisations: lighting and shadowing.
Why so many new games come out with glaring problems on ATI cards that don't get fixed until months later, by then most gamers are finished with the game that is having problems.
Games like Borderlands having grey texture bugs for months after release that only got fixed in Catalyst 9.12, Resident Evil 5 having the screen black out during cut scenes, MW2 having bugs with flash bangs, Many have been unable to force AF in Dragon Age since the 9.11's. NFS Shift taking months to be fixed etc
In a pretty big way ATI's rigid one driver per month release schedule has hurt them. Users shouldn't have to deal with such huge bugs on new games, having to wait for months after release before they can play them, bugs which users of Nvidia cards don't have.
bugs which users of Nvidia cards don't have.
Sorry? have you ever read one "new nv driver" release thread? The land seems to be too barren for grass to be green on both sides of the fence.
Unless, of-course, you think that This (http://forums.nvidia.com/index.php?showtopic=151917&pid=975496&mode=threaded&start=#entry975496) is something that's not described as an issue.
Broken Hope
06-Jan-2010, 15:12
Sorry? have you ever read one "new nv driver" release thread? The land seems to be too barren for grass to be green on both sides of the fence.
Unless, of-course, you think that This (http://forums.nvidia.com/index.php?showtopic=151917&pid=975496&mode=threaded&start=#entry975496) is something that's not described as an issue.
I'm not saying Nvidia drivers are 100% bug free, but for new release games I see far more ATI users having issues than Nvidia users, are you saying it's the opposite?
trinibwoy
06-Jan-2010, 15:16
Lol, I'm impressed. He managed to drop quite a few zingers in there :lol:
bit-tech: IF - given we don't know yet - when Nvidia's Fermi cards finally arrive they are faster than your HD 5970-
RH: -Well if it's not faster and it's 50 per cent bigger, then they've done something wrong-
I'd be inclined to believe Huddy is thinking the question is about the 5870 when he says this, but I've read the same sentiment before on this forum. Why would a Fermi card need to be faster than a dual GPU Cypress card?
I'm not saying Nvidia drivers are 100% bug free, but for new release games I see far more ATI users having issues than Nvidia users, are you saying it's the opposite?
No I'm saying both have their own fair share of issues.
I'd be inclined to believe Huddy is thinking the question is about the 5870 when he says this, but I've read the same sentiment before on this forum. Why would a Fermi card need to be faster than a dual GPU Cypress card?
5970 Also does not make sense to me, could be an honest typo (at least they didn't write "Firmy")
Lightman
06-Jan-2010, 18:10
5970 Also does not make sense to me, could be an honest typo (at least they didn't write "Firmy")
50% bigger than dual RV870 is like 1000mm2 die so everything points out to a typo :smile:
Very good interview indeed!
This bit make my day :lol::
[Nvidia] put PhsyX in there, and that's the one I've got a reasonable amount of respect for. Even though I don't think PhysX - a proprietary standard - is the right way to go, despite Nvidia touting it as an "open standard" and how it would be "more than happy to license it to AMD", but [Nvidia] won't. It's just not true! You know the way it is, it's simply something [Nvidia] would not do and they can publically say that as often as it likes and know that it won't, because we've actually had quiet conversations with them and they've made it abundantly clear that we can go whistle.
The other thing is that all these CPU cores we have are underutilised and I'm going to take another pop at Nvidia here. When they bought Ageia, they had a fairly respectable multicore implementation of PhysX. If you look at it now it basically runs predominantly on one, or at most, two cores. That's pretty shabby! I wonder why Nvidia has done that? I wonder why Nvidia has failed to do all their QA on stuff they don't care about - making it run efficiently on CPU cores - because the company doesn't care about the consumer experience it just cares about selling you more graphics cards by coding it so the GPU appears faster than the CPU.
It's the same thing as Intel's old compiler tricks that it used to do; Nvidia simply takes out all the multicore optimisations in PhysX. In fact, if coded well, the CPU can tackle most of the physics situations presented to it. The emphasis we're seeing on GPU physics is an over-emphasis that comes from one company having GPU physics... promoting PhysX as if it's Gods answer to all physics problems, when actually it's more a solution in search of problems.Two things for Huddy:
nVidia does not selling CPUs. Why do you expect that they do your job in helping the ISV?
A lot of new games are using or will use CPU-PhysX. Somebody should tell the ISV that they are will get a very bad multi cpu support. And how will it helps nVidia selling more gpus when there is no GPU-PhysX support? :roll:
Two things for fuddy:
nVidia does not selling CPUs. Why do you expect that they do your job in helping the ISV?
A lot of new games are using or will use CPU-PhysX. Somebody should tell the ISV that they are will get a very bad multi cpu support. And how will it helps nVidia selling more gpus when there is no GPU-PhysX support? :roll:
Mr. Sontin. HOw does nvidia run PhysX on an iPhone, which also doesn't have a GPU ..
doh!
Deathlike2
06-Jan-2010, 19:00
Two things for fuddy:
nVidia does not selling CPUs. Why do you expect that they do your job in helping the ISV?
A lot of new games are using or will use CPU-PhysX. Somebody should tell the ISV that they are will get a very bad multi cpu support. And how will it helps nVidia selling more gpus when there is no GPU-PhysX support? :roll:
I think he was talking about underutilizing of PhysX when using multi core CPUs. HardOCP had run these tests, but it showed that the CPU was not being efficiently used at all, so what Huddy is saying is correct. If a supposedly CPU driven feature such as physics can be done by the GPU, but no effort is made to have any CPU assistance for PhysX is the problem.
Here's the link for that site: http://www.hardocp.com/article/2009/10/19/batman_arkham_asylum_physx_gameplay_review/11
With graphics and PhysX running on the same GTX 285 GPU, our CPU usage changed hardly at all. Core 0 was the most heavily loaded, at an average of about 51% and a peak utilization of 97%. Across all four cores, we saw an average utilization of 35%, and a peak of 71%. That is only 4% lower on average than with PhysX running entirely on the CPU.
Mr. Sontin. HOw does nvidia run PhysX on an iPhone, which also doesn't have a GPU ..
doh!
Will it helps them to sell more gpus because PhysX runs on the iPhone? :lol:
Why should anybody use PhysX over Havok or other, free physic engines when the CPU support is in such a bad shape?
I think he was talking about underutilizing of PhysX when using multi core CPUs. HardOCP had run these tests, but it showed that the CPU was not being efficiently used at all, so what Huddy is saying is correct. If a supposedly CPU driven feature such as physics can be done by the GPU, but no effort is made to have any CPU assistance for PhysX is the problem.
No, he is speaking about the whole cpu support of PhysX. And i don't see the problem that nVidia is not optimizing the GPU-PhysX code for cpus. It's not their problem that the cpu vendors don't care about physics in games.
Deathlike2
06-Jan-2010, 19:21
No, he is speaking about the whole cpu support of PhysX. And i don't see the problem that nVidia is not optimizing the GPU-PhysX code for cpus. It's not their problem that the cpu vendors don't care about physics in games.
Since when did CPU vendors control physics? They don't. Developers do, and they can do it with a CPU if they so desire. PhysX is a vehicle to make this "easier" for the CPU as a method of acceleration. It's not supposed to be "the only way" to make it accessible to all.
If you consider PhysX as a form of T&L which was whole "give less work for the CPU to do" deal in the DX7 era, then they've done very poor job of it. It's not a great analogy, but for the purposes of what PhysX is supposed to offer, making no effort to make the CPU more efficient in getting better performance is not acceptable if that's what PhysX was claiming in the first place... to help out accelerating physics.
I don't like the idea that PhysX does absolutely nothing for the CPU... you're supposed to help out the CPU to make your own product look better anyways. To say that it shouldn't help out the CPU is utter nonsense for hardware that is supposed to reduce CPU overhead for physics.
Since when did CPU vendors control physics? They don't. Developers do, and they can do it with a CPU if they so desire. PhysX is a vehicle to make this "easier" for the CPU as a method of acceleration. It's not supposed to be "the only way" to make it accessible to all.
So, what is the point of the PhysX bashing from Fuddy? There are developers who used or are using PhysX as their major cpu physics engine. It's not nVidia's fault that they don't use all free cores of a cpu.
If you consider PhysX as a form of T&L which was whole "give less work for the CPU to do" deal in the DX7 era, then it's done very poor job of it. It's not a great analogy, but for the purposes of what PhysX is supposed to offer, making no effort to make the CPU more efficient in getting better performance is not acceptable if that's what PhysX was claiming in the first place... to help out accelerating physics.
I see the point, but GPU-PhysX is only one way of the whole "GPU-Physics" thing. Until no independent developer will use CPU- and GPU-PhysX in a programm, i see no problem that nVidia will not optimize their code.
Deathlike2
06-Jan-2010, 19:39
So, what is the point of the PhysX bashing from Fuddy? There are developers who used or are using PhysX as their major cpu physics engine. It's not nVidia's fault that they don't use all free cores of a cpu.
He's saying that prior to acquiring PhysX, the company was doing just dandy with multi-core acceleration. Since tests prove that no more than dual-core is being accelerated, he's saying that the tech is being "held back" intentionally to want you to buy the video card than a CPU. I should think that upgrading from singlel core to a Core i7 would actually help physics out, but that's not really the case under this scenario.
He's saying that prior to acquiring PhysX, they were doing just dandy with multi-core acceleration. Since tests prove that no more than dual-core is being accelerated, he's saying that the tech is being "held back" intentionally to want you to buy the video card than a CPU.
I don't see tests. He is claiming something.
This came from Futuremark:
Jussi Markkanen: Our game engine is designed specifically for multi-core processors. We can parallelize all CPU-heavy tasks. For example rendering, physics simulation, audio, network handling and game logic are all executed in separate threads. Some other minor tasks are parallelized as well. Currently we have limited multicore scaling up to 16 cores. Here is an image of one of our test runs with heavy CPU load in a 16 core-machine. It demonstrates how the load is nicely distributed across the processors.http://www.pcgameshardware.com/aid,698996/Why-Shattered-Horizon-is-PC-exclusive-and-more-technical-details/Practice/
Deathlike2
06-Jan-2010, 19:52
I don't see tests. He is claiming something.
I showed you a link with some analysis. Your link doesn't have any.
You have to at least see the impact with some benchmarks than just a Q&A.
I'm not saying that the Batman game was any good as a comparison (we don't know how optimized it really is), but if you're gonna market a marquee game with PhysX, you need to be able to see the performance differences that one can properly quantify.
I showed you a link with some analysis. Your link doesn't have any.
You have to at least see the impact with some benchmarks than just a Q&A.
I'm not saying that the Batman game was any good as a comparison, but if you're gonna market a marquee game with PhysX, you need to be able to see the performance differences that one can properly quantify.
I know a lot of other Games with physics which only use 2-3 cores. It's wrong to assume that there is a bad multi cpu support because games only use 2-3 cores.
Look at other games which don't use physx:
Dirt2: http://www.hardocp.com/article/2009/12/23/dirt_2_gameplay_performance_image_quality/9
Resident Evil 5: http://www.hardocp.com/article/2009/11/03/resident_evil_5_gameplay_performance_iq/9
Wolfenstein 2: http://www.hardocp.com/article/2009/09/01/wolfenstein_gameplay_performance_iq/8
All three games use 2 cores of the cpu. What do you think? All three game developers want to harm the gamer?
Deathlike2
06-Jan-2010, 20:13
We're exclusively talking about PhysX here with multi-core processors... since that is the scope of Huddy's comments. Those benchmarks don't show PhysX on and off.
We're exclusively talking about PhysX here... since that is the scope of Huddy's comments. Those benchmarks don't discuss PhysX.
But your link? You showed me a game with CPU-PhysX but without an abnormal behaviour.
I think without a proof that PhysX has no > dual core support it's nothing more than fud from Fuddy.
Silent_Buddha
06-Jan-2010, 20:21
Two things for fuddy:
nVidia does not selling CPUs. Why do you expect that they do your job in helping the ISV?
A lot of new games are using or will use CPU-PhysX. Somebody should tell the ISV that they are will get a very bad multi cpu support. And how will it helps nVidia selling more gpus when there is no GPU-PhysX support? :roll:
Except that there ARE multi-thread optimisations as well as CPU optimisations in PhysX on both PS3 and X360. But they actively remove those for the PC... Also there are CPU optimisations for handheld CPU's which are also removed for the PC.
THAT is what he is referring to.
I can also see why Nvidia is reluctant to port PhysX to OpenCL, as OpenCL will by default compile so that it will run across multiple threads taking advantage of all CPU cores. Something Nvidia desperately does NOT want PhysX to do as it would negate some of those "huge" artificial advantages that it currently has when comparing GPU PhysX to CPU PhysX. Despite the fact that there would still be an advantage.
Regards,
SB
I think without a proof that PhysX has no > dual core support it's nothing more than fud from Fuddy.
The Computerbase benchmark has all ati cards stuck at 21fps with cpu physx and very low (14%) cpu utilization, get your head out of your ***.
50% bigger than dual RV870 is like 1000mm2 die so everything points out to a typo :smile:
He meant this: Fermi=100% * Cypress + 50% * Cypress=150% * Cypress=150% * 334mm2=501mm2. I don't exactly see how that can be interpreted as Fermi being almost 3 times Cypress(1000/334), but English is not my native language, so some subtleties of it may be escaping me.
The Computerbase benchmark has all ati cards stuck at 21fps with cpu physx and very low (14%) cpu utilization, get your head out of your ***.
I think you overlooked my comment, that i did not spoke about GPU-PhysX. :lol:
Except that there ARE multi-thread optimisations as well as CPU optimisations in PhysX on both PS3 and X360. But they actively remove those for the PC... Also there are CPU optimisations for handheld CPU's which are also removed for the PC.
THAT is what he is referring to.
Yeah and where is the proof?
/edit: Without CPU-PhysX in the software there will be no GPU-PhysX. So it makes perfect sense to cripple your CPU-PhysX for pushing your gpus...
Deathlike2
06-Jan-2010, 20:43
But your link? You showed me a game with CPU-PhysX but without an abnormal behaviour.
I think without a proof that PhysX has no > dual core support it's nothing more than fud from Fuddy.
My link shows exactly what was said. There was a multi-core processor used and tested WITH and WITHOUT PhysX on. CPU usage didn't go up very much, suggesting that the CPU is not being used. It is supposed to go quite a bit up (translating into better performance) or quite a bit down (translating into saving CPU resources).
/edit: Without CPU-PhysX in the software there will be no GPU-PhysX. So it makes perfect sense to cripple your CPU-PhysX for pushing your gpus...
That is contradicted by this:
The Computerbase benchmark has all ati cards stuck at 21fps with cpu physx and very low (14%) cpu utilization, get your head out of your ***.
I would still like a link for that.
If you're going to use CPU-PhysX, at least you would need to see the other cores being used for a proper comparison, or it doesn't become a useful comparison. Might as well disable all the cores!
Silent_Buddha
06-Jan-2010, 20:43
When they bought Ageia, they had a fairly respectable multicore implementation of PhysX.
I dunno, that's pretty black and white there with regards to the PC. The fact that it no longer takes advatage of multiple cores... Well, you're obviously going to form your own opinions no matter what is said or presented, so we'll leave it at that.
And if Huddy is right that Bullet and possibly one other physics middleware developer will have a GPU accelerated version of their product out this year, then it'll all be moot soon.
Regards,
SB
Deathlike2
06-Jan-2010, 21:14
Here's another link about benching PhysX on the same Batman game:
http://www.tomshardware.com/reviews/batman-arkham-asylum,2465-10.html
They use ATI cards with PhysX, so that means CPU-PhysX... you shouldn't expect great performance anyways, but read this specifically...
Rather than clearing things up, the results of this testing have only left us more puzzled. We can recall that the PhysX API is supposed to be optimized for multiple threads, yet on the Core i7, only a single thread seems to be stressed when PhysX is cranked up..
In theory, performance shouldn't suck this badly, except there's no effort to improve performance! This is essentially the same analysis when NVidia's hardware is used in my HardOCP link. What's the point of PhysX acceleration if it doesn't get some extra performance from the CPU? Go back to single core? I don't think so.
No, he is speaking about the whole cpu support of PhysX. And i don't see the problem that nVidia is not optimizing the GPU-PhysX code for cpus. It's not their problem that the cpu vendors don't care about physics in games.
Dude ... where have you been? There have been multiple threads about this and other than you no one has even doubted the validity of the claims since the original articles by Techreport on core utilization with CPU PhysX. No one, quite regardless of manufacturer bias.
The evidence is clear enough ... this isn't FUD from Richard Huddy, this is just you being extremely dense.
PS. which is not to say it's "wrong" of them to do so, or even "wrong" of developers to accept it in return for free programmers and such ... it's of course perfectly legal and it makes economic sense up to a point (although we will probably get to the point where giving a large part of your customers an underperforming game engine probably will stop making economic sense for developers ... if enough big games don't tow the line). It's just ultimately not advantageous to gamers to create warring camps with proprietary standards (or even more dangerous, games with code intentionally de-optimized for the competition). Without Carmack making sure there was a level playing field by pushing for miniGL there probably would not have been a NVIDIA ... any developer pushing PhysX is not doing gamers a favour (looking at you mr. Sweeney :)).
CNCAddict
06-Jan-2010, 22:40
http://bulletphysics.org/Bullet/phpBB3/viewtopic.php?f=18&t=4495 :)
Lightman
06-Jan-2010, 23:30
He meant this: Fermi=100% * Cypress + 50% * Cypress=150% * Cypress=150% * 334mm2=501mm2. I don't exactly see how that can be interpreted as Fermi being almost 3 times Cypress(1000/334), but English is not my native language, so some subtleties of it may be escaping me.
The question was regarding HD5970 which is dual Cypress = 2x334mm2
That's where all the confusion is coming from :smile:
We all suspect that Huddys answer was regarding HD5870 so as you are pointing single Cypress + 50%.
Squilliam
07-Jan-2010, 02:00
What I don't understand is after the following Quote
Why so many new games come out with glaring problems on ATI cards that don't get fixed until months later, by then most gamers are finished with the game that is having problems.
What I don't know is what an acceptable answer from him to this type of question would be. People who have seen this stuff for a while take everything he would say with an epic boulder of salt. Its one thing for them to be honest and forthright and another for the words to be taken as gospel.
PR now means that no-one believes a word you say either way, so its almost gotten to the point where they may as well not say anything at all!
Deathlike2
07-Jan-2010, 18:06
Finally found the tech report reference:
http://techreport.com/articles.x/17618/13
Another PhysX game not even bothering to use the other cores.
This doesn't even help PhysX when it isn't even reasonably optimized....
http://forum.beyond3d.com/showthread.php?t=48717&highlight=cpu+utilization+physx
The question was regarding HD5970 which is dual Cypress = 2x334mm2
That's where all the confusion is coming from :smile:
We all suspect that Huddys answer was regarding HD5870 so as you are pointing single Cypress + 50%.
The 5970 bit is obviously a typo. In that the question (and the answer) itself was about the 5870 and it got scrambled as it was uploaded.
So can someone who plays/keeps track of STALKER comment on his statement about it being shit while it was a TWIMTBP game then ATI fixed it with later patches, eg including a DX10 AA implementation that works fine on NV hardware?
I liked the answer to 'why buy a 5870' question :grin:
Can't imagine an NV spokesperson ever saying 'stick with what you have if it works for you, or go for our 3rd ranked card' :lol:
(actually very carefully worded & perfectly targeted at the cost conscious upgrader who skips a generation or two, which I guess is why it rings my bell)
gamervivek
08-Jan-2010, 17:17
I liked the answer to 'why buy a 5870' question :grin:
Can't imagine an NV spokesperson ever saying 'stick with what you have if it works for you, or go for our 3rd ranked card' :lol:
Well, they themselves have been stuck with what they have for quite some time now.
They could certainly say 'stick with what you have if it works for you, or just rebrand it like we do.' :razz:
Lightman
08-Jan-2010, 20:31
Well, they themselves have been stuck with what they have for quite some time now.
They could certainly say 'stick with what you have if it works for you, or just rebrand it like we do.' :razz:
:lol:
Good one!
Just a thought, If you didnt know much about pc hardware you could actually upgrade your nv card 3 times and have the same card you started off with.
Just a thought, If you didnt know much about pc hardware you could actually upgrade your nv card 3 times and have the same card you started off with.
Planned Obsolescence 101 :lol:
Squilliam
09-Jan-2010, 07:33
Just a thought, If you didnt know much about pc hardware you could actually upgrade your nv card 3 times and have the same card you started off with.
I think I've done that before! :oops:
Well I guess its a good way to test out the placebo effect! :-D
Lonbjerg
10-Jan-2010, 09:29
When they bought Ageia, they had a fairly respectable multicore implementation of PhysX.
Really?
I got a PPU in 2006 and most games/demos I compared the CPU vs PPU physics, the CPU physcis ran on a single core?
I have never seen any novodex/AGEIA demo/game with full multicore utilization?!
Just an observation, Sontin, but it's really very disrespectful to call Richard "Fuddy". He's put in front of press to evangelise for ATI, sure, but he's a deeply smart guy who's forgotten more about graphics than anyone calling him Fuddy would ever hope to learn. So when he talks about it and the industry one should listen and pay attention, rather than instantly think it's self serving for him and ATI. Given he used to work for NV, his perspective is somewhat unique and really quite valuable.
So maybe try reading the interview again without the inbuilt misconception he's acting like a PR person, since you might get something useful from it and contribute something useful in this thread going forward.
trinibwoy
10-Jan-2010, 13:15
Just a thought, If you didnt know much about pc hardware you could actually upgrade your nv card 3 times and have the same card you started off with.
If you spent less money each time yeah but technically that doesn't count as an "upgrade" :)
gamervivek
10-Jan-2010, 15:03
Not really that unique :smile2:
http://www.rage3d.com/previews/video/ati_hd5870_performance_preview/index.php?p=4
ChrisRay
15-Jan-2010, 10:32
Except that there ARE multi-thread optimisations as well as CPU optimisations in PhysX on both PS3 and X360. But they actively remove those for the PC..
What do you mean by this? The PhysX SDK for the PC supports multi threading and core scaling. ((Despite what some people would like you to believe)) Who actively removes what? There are "tons" of CPU PhysX titles out there. It just seems the GPU PhysX titles get the most scrutiny because they don't accellerate CPU performance to "Some peoples" liking. Yet for every GPU PhysX title out there. Theres about 12-13 CPU PhysX titles out there.
Another interesting perspective is there are a ton of CPU PhysX/Havok implementations out there. But do we give the developers alot of grief who only want to implement simple Physic effects into their titles and don't massively code threaded CPU enviroments or for the GPU? The devs are ultimately responsible for how our games get coded and how the performance/features look from there. Some devs will opt for CPU multi threaded Physics. Some will opt for GPU Physics. Some will opt for simple single threaded Physics. They don't neccassarily have to be inclusive of each other. It'll be very rare for a dev to invest heavily into one or the other. When they have one implementation which performs to their liking.
What do you mean by this? The PhysX SDK for the PC supports multi threading and core scaling. Who actively removes what? There are "tons" of CPU PhysX titles out there. It just seems the GPU PhysX titles get the most scrutiny because they don't accellerate CPU performance to "Some peoples" liking.
He means that, in a actively promoted GPU PhysX title, none your mentioned scaling can be witnessed. The Point being that your "tons" of CPU titles simply don't exhibit this behaviour. they do not accelerate physx at all as can be witnessed by, what almost seems to be a framecap in benchmarks: 21fps on ati hardware or nv hardware with edited hardwareID.
Even CPU loads witnessed in these situations (14% on one core out of 8) do simply not correlate that anything is actually going on, physx or gaming wise. PhysX is ultimately owned by nvidia and there's simply no evidence that they, so far have put any effort (themselves or helping developers) in getting PhysX up in games that also support GPU physx.
In your last sentence, you seem to indicate developers only develop for one target (i.e. GPU physx) isn't it nvidia's duty to make sure that the GPU workload is properly processed on the CPU when a GPU is not present? Or do developer relations only go so far that they don't want to help developers getting a game to run properly, but only properly when a number of variables are to nv's liking? (hint, intel's recent compiler snafu)
Since PhysX is proprietary and owned by nvidia, you can't expect others to perform code optimizations on PhysX.
ChrisRay
15-Jan-2010, 11:01
He means that, in a actively promoted GPU PhysX title, none your mentioned scaling can be witnessed. The Point being that your "tons" of CPU titles simply don't exhibit this behaviour. they do not accelerate physx at all as can be witnessed by, what almost seems to be a framecap in benchmarks: 21fps on ati hardware or nv hardware with edited hardwareID.
And? Like I said above. If a developer chooses to code for one or the other and optimally tune for either. You're not likely going to see them spending alot of time with the other. If a game is coded for the GPU it doesn't even necessitate a CPU fallback. Some PhysX titles don't even have them. Its obvious the CPU PhysX enviroments in GPU PhysX titles are included as an after thought. Not something that was optimally coded for. I personally would rather them not even be there.
your last sentence, you seem to indicate developers only develop for one target (i.e. GPU physx) isn't it nvidia's duty to make sure that the GPU workload is properly processed on the CPU when a GPU is not present?
This is something I talked to Tony Tamasi about in Vegas. And the answer is no. Unless the developer requests that kind of assistance from Nvidia's PhysX devrel. Nvidia will infact help devs code for a threaded CPU implementation if they request it. Nvidia's PhysX devrel provides assistance for both GPU and CPU PhysX on the PC if the dev has purchased that kind of support. Obviously those using the free SDK build will probably not get the same level of support. However most devs will not bother coding the CPU if they have already coded a PhysX for the GPU or Vice versa. If it was as simple as "Switching back and forth" using a compiler. Then all games would have the option for CPU or GPU PhysX.
They don't. The reason for why should be obvious. Because it's not that easy. Take Batman Arkham Assylum for example. Nvidia said they invested about 4 man months into the title getting it GPU physX ready and optimal for GPU PhysX. Which they agree is too long. There are obviously improvements that need to be made on the devrel side. But it's still not a simple on off switch. Especially after you have thoroughly coded for one or the other.
So, you're saying there is no cpu fallback implementation of the gpu-physx api (an implementation that should be trivially multithreaded), so if developers for gpu-physx-api titles want cpu support (at all) they'll have to code it up against yet another api?
Colourless
15-Jan-2010, 12:25
I'm guessing that the CPU fallback for GPU physx is single threaded and if a developer wants to they could manually multithread it themselves. If that is the case though, it'd be really annoying.
Nvidia's PhysX devrel provides assistance for both GPU and CPU PhysX on the PC if the dev has purchased that kind of support.
Is the number of live in developers they get purely a question of the level of support purchased or does NVIDIA vary the level of support based on the importance of the title? (The importance to NVIDIA.)
trinibwoy
15-Jan-2010, 14:52
They're probably doing what any sane company does, i.e allocating resources to get the best return.
So if the amount of resources (free developers) is not purely a contractual issue we can then conclude it would have cost Rocksteady money to optimize for multithreading (because that would have reduced NVIDIA's return).
Mintmaster
15-Jan-2010, 17:52
What do you mean by this? The PhysX SDK for the PC supports multi threading and core scaling. ((Despite what some people would like you to believe)) Who actively removes what? There are "tons" of CPU PhysX titles out there. It just seems the GPU PhysX titles get the most scrutiny because they don't accellerate CPU performance to "Some peoples" liking. Yet for every GPU PhysX title out there. Theres about 12-13 CPU PhysX titles out there.There is no excuse for underutilized cores in a physics API meant to run on a stream processor. Whatever parallel loads you feed to CUDA can be fed to a very simple job queue application running code from a CUDA to CPU compiler. The latter is probably already there.
Nobody is saying NVidia is breaking the law by doing this. They're just saying NVidia is being a corporate douche for intentionally crippling CPU performance.
I would love to see some Havok vs. PhysX CPU benchmarks for similar physics simulations. It wouldn't surprise me if there was an order of magnitude difference.
ChrisRay
15-Jan-2010, 19:24
Is the number of live in developers they get purely a question of the level of support purchased or does NVIDIA vary the level of support based on the importance of the title? (The importance to NVIDIA.)
Its more a question of resources than anything else. Nvidia tries to support all developers if they can. But they don't have unlimited manpower. Its not uncommon for an Nvidia devrel guy to go down to the offices of a company they are helping and basically live there till the work they are doing is done. In the case of Rocksteady. They actually wanted to add more GPU PhysX than what exists in our current games. But they didn't have the time/manpoower to get them implemented.
Squilliam
15-Jan-2010, 20:01
What do you mean by this? The PhysX SDK for the PC supports multi threading and core scaling. ((Despite what some people would like you to believe)) Who actively removes what? There are "tons" of CPU PhysX titles out there. It just seems the GPU PhysX titles get the most scrutiny because they don't accellerate CPU performance to "Some peoples" liking. Yet for every GPU PhysX title out there. Theres about 12-13 CPU PhysX titles out there.
Another interesting perspective is there are a ton of CPU PhysX/Havok implementations out there. But do we give the developers alot of grief who only want to implement simple Physic effects into their titles and don't massively code threaded CPU enviroments or for the GPU? The devs are ultimately responsible for how our games get coded and how the performance/features look from there. Some devs will opt for CPU multi threaded Physics. Some will opt for GPU Physics. Some will opt for simple single threaded Physics. They don't neccassarily have to be inclusive of each other. It'll be very rare for a dev to invest heavily into one or the other. When they have one implementation which performs to their liking.
I would like to know if theres an example game released or a game coming soon which implements both GPU PhysX and multithreaded CPU PhysX at the same time. If you have an example handy then it would go a long way to putting this issue to rest.
ChrisRay
15-Jan-2010, 20:23
None that I'm aware of. Like I said. If dev optimizes for one. Its unlikely they'll spend the resources optimizing for the other. It could happen. But has not happened yet. It all comes down to how satisfied devs are with the implementation of PhysX they have used.
It comes down to a business decision ... a cheap license with free developers (if your game is big enough) or an expensive license and basic support.
Without proof I'm hesitant to just take your assurances that a developer could so easily multithread the code ... as we saw with the MSAA stuff, source code licenses are not always that flexible to begin with.
Demirug
15-Jan-2010, 21:23
As we had evaluated PhysX for BattleForge I have some experiences with the SDK. From the SDK point of view using another CPU core for the physic simulation is pretty easy. But it could only work as it should if you can update and start the simulation some time before you need the result. If you need it immediately the fetch will block. Unfortunately there is still much multicore unfriendly engine code out there that could not handle this latency. If you want to run on the GPU you have to face these latency problems, too. This could make it complicate to integrate.
On the other hand locking PhysX to the GPU is quite simple. There are some functions that work only if you use a GPU context. They are simply not implemented in the CPU version. If someone makes use of these functions the simulation would not run on the CPU before you remove them.
ChrisRay
15-Jan-2010, 21:29
Without proof I'm hesitant to just take your assurances that a developer could so easily multithread the code
I thought I was pretty clear it wasn't "easy".
I meant easy as in getting an affordable source code license out of NVIDIA, not development effort.
Silent_Buddha
16-Jan-2010, 00:45
Well, presumably when Nvidia is finally forced to port PhysX to OpenCL it'll automatically support multiple CPU threads, unless they code it specificly to disallow this.
So, it's only a matter of time until they are forced to better support multiple CPU cores, either that or they drop PhysX once that situation presents itself.
I'll be surprised if they don't eventually port PhysX to OpenCL as the same code would be able to run on both CPU and GPU. Oh wait that might be a problem, as then the gap between GPU and CPU wouldn't be as great. So maybe they will forever stick with CUDA.
Regards,
SB
In the case of Rocksteady. They actually wanted to add more GPU PhysX than what exists in our current games. But they didn't have the time/manpoower to get them implemented.
You mean compared with other PhysX (TWIMTBP) titles?
Oh wait that might be a problem, as then the gap between GPU and CPU wouldn't be as great.
You cynic, you.
Silent_Buddha
16-Jan-2010, 06:07
You cynic, you.
Yes. :)
I've been a cynic of PhysX ever since Ageia announced it waaaaaay back when.
Regards,
SB
Lonbjerg
16-Jan-2010, 10:27
There is no excuse for underutilized cores in a physics API meant to run on a stream processor. Whatever parallel loads you feed to CUDA can be fed to a very simple job queue application running code from a CUDA to CPU compiler. The latter is probably already there.
Nobody is saying NVidia is breaking the law by doing this. They're just saying NVidia is being a corporate douche for intentionally crippling CPU performance.
I would love to see some Havok vs. PhysX CPU benchmarks for similar physics simulations. It wouldn't surprise me if there was an order of magnitude difference.
I can repeat:
I have never seen an AGIEA (or even novodex) demo/game with full CPU-multicore support?
I would still like to see Huddy back up his claims, as they are in contrast to my own experince?
Specifically which claims and what is your experience? (The probably mistaken assumption that the old library was multithreaded for x86 before NVIDIA got it was not from the interview nor from mr. Huddy ... although I'm pretty sure the console versions are and it shouldn't take that much work to port that work to x86.)
I would love to see some Havok vs. PhysX CPU benchmarks for similar physics simulations. It wouldn't surprise me if there was an order of magnitude difference.
I would love to see some Havok vs Physx GPU benchmarks for similar physics simulations. The magnitude of difference should be off the charts.
If the GPU isn't needed in the first place then so what?
Lonbjerg
16-Jan-2010, 15:27
Specifically which claims and what is your experience? (The probably mistaken assumption that the old library was multithreaded for x86 before NVIDIA got it was not from the interview nor from mr. Huddy ... although I'm pretty sure the console versions are and it shouldn't take that much work to port that work to x86.)
That PhysX was multithreaded on the CPU before NVIDIA aquired AGEIA?
All the demo's (From Carwash to PhysX Rocket to RealityMark) I have run myslef always had Core1 maxed out and virtually nothing going on Core2.
As this link shows:
http://forums.guru3d.com/showthread.php?p=1974275
I cannot remember any games with multicore usage (on the PC) of PhysX and that is why I call this quote bad PR spin:
bit-tech: -so we'll see AMD GPU physics in 2010?
RH: Bullet should be available certainly in 2010, yes. At the very least for ISVs to work with to get stuff ready.
The other thing is that all these CPU cores we have are underutilised and I'm going to take another pop at Nvidia here. When they bought Ageia, they had a fairly respectable multicore implementation of PhysX. If you look at it now it basically runs predominantly on one, or at most, two cores
I don't have a PPU(and AGIEIA's old drivers) in any systems anymore so I cannot disprove his claims meself...but I a damned sure about my memories...and they cannot remeber the "situation" he describes.
AFAIR even the AGIEA control panel demos ran the physics on a single thread.
If the GPU isn't needed in the first place then so what?
Nvidia prefers you spend money on a GPU rather than on a quad core CPU. Intel and AMD have another perspective on this. All of which makes business sense.
Somehow, one side gets called a corporate douche. The other side is commended for sticking to open standards, which in this case mainly translates to a failure to innovate and/or secure market share.
Like you say - so what? None of this matters.
Meh, googled a bit ... the old Novodex was multithreaded, they made a big song and dance routine about it, but if you looked a bit closer it wasn't really done in a very useful way (not in a way which would show up in demos, or in a way which would be terribly practical in games).
Nvidia prefers you spend money on a GPU rather than on a quad core CPU. Intel and AMD have another perspective on this. All of which makes business sense.
Somehow, one side gets called a corporate douche. The other side is commended for sticking to open standards, which in this case mainly translates to a failure to innovate and/or secure market share.
Like you say - so what? None of this matters.
It matters to me as a gamer. Taking my money and bribing developers to run algorithms inefficiently runs directly counter to my interests. When companies compete with open standards it gives me better hardware when they compete on who can find more obnoxious way of locking in customers it gets me what exactly?
Lonbjerg
16-Jan-2010, 16:06
Meh, googled a bit ... the old Novodex was multithreaded, they made a big song and dance routine about it, but if you looked a bit closer it wasn't really done in a very useful way (not in a way which would show up in demos, or in a way which would be terribly practical in games).
Yup and people forget that physics scale very badly with the number of CPU cores too...hence why I don't know why he would say what he did...unless it's a bad PR spin. :?:
It matters to me as a gamer. Taking my money and bribing developers to run algorithms inefficiently runs directly counter to my interests. When companies compete with open standards it gives me better hardware when they compete on who can find more obnoxious way of locking in customers it gets me what exactly?
AFAIK only NVIDIA (which basicly means AGIEA) has delivered.
Back when I got my PPU in 2006, both ATi and NVIDIA hurried up to claim they would do GPU physics real soon.
The rest is history..NVIDIA acquired AGIEA...and AMD (read : ATi) is still all talk and nothing to show....going on ~4 years.
Sorry, but I would rather have something proprietary...than nothing "open to all"...
It matters to me as a gamer. Taking my money and bribing developers to run algorithms inefficiently runs directly counter to my interests.
I disagree with your characterisation of what's happening.
When companies compete with open standards it gives me better hardware when they compete on who can find more obnoxious way of locking in customers it gets me what exactly?
Havok is not exactly an open standard either, just the one the CPU makers happen to be aligning behind because right now it fits their purposes.
As we see so often, the outrage is quite selective. You know what? Just vote with your wallet.
Lonbjerg
16-Jan-2010, 16:28
PhysX = proprietary NVIDIA
Havok = proprietary Intel (and why AMD in the end dropped it...after much(again) PR and nothing to show)
Then we have BulletPhysics that from what I gather only has been used in "indiegames"..and now is the hope of AMD...(until they pick something else).
Havok is proprietary, but it runs on x86 which is not quite as proprietary. Bullet is not only used in indiegames, but it's predominantly used by Sony (since they employ the main developer).
Apart from those though, not all game engine developers are as ready to sacrifice their physics performance for expedience as Tim Sweeney. Cryengine and Internal engine for instance have pretty well developed internal physics engine. The Infernal engine physics demo video (http://www.viddler.com/explore/HardOCP/videos/36/) is purty and has a nice quote :
I’m pretty sure we’ve never seen GPU-enabled physics to be able to do anything on a scale like this ... this frees up the graphics card to do the real work that it needs to do, and allows the CPU to really shine.
Lonbjerg
16-Jan-2010, 17:41
Havok is proprietary, but it runs on x86 which is not quite as proprietary. Bullet is not only used in indiegames, but it's predominantly used by Sony (since they employ the main developer).
Apart from those though, not all game engine developers are as ready to sacrifice their physics performance for expedience as Tim Sweeney. Cryengine and Internal engine for instance have pretty well developed internal physics engine. The Infernal engine physics demo video (http://www.viddler.com/explore/HardOCP/videos/36/) is purty and has a nice quote :[/QUOTE]
That quote is "disproven" by their simple rigid bodies collisions that dissapear after ~10 seconds.
It was done better in 2006 (via hardware physics) so it only means that CPU physics still are way behind and not really something to aim for.
Lonbjerg
16-Jan-2010, 17:43
Quote-bug...but I hope you can see throgh it :)
Groo The Wanderer
16-Jan-2010, 18:31
PhysX = proprietary NVIDIA
Havok = proprietary Intel (and why AMD in the end dropped it...after much(again) PR and nothing to show)
Then we have BulletPhysics that from what I gather only has been used in "indiegames"..and now is the hope of AMD...(until they pick something else).
When did AMD drop Havok? Last I heard, that was still going quite strong.
-Charlie
Groo The Wanderer
16-Jan-2010, 18:33
As we had evaluated PhysX for BattleForge I have some experiences with the SDK. From the SDK point of view using another CPU core for the physic simulation is pretty easy. But it could only work as it should if you can update and start the simulation some time before you need the result. If you need it immediately the fetch will block. Unfortunately there is still much multicore unfriendly engine code out there that could not handle this latency. If you want to run on the GPU you have to face these latency problems, too. This could make it complicate to integrate.
On the other hand locking PhysX to the GPU is quite simple. There are some functions that work only if you use a GPU context. They are simply not implemented in the CPU version. If someone makes use of these functions the simulation would not run on the CPU before you remove them.
Got a good explanation for why Physx doesn't even max a single CPU?
-Charlie
ChrisRay
16-Jan-2010, 19:39
You mean compared with other PhysX (TWIMTBP) titles?
No. they just wanted to make batman fancier. With more PhysX effects than what exists in the shipping game. Time just ran out.
Chris
Lonbjerg
16-Jan-2010, 20:04
When did AMD drop Havok? Last I heard, that was still going quite strong.
-Charlie
Since Intel aquired Havok (and just let AMD hang in the wind...they are not friends you know)...and since AMD annnoced this last year:
http://www.amd.com/us/press-releases/Pages/amd-announces-new-levels-of-realism-2009sept30.aspx
But we are still in 2006...all words...and nothing to show.
Which is why Huddy really shouldn't have bended the facts like that.
Demirug
16-Jan-2010, 20:07
Got a good explanation for why Physx doesn't even max a single CPU?
-Charlie
For the same reasons why games without PhysX doesn’t max out a single CPU.
1. The game/engine is not limited by the CPU and therefore spend time (that’s not shown as processor time) waiting for the blocking component. Most likely the GPU.
2. Bad multi core code that blocks execution in an unfortunately way. Threads that are blocked are not shown as processor time either.
Silent_Buddha
17-Jan-2010, 10:51
PhysX = proprietary NVIDIA
Havok = proprietary Intel (and why AMD in the end dropped it...after much(again) PR and nothing to show)
Then we have BulletPhysics that from what I gather only has been used in "indiegames"..and now is the hope of AMD...(until they pick something else).
Except that as far as we know, ATI is still assisting Havok with porting to OpenCL. So they haven't exactly dropped it.
[Edit] Replying to your later post, it's business. Businesses aren't so petty usually as to snub their competition if their competition has something they can work on together. MS and Sony still work on projects together even though they are direct competitors. MS still works with Apple. And AMD is still working with Intel (especially with regards to Havok).
And to the one above this one. Yup, voting with Wallet. Not a single person I know in RL has purchased Batman AA due to vendor lock in. And many have stated to me they will be skipping at least 1 (or more) generation of Nvidia hardware even if it completely blows ATI away in hopes Nvidia gets the message that they would prefer open standards/stuff to work cross vendor.
It's a bit of a sea change around here, as many of these same people have never owned anything other than Nvidia cards.
Regards,
SB
Lonbjerg
17-Jan-2010, 12:31
Except that as far as we know, ATI is still assisting Havok with porting to OpenCL. So they haven't exactly dropped it.
They still talk yes...but after Intel canned "Larrabee" they have no interest (ATM) in GPU-physics.
The problem is that they have talked since 2006...and that is it.
[Edit] Replying to your later post, it's business. Businesses aren't so petty usually as to snub their competition if their competition has something they can work on together. MS and Sony still work on projects together even though they are direct competitors. MS still works with Apple. And AMD is still working with Intel (especially with regards to Havok).
I know that the IT-world is not black&white.
But Intel is still a competitor to AMD and with "larrabee" on the backbruner...and AMD's "fusion" in the horizon, you can see with ease why Intel would let AMD hang.
And to the one above this one. Yup, voting with Wallet. Not a single person I know in RL has purchased Batman AA due to vendor lock in. And many have stated to me they will be skipping at least 1 (or more) generation of Nvidia hardware even if it completely blows ATI away in hopes Nvidia gets the message that they would prefer open standards/stuff to work cross vendor.
It's a bit of a sea change around here, as many of these same people have never owned anything other than Nvidia cards.
Regards,
SB
I fail to see the relevance on this topic (which is AMD PR (even making false claims))?
Silent_Buddha
17-Jan-2010, 14:18
I fail to see the relevance on this topic (which is AMD PR (even making false claims))?
I should have put that into a new post, it was a reply to a post above yours that I replied to, where the person urged people to vote with their wallets rather than complain if a company is doing things some people view as harmful to the industry.
As to Havok. It is a wholely owned subsidiary of Intel as far as I'm aware, which means it makes it's own profits regardless of what Intel does. Whether Larrabee is ever released or not, Havok as a company still makes a profit and for Intel to abandon it would be to throw away their investment as well as a continuing revenue stream.
If Intel truly felt Havok was no longer of use for them, then they'd be better off to spin it off or look for a new buyer/allow Havok to buy themselves out.
Regards,
SB
Lonbjerg
17-Jan-2010, 15:06
I should have put that into a new post, it was a reply to a post above yours that I replied to, where the person urged people to vote with their wallets rather than complain if a company is doing things some people view as harmful to the industry.
As to Havok. It is a wholely owned subsidiary of Intel as far as I'm aware, which means it makes it's own profits regardless of what Intel does. Whether Larrabee is ever released or not, Havok as a company still makes a profit and for Intel to abandon it would be to throw away their investment as well as a continuing revenue stream.
If Intel truly felt Havok was no longer of use for them, then they'd be better off to spin it off or look for a new buyer/allow Havok to buy themselves out.
Regards,
SB
They put "larrabee" on the backburner...they havn't scrapped their plans about eventually going into the GPU market all together. (AMD's "fusion" is the reason of that.)
Their venture into the GPU market is why they aquired Havok in the first place and I'll bet they hold on tight...the Intel way.
Groo The Wanderer
17-Jan-2010, 19:47
Since Intel aquired Havok (and just let AMD hang in the wind...they are not friends you know)...and since AMD annnoced this last year:
http://www.amd.com/us/press-releases/Pages/amd-announces-new-levels-of-realism-2009sept30.aspx
But we are still in 2006...all words...and nothing to show.
Which is why Huddy really shouldn't have bended the facts like that.
So the demo of Havok running on ATI hardware at GDC last spring (March 2009?) was not real? Damn, I wonder how they worked together to port that then? In fact, I wonder why the Intel people in the audience were so friendly and happy?
Intel and ATI are working very closely on Havok last time I looked, and it makes a lot of sense. The last round of Physics announcements I read had both Havok and Bullet in them, but there could have been others. I have not heard about a falling out from either side, it is in their best interests to work together.
-Charlie
Edit: Found the link I was looking for.
http://www.theinquirer.net/inquirer/news/1051673/ati-physics-argument
And the official line:
http://www.amd.com/us/press-releases/Pages/amd_demonstrates_optimized-2009mar26.aspx
You either are so out of the loop it isn't funny, don't bother to look for contradictory info, or have an axe to grind.
Even Nvidia and Amd work together sometimes
"In a normal class certification hearing, the plaintiffs revealed an email between Nvidia senior VP of marketing, Dan Vivoli, and ATI’s president and COO, Dave Orton, which points to inflated prices and collusion. It reads: “I really think we should work harder together on the marketing front. As you and I have talked about, even though we are competitors, we have the common goal of making our category a well positioned, respected playing field. $5 and $8 stocks are a result of no respect.”"
Squilliam
17-Jan-2010, 21:54
Even Nvidia and Amd work together sometimes
"In a normal class certification hearing, the plaintiffs revealed an email between Nvidia senior VP of marketing, Dan Vivoli, and ATI’s president and COO, Dave Orton, which points to inflated prices and collusion. It reads: “I really think we should work harder together on the marketing front. As you and I have talked about, even though we are competitors, we have the common goal of making our category a well positioned, respected playing field. $5 and $8 stocks are a result of no respect.”"
Another Dave? I've got the 'Clone Wars' vibe going on here. So is it multiple clones of the one 'Dave' or is it one 'Dave' doing multiple jobs?
Anyway is that legal to work together on industry wide marketing collusion so long as they don't cooperate on price? I think other industries have worked together on standards and thats fine so long as its not anticompetitive right?
well that quote was from july 2008
http://www.law.com/jsp/article.jsp?id=1202422773207
Silent_Buddha
19-Jan-2010, 15:53
It's amazing that you continue to completely ignore the fact that Havok on its own is a profitable venture. If it was costing Intel money I could see they may shutter it or far more likely, try to find a buyer for it.
But Intel is a business. They make money because they generally follow good business practices.
Havok is providing a postive revenue stream. Intel won't be shuttering it or otherwise changing any aspect of Havok, especially since Havok is relatively independant of Intel.
Noone will argue that Intel most likely were hoping to use Havok to help push Larrabee. But to think that Intel will suddenly attempt to sabotage Havok in order to spite the rest of the industry? That's just so far out in left field, I don't even know how to comment on it.
In fact if you are going to use emotions to guide business practices as you seem to be advocating. Intel would be far more likely to partner with AMD with regards to Havok in order to spite Nvidia who have been directly provoking Intel. Fortunately, Intel is a business. And such things like that won't factor into it.
Havok makes money. Havok continues to make money. Thus business as usual.
Regards,
SB
They make money because they generally follow good business practices.
Curiously, the FTC, the EU, AMD, and Nvidia seem to be in rare agreement about the fact that above statement is questionable.
Havok is providing a postive revenue stream.
Like software modems, sound, vertex processing and virtualisation, Havok is just another reason to sell quadcore CPUs.
Mintmaster
19-Jan-2010, 16:35
Intel's only (real) interrest in Havok is "larrabee" related.
Funny how all your arguments are pre-"larragate"
It's not only Larrabee related. They want Havok to maintain dominance in the physics market because then they can use the CPU implementation to their advantage over AMD's CPUs.
If that means making their CPU look weak compared to a top of the line AMD GPU in certain situations, so be it. For the majority of the market, though, they only care about making their CPU look better than AMD's CPU.
CNCAddict
20-Jan-2010, 03:54
This is good stuff. nVidia just keeps stepping in it.
http://www.xbitlabs.com/news/multimedia/display/20100119134616_AMD_Accuses_Nvidia_of_Disabling_Mul ti_Core_CPU_Support_in_PhysX_API.html
But to nVidias defense..at least they have something. The following video is from 06..... running on a X1600. The 58xx series should be a monster at physics :sad: Epic FAIL at the end of the video with the "end of this year" promise. We don't even have a flipping demo yet...
gLgb9AdnaBI
FrameBuffer
20-Jan-2010, 07:24
This is good stuff. nVidia just keeps stepping in it.
http://www.xbitlabs.com/news/multimedia/display/20100119134616_AMD_Accuses_Nvidia_of_Disabling_Mul ti_Core_CPU_Support_in_PhysX_API.html
But to nVidias defense..at least they have something. The following video is from 06..... running on a X1600. The 58xx series should be a monster at physics :sad: Epic FAIL at the end of the video with the "end of this year" promise. We don't even have a flipping demo yet...
gLgb9AdnaBI
Yeah unfortunately ATI is epic for making promises and never fulfilling them.. but hey they haven't joined the likes of DNF/BB .. yet
I don't get this part of the interview:
bit-tech: Given Intel's approach to using Intel Architecture (IA) in Larrabee, and as an x86 company yourself, do you think it's because Intel are using IA specifically that it's the problem?
RH: They really have a whole host of problems: some of which I wouldn't want to describe in too much detail because it points them in the right direction and they've got their own engineers to see that. The x86 instruction set is absolutely not ideal for graphics and by insisting on supporting the whole of that instruction set they have silicon which is sitting around doing nothing for a significant amount of time.
By building an in-order CPU core - which is what they are doing on Larrabee - they are going to get pretty poor serial performance. When the code is not running completely parallel their serial performance will be pretty dismal compared to modern CPUs. As far as I can tell they haven't done a fantastic job of latency hiding either - it's hyperthreaded like mad and has a huge, totally conventional CPU cache. Well it shouldn't come as a big surprise that it's simply not what we do. Our GPU caches simply don't work like CPU caches and they are for flushing data out of the pipeline at one end and preparing it to be inserted at the other - a read and write cache to keep all the GPU cores filled. One large cache and lots of local caches for the cores is not a great design. On top of which it doesn't actually have enough fixed function hardware to take on the problem as it's set out at the moment, so it needs to be rearchitected if Intel is to have a decent chance of competing.
(The bold part) I don't get isn't it obvious? Would it be possible to preserve throughput and improve serial perfs in chip of the same size at larrabee? Is it a bit of free bashing or he suggests that as Larrabee was not to compete with nowadays GPUs and Intel should have known it they may have made sense to sacrifice some throughput to offer a more balanced chip (by the way making plain X86 choice for the ISA more relevant)?
Lonbjerg
20-Jan-2010, 08:48
It's amazing that you continue to completely ignore the fact that Havok on its own is a profitable venture. If it was costing Intel money I could see they may shutter it or far more likely, try to find a buyer for it.
But Intel is a business. They make money because they generally follow good business practices.
Havok is providing a postive revenue stream. Intel won't be shuttering it or otherwise changing any aspect of Havok, especially since Havok is relatively independant of Intel.
Noone will argue that Intel most likely were hoping to use Havok to help push Larrabee. But to think that Intel will suddenly attempt to sabotage Havok in order to spite the rest of the industry? That's just so far out in left field, I don't even know how to comment on it.
In fact if you are going to use emotions to guide business practices as you seem to be advocating. Intel would be far more likely to partner with AMD with regards to Havok in order to spite Nvidia who have been directly provoking Intel. Fortunately, Intel is a business. And such things like that won't factor into it.
Havok makes money. Havok continues to make money. Thus business as usual.
Regards,
SB
I just find few oddities in that first AMD starts talking Bullet-physics after been talking (Keyword: talking) Havok GPU-physics for years (since 2006) and then 3 months later Intel spill the beans about "Larra-gate" (the delay of "Larrabee").
And havok still makes money from it's CPU-software buisness...but that is not what I am talking about(The GPU side of things).
Take it to PM, or to the thread I made for those that want to solve their issues with Charlie. Please.
Lonbjerg
21-Jan-2010, 08:38
NVIDIA confirms my suspensions:
http://www.tomshardware.com/news/nvidia-physx-amd-gpu-multicore,9481.html#xtor=RSS-181
Huddy wasn't talking facts...
itsmydamnation
21-Jan-2010, 08:46
AMD accuses Nvidia of disabling multi-core CPU support in PhysX API
execpt that wasn't what was said was it?
keep looking im sure you will find your proof, or whatever your looking for, someday, maybe............
Is he saying anything more than that you're able to run multiple instances of the api in a multithreaded app ;)
At least it seems to confirm that the developer has to do all the work for a multithreaded cpu implementation on top of doing the gpu-physx part.
We continue to invest substantial resources into improving PhysX support on ALL platforms--not just for those supporting GPU acceleration.
But yet they haven't made the most obvious optimization for one of the most common platforms.
Arnold Beckenbauer
21-Jan-2010, 12:16
It's true, that Vantage's CPU test uses all CPU cores, which are available: For every core it adds more "stuff".
The question is: My pc has a quad-core CPU. If Vantage's CPU test runs in a "dual-core mode", are then all four cores in use or just two?
trinibwoy
21-Jan-2010, 17:36
NVIDIA confirms my suspensions:
http://www.tomshardware.com/news/nvidia-physx-amd-gpu-multicore,9481.html#xtor=RSS-181
Huddy wasn't talking facts...
Just came across that. Seems to corroborate what ChrisRay was saying earlier. Demirug made an excellent point as well - all the complaining about PhysX not maximizing CPU cores seems to completely ignore the fact that custom built physics implementations don't either. Maybe there's something to all this besides Nvidia's evil intentions to cripple CPU performance?
all the complaining about PhysX not maximizing CPU cores seems to completely ignore the fact that custom built physics implementations don't either. Maybe there's something to all this besides Nvidia's evil intentions to cripple CPU performance?
I thought the [H] video shown upstream was indeed stressing all of the CPU? "Using the CPU? Yes, it's definitely using all cores of the CPU"
One should only have to run Ghostbusters and have yes or no on physx utilization. My bet would be that Ghostbusters on PC has much better CPU utilization than the aforementioned Batman and Sacred.
Unless, of course.. the latter were designed to only run with very low CPU utilization on Radeon powered machines. We're not even talking about multicore utilization here, we're at a point where the PhysX cannot even stress one single core.
trinibwoy
21-Jan-2010, 18:11
[H] is using task manager which is hardly an accurate way to tell how much an application is using multiple CPU cores (or how much work the CPU is doing).
The people who wrote and develop the API are telling their story and it seems to be confirmed by people who have actually used the SDK. Anything else amounts to guesswork.
The story being that PhysX can't (and never could) accelerate a single scene with multiple threads on the x86. You can create multiple threads but unless you want to simulate non interacting systems it's useless ...
Just came across that. Seems to corroborate what ChrisRay was saying earlier. Demirug made an excellent point as well - all the complaining about PhysX not maximizing CPU cores seems to completely ignore the fact that custom built physics implementations don't either. Maybe there's something to all this besides Nvidia's evil intentions to cripple CPU performance?
The difference is that with say Batman we have proof positive that the operations PhysX are doing are bottlenecking as long as it's running slower as with PhysX on the GPU and not maxing out the CPUs. We know it's relatively latency insensitive and trivially parallelizeable (it can run on a GPU after all). We don't know what the bottlenecks in those other games are.
Tomshardware got a bit puzzled on PhysX on CPU in their Batman review. Weird. Put software PhysX on high and the CPU utilization decreases instead of increases. Shouldn't PhysX use the CPU more and not less when you put PhysX on high on the CPU?:
http://media.bestofmicro.com/N/O/228948/original/Batman%20PhysX%20Soft%20CPU.png
Why is CPU utilization lower when PhysX is enabled? And why is CPU utilization so low at all? If the CPU is bottlenecking the PhysX calculations, shouldn't the increased load be pushing the CPU to its limits?We're trying to get clarification from the developers (http://www.tomshardware.com/reviews/batman-arkham-asylum,2465-10.html#) at Rocksteady about this phenomenon--it's almost as though the game is artificially capping performance at a set level, and is then using only the CPU resources it needs to reach that level.http://www.tomshardware.com/reviews/batman-arkham-asylum,2465-10.html
No, is normal. There are to much physics calculation for one core. The other core(s) is (are) waiting for the next information.
Here is a example of this behaviour: http://physxinfo.com/news/1727/dark-void-benchmark-and-physx-patch-available/
trinibwoy
21-Jan-2010, 22:26
We don't know what the bottlenecks in those other games are.
Yes, that's exactly my point. Why is it that PhysX games qualify for such scrutiny yet other physics engines don't? There also aren't any examples of other physics engines doing particle simulations on the CPU with good performance.
Tomshardware got a bit puzzled on PhysX on CPU in their Batman review. Weird. Put software PhysX on high and the CPU utilization decreases instead of increases. Shouldn't PhysX use the CPU more and not less when you put PhysX on high on the CPU?:
Yeah that's really weird. I'm not one for conspiracy theories so it could be something as simple as PhysX putting a higher load on the memory subsystem - after all Nvidia did mention that SPH is much faster on Fermi due to better caching. Also, as Sontin pointed out the PhysX thread(s) could be starving other threads that are normally free to run.
Squilliam
21-Jan-2010, 22:32
Yes, that's exactly my point. Why is it that PhysX games qualify for such scrutiny yet other physics engines don't? There also aren't any examples of other physics engines doing particle simulations on the CPU with good performance.
I suspect its due to the fact that PhysX can be turned on/off and there are multiple levels of implementation which can be activated/deactivated in the games settings. I have not personally seen the ability to turn off Havok physics in any games, so I guess thats the reason.
Since physics is another one of those ridiculously parellel workloads it doesn't make sense for it to not be implemented on multiple cores and the perceived conflict of interest between Nvidias GPUs and CPU implementation simply adds fuel to the fire.
Yeah that's really weird. I'm not one for conspiracy theories so it could be something as simple as PhysX putting a higher load on the memory subsystem - after all Nvidia did mention that SPH is much faster on Fermi due to better caching. Also, as Sontin pointed out the PhysX thread(s) could be starving other threads that are normally free to run.
Both starving other threads as Sontin argued and an artificial cap as Tomshardware argued are plausible explainations. If you see the results on the performance, the 4870 has the same framerate going from 1280x1024 to 2560x1600. Normally, this would be a huge performance hit, but in Batman AA, the FPS is the same regardless of resolution:
http://media.bestofmicro.com/N/T/228953/original/Batman%20PxHigh%201280.png
http://media.bestofmicro.com/N/W/228956/original/Batman%20PxHigh%202560.png
That makes Batman even weirder. Its the only game I've seen where there is no performance hit going to 2560x1600. But, if Sontin is right and its the threads that are starved, shouldn't that effect the framerates more on a larger resolution?
trinibwoy
21-Jan-2010, 22:43
Since physics is another one of those ridiculously parellel workloads it doesn't make sense for it to not be implemented on multiple cores and the perceived conflict of interest between Nvidias GPUs and CPU implementation simply adds fuel to the fire.
Agreed, I just don't get why the benchmark for PhysX games is higher than for other games. I can't reconcile the uproar over PhysX with the fact that most entire game engines (including physics) do not scale past two cores. Take Crysis for example:
http://img192.imageshack.us/img192/6572/crysisb.png
http://www.guru3d.com/article/cpu-scaling-in-games-with-quad-core-processors/9
Squilliam
21-Jan-2010, 23:03
Agreed, I just don't get why the benchmark for PhysX games is higher than for other games. I can't reconcile the uproar over PhysX with the fact that most entire game engines (including physics) do not scale past two cores. Take Crysis for example:
Its an unfortunate situation, im trying to give Nvidia the benefit of the doubt here but theres a lot of doubt, especially when a game with so much cross vendor controversy like Batman: AA shows competing hardware as 100% PhysX limited.
Game engines in entirety may not scale particularly well over more than two cores but many individual parts of the game engine can be scaled relatively easily over more than two cores and physics is one of them.
Amdahl's Law dictates that a game engine can only scale until its limited by its most serial component. In this case its an incredibly parellel workload which is apparantly triggering Amdahl's law on the systems with AMD GPUs and PhysX. This absolutely does not make sense.
MrGaribaldi
21-Jan-2010, 23:06
But does that look like a well threaded implementation?
Granted, I haven't played either Batman nor Dark Void, but it does seem unlikely that any one of them would have a single physics task that would maximise any one core on the low setting. Assuming that the developers have split the physics tasks into reasonably small workloads, why aren't those then split more evenly amongst the available cores?
Is this something that can easily be set up by specifying how many threads you want to run the tasks on, and the PhysX library handling the rest, do you need to manage the PhysX threads yourself to balance them, or do you need to run multiple contexts of PhysX with all the overhead that would include?
If it is either of the first two options, then it would point to the devs and how they have chosen to implement/use the PhysX physics. If it is the latter, then it would point to the library having a sub-par multicore CPU implementation.
It would also be very interesting to learn more about how the PS3 implementation is done, if (and how) it uses the SPEs, how it balances between the work, to compare with how it runs on the CPU on a PC. If the PS3 solution has a good solution for how to assign the jobs to SPEs, there is little reason why a similar system isn't available on the CPU (if it isn't).
Do anyone information they can share which will help to shed light on these questions?
Yeah that's really weird. I'm not one for conspiracy theories so it could be something as simple as PhysX putting a higher load on the memory subsystem - after all Nvidia did mention that SPH is much faster on Fermi due to better caching. Also, as Sontin pointed out the PhysX thread(s) could be starving other threads that are normally free to run.
Easy enough to test, although I put the odds somewhere between slim and none, underclock the memory (without SIMD it's not going to be the cache). Don't have the game though.
Lonbjerg
22-Jan-2010, 07:55
One thing people also need to remember when comapring GPU to CPU physics is that all the rigid body collisions with destructable architechture I have seen on the CPU in games result in where the fragments dissapear after 5-10 seconds.
From Ghostbusters to Force Unleashed.
So not only are you getting lower performance...you also get less fidelity and immersion with CPU-physics.
An analogy would be that GPU physics is like running with AA and AF and getting +30 FPS, while CPU physics is like no AA and AF and yet you still only get ~3 FPS when doing the same task.
http://pc.watch.impress.co.jp/img/pcw/docs/343/671/08.jpg
http://pc.watch.impress.co.jp/img/pcw/docs/343/671/09.jpg
http://pc.watch.impress.co.jp/docs/column/ubiq/20100121_343671.html
その実装はもちろんNVIDIAのGPUだけでなく、AMDのGPUにも有効なものだったのだが、開発者は 中国でAMDのDirect3D 10対応GPUを入手できなかったため、NVIDIAが近所の小売店で買ったものを送ってテストさせたのだ という。
Its an unfortunate situation, im trying to give Nvidia the benefit of the doubt here but theres a lot of doubt, especially when a game with so much cross vendor controversy like Batman: AA shows competing hardware as 100% PhysX limited.
It's worse than that. Toss an NV PhysX gpu in that competing vendor rig and PhysX will run fine, but AA is still disabled unless you hack the inis to fool the proggy into thinking it's an NV card and then, miraculously, AA works.
The "Nvidia workaround" was to force AA through CCC which gave very slow AA compared to the in-game MSAA. Nice trick to win the benchies.
Squilliam
22-Jan-2010, 18:51
It's worse than that. Toss an NV PhysX gpu in that competing vendor rig and PhysX will run fine, but AA is still disabled unless you hack the inis to fool the proggy into thinking it's an NV card and then, miraculously, AA works.
The "Nvidia workaround" was to force AA through CCC which gave very slow AA compared to the in-game MSAA. Nice trick to win the benchies.
Considering the fact that the test system was a Core i7, I cannot see how a processor with that much floating point performance could get bogged down so badly by PhysX. I've heard that PhysX is code which is copyrighted, I wonder how that effects the ease of a CPU implementation. Its like the game turns the CPU into a single core P4 2.4Ghz Northwood once its activated. Surely the out of the box implementation should at least use two cores standard!
How can developers even take it as a serious Physics implementation if its only good for technology demos on the latest Nvidia GPUs whilst none of the older G92 and below can implement it without taking a massive hit to performance and none of the ATI cards can do it at all if they don't have a decent CPU implementation?
Free license and free developers which will also help for your console versions, where the PhysX probably isn't quite so atrocious (not to mention the physics budget is smaller on consoles anyway, so a pure single threaded implementation might be enough if it at least has some decently optimized SIMD code ... unlike on x86). It's a pure business decision ...
AlStrong
22-Jan-2010, 19:55
http://pc.watch.impress.co.jp/img/pcw/docs/343/671/08.jpg
http://pc.watch.impress.co.jp/img/pcw/docs/343/671/09.jpg
http://pc.watch.impress.co.jp/docs/column/ubiq/20100121_343671.html
Someone want to explain why G16R16 format is relevant here :?: MSAA did work with Gears of War...
Lonbjerg
23-Jan-2010, 11:06
Considering the fact that the test system was a Core i7, I cannot see how a processor with that much floating point performance could get bogged down so badly by PhysX. I've heard that PhysX is code which is copyrighted, I wonder how that effects the ease of a CPU implementation. Its like the game turns the CPU into a single core P4 2.4Ghz Northwood once its activated. Surely the out of the box implementation should at least use two cores standard!
How can developers even take it as a serious Physics implementation if its only good for technology demos on the latest Nvidia GPUs whilst none of the older G92 and below can implement it without taking a massive hit to performance and none of the ATI cards can do it at all if they don't have a decent CPU implementation?
I got this link somewhere on this forum:
http://golubev.com/about_cpu_and_gpu_2_en.htm
Only it gets worse with physics, as physics scales badly (and not at all linear) with more CPU cores.
Compare it to running the graphics on the CPU...it the same thing, people should stop thinking the CPU is better than it really is...because it isn't.
If we alter you statement to:
"Considering the fact that the test system was a Core i7, I cannot see how a processor with that much floating point performance could get bogged down so badly by rendering graphics"
Do you get it now?
aaronspink
23-Jan-2010, 12:53
I got this link somewhere on this forum:
http://golubev.com/about_cpu_and_gpu_2_en.htm
Only it gets worse with physics, as physics scales badly (and not at all linear) with more CPU cores.
Compare it to running the graphics on the CPU...it the same thing, people should stop thinking the CPU is better than it really is...because it isn't.
If we alter you statement to:
"Considering the fact that the test system was a Core i7, I cannot see how a processor with that much floating point performance could get bogged down so badly by rendering graphics"
Do you get it now?
Physics scales badly with more CPU cores? Um... Someone might want to do some actual research instead of just making things up on the fly. Physics is EASIER to scale with more CPU cores than it is to make it run fast on GPUs. Here's a newflash, the majority of all physics in the world is run on massively multi-processors CPUs. There's a reason by governments spend upwards of 1 BILLION on by supercomputers that are effectively MPPs of OTS cpus.
My point was that even if PhysX scales poorly on i7, NV still clearly haves Batman:AA so that ATI cards would be hobbled. It's no different than the renaming exes of old tricks except this one's harder to detect & defeat.
Even if you do fool the game into thinking your cypress is NV & hacking you NV drivers to allow PhysX to run on your second NV gpu, the proggy will re-detect you card he next time and disable in-game MSAA that was previously working.
I think NV makes great products, but their "marketing tactics" suck.
entity279
23-Jan-2010, 14:38
(this post continues on what aaron said)
That's why I am not impressed at all by nV PR on this one.
If they really say that GPU is better for Physics then they should just point us to a few algorithms that are implemented on the Physics API and are often called on current Physics implementations. I'm sure such algoritms are rather well known and it's easy to determine which implementation (CPU/GPU) would be better.
It was said (forgot the links, but surely have been posted on this forum) that some functions have GPU only implementations. Ok, than why did they claimed that is up to game devs to implement multicore CPU Physics if the CPU part of the API is incomplete?
Now really, i just don't like their "we're the good guys, we give Physics to everybody (but nobody=AMD wants it)" attitude. If they want to increase GPU sales with Physics help, fine by me. But then just say something (as PRish as it is) like "we will concentrate on Physics for nVidia GPU, because we believe they are the future of gaming"
Havok has multithreading, Bullet has a multithreaded solver (no broadphase yet though), that Infernal Engine is obviously multithreaded, a quick google found BEPU-Physics with a multithreaded broadphase and solver.
Lonbjerg
23-Jan-2010, 16:17
Physics scales badly with more CPU cores? Um... Someone might want to do some actual research instead of just making things up on the fly. Physics is EASIER to scale with more CPU cores than it is to make it run fast on GPUs. Here's a newflash, the majority of all physics in the world is run on massively multi-processors CPUs. There's a reason by governments spend upwards of 1 BILLION on by supercomputers that are effectively MPPs of OTS cpus.
I was talking milk-of-the-run desktop PC's, not server clusters, feel free to prove me wrong :razz:
aaronspink
23-Jan-2010, 16:30
I was talking milk-of-the-run desktop PC's, not server clusters, feel free to prove me wrong :razz:
You do realize its easier to extract parallelism with something that is using a big large cache with low latencies for communication rather than message passing over less than 1 GB/s of network bandwidth with multiple millisecond latencies, right?
So, at this point, I think I've done more than enough shooting fish in a barrel over your hypothesis, maybe you should try actual proof for your preposterous claim. As far as my hypothesis, their are decade of research available including multitudes of millions of dollars spent in both software and hardware. I think all the proof I need is readily self evident (hell if it parallelizes on a GPU, then its trivial to parallelize it on a couple cpu cores.)
So you can either admit you were wrong or admit that you are either a paid shill or a troll. Which will it be?
willardjuice
23-Jan-2010, 17:11
I was talking milk-of-the-run desktop PC's, not server clusters, feel free to prove me wrong :razz:
So PhysX can be parallelized over a GPU, but not a CPU? I don't get it.
AlStrong
23-Jan-2010, 17:14
So PhysX can be parallelized over a GPU, but not a CPU? I don't get it.
Unbeliever!
entity279
23-Jan-2010, 17:41
So PhysX can be parallelized over a GPU, but not a CPU? I don't get it.
aaronspink didn't say it can't be parallelized on GPU so what are you talking about?
hell if it parallelizes on a GPU, then its trivial to parallelize it on a couple cpu cores
And it's not just about Physics. Is about physical simulations done on a computer. They've all worked on the CPU in the past, so why should they be so under-performing now?
willardjuice
23-Jan-2010, 17:52
aaronspink didn't say it can't be parallelized on GPU so what are you talking about?
And it's not just about Physics. Is about physical simulations done on a computer. They've all worked on the CPU in the past, so why should they be so under-performing now?
?
I was (I thought clearly) replying to Lonbjerg. I don't even know how you thought I was responding to Aaron. :razz:
Unbeliever!
What!?! Everyone knows I think PhysX is bigger than 3D!!!111
trinibwoy
23-Jan-2010, 18:39
And it's not just about Physics. Is about physical simulations done on a computer. They've all worked on the CPU in the past, so why should they be so under-performing now?
Underperforming compared to which other CPU based physics engine?
Groo The Wanderer
23-Jan-2010, 19:11
(this post continues on what aaron said)
That's why I am not impressed at all by nV PR on this one.
If they really say that GPU is better for Physics then they should just point us to a few algorithms that are implemented on the Physics API and are often called on current Physics implementations. I'm sure such algoritms are rather well known and it's easy to determine which implementation (CPU/GPU) would be better.
It was said (forgot the links, but surely have been posted on this forum) that some functions have GPU only implementations. Ok, than why did they claimed that is up to game devs to implement multicore CPU Physics if the CPU part of the API is incomplete?
Now really, i just don't like their "we're the good guys, we give Physics to everybody (but nobody=AMD wants it)" attitude. If they want to increase GPU sales with Physics help, fine by me. But then just say something (as PRish as it is) like "we will concentrate on Physics for nVidia GPU, because we believe they are the future of gaming"
If NV actually wanted to show how much better GPU physics were than CPU, instead of putting out a hobbled versions that runs x87 code instead of SSE/2/3, they would put out something that is decently optimized for the CPU and scales well. Then they could simply say, assuming that they are not wrong about the relative speeds, and they are, that you need to have (pick a number) 12 cores before a Nehalem is faster than a 9800/250/350/450, and can prove that with scaling. The way they do it now just makes them look like weasels.
And I also agree that the best tool they have to fight Intel right now is physics, but they are blowing their own legs off with a shotgun, limping around and looking for more ammo to remove those pesky knees with instead of working WITH ATI to go after Intel. Then again, NV has proven to just about everyone that they can not be worked with, so no loss in reality.
NV management is playing this totally wrong, but is that news?
-Charlie
entity279
23-Jan-2010, 19:32
?
I was (I thought clearly) replying to Lonbjerg. I don't even know how you thought I was responding to Aaron. :razz:
Indeed. Let's just say that my axon pattern is different than yours ;). That and I was quickly reading through the last 2-3 posts :oops:.
Underperforming compared to which other CPU based physics engine?
So the other (less used) physics engines for games are just as bad on CPU?
That makes Batman even weirder. Its the only game I've seen where there is no performance hit going to 2560x1600. But, if Sontin is right and its the threads that are starved, shouldn't that effect the framerates more on a larger resolution?
I decided to try it out with Batman myself and it looks like its still weird. On a 5870 (vs. 4870 in Tomshardware review) with a Q9550 (vs. I7 920 in Tomshardware), I got almost the same in Batman benchmark going from 1280x768 to 1920x1200 with same settings as tomshardware. 1 FPS performance hit in average:
1280x768:
http://img714.imageshack.us/img714/9034/batman1280x768.jpg
1920x1200:
http://img15.imageshack.us/img15/1151/batman1920x1200.jpg
You get the same fps because your cpu can't calculate the physics information fast enough. Your graphics card is waiting for work. It's the same with the other cpu cores.
You get the same fps because your cpu can't calculate the physics information fast enough. Your graphics card is waiting for work. It's the same with the other cpu cores.
I was just about to edit my post. I ran another benchmark and this time with PhysX on normal (not off). Still the same average, though maximum went higher:
http://img686.imageshack.us/img686/3370/batman1920x1200normal.jpg
trinibwoy
23-Jan-2010, 21:35
If NV actually wanted to show how much better GPU physics were than CPU, instead of putting out a hobbled versions that runs x87 code instead of SSE/2/3, they would put out something that is decently optimized for the CPU and scales well.
Yeah, optimizing for your competitor's products is a sure fire business strategy. Entertaining, as always Charlie :D
So the other (less used) physics engines for games are just as bad on CPU?
That's precisely my question. I see a lot of judgements being made about PhysX but they seem to be pulled out of thin air. Where are the other CPU based physics engines that do all these things that PhysX supposedly falls short on? Examples of more computationally intense workloads or higher performance on the same workload are welcome.
Squilliam
23-Jan-2010, 22:09
That's precisely my question. I see a lot of judgements being made about PhysX but they seem to be pulled out of thin air. Where are the other CPU based physics engines that do all these things that PhysX supposedly falls short on? Examples of more computationally intense workloads or higher performance on the same workload are welcome.
http://enthusiast.hardocp.com/article/2009/05/19/real_world_gameplay_cpu_scaling
Something like this?
trinibwoy
23-Jan-2010, 22:29
Sorry, can you be a little more specific? Where's the evidence that the physics effects in those games are more computationally taxing or that the engines are more efficient/scalable/faster etc?
Edit: Oh, were you referring to the Ghostbusters video? I see a few simple rigid body effects where most of the "debris" simply disappears after half a second or so without interacting with the environment. No where near a physics showcase.
Absolute performance isn't proven, scalability is ... in that it can scale at all beyond a single thread (which PhysX can not in a meaningful way besides what NVIDIA says).
trinibwoy
23-Jan-2010, 22:44
That's not particularly relevant at all unless you can point to another engine that scales with multiple cores and produces effects that aren't possible or are slow with PhysX. Most of the angst over PhysX has been over comparisons to GPU PhysX, which is silly to me since that's not its competition.
Most of the angst over PhysX has been over comparisons to GPU PhysX, which is silly to me since that's not its competition.
Of course it is, if it's supposed to influence your next graphics card buying decision.
eastmen
24-Jan-2010, 00:34
That's not particularly relevant at all unless you can point to another engine that scales with multiple cores and produces effects that aren't possible or are slow with PhysX. Most of the angst over PhysX has been over comparisons to GPU PhysX, which is silly to me since that's not its competition.
The main problem is that other games scale based on cpu cores while physx games like batman do not. Batman hardly cares if i have a quad core or a dual core.
So as gamers we are buying faster cpus and gpus to get better performance but nvidia through controling physx is forcing their hardware on us and rendering other hardware useless.
Thats why I'm done buying physx games.
Karoshi
24-Jan-2010, 00:37
That's not particularly relevant at all unless you can point to another engine that scales with multiple cores and produces effects that aren't possible or are slow with PhysX. Most of the angst over PhysX has been over comparisons to GPU PhysX, which is silly to me since that's not its competition.
Easiest physics possible, point particles, valve particle benchmark. First hit on google "valve particle benchmark" from December 2008:
http://www.overclock.net/nvidia/314125-official-valve-particle-benchmark-results-thread.html
From that thread:
Username--------------Metric Score------------CPU/SPEED
1. Emmett--------------------125---------------Q6600 @ 4GHz
2. grunion--------------------123-----------------Q6600 @ 3.7GHz
3. rolandooo-----------------120----------------Q6600 @ 3.7GHz
4. kbrescher------------------118------------------Q9450 @ 3.5GHz
5. Tricky-----------------------116------------------Q6600 @ 3.6GHz
6. Criswell---------------------115---------------------Q6600 @ 3.84 GHz
7. Havegooda----------------108-----------------------Q6600 @ 3.46GHz
8. h33b------------------------106-------------------Q6600 @ 3.42GHz
9. Hailscott-------------------105-----------------------Q6600 @ 3.15GHz
10. spazbob------------------104----------------------Q6600 @ 3.30GHz
11. PGT96AJT------------------100------------------Q6600 @ 3.2GHz
12. spazzbob------------------93-------------------Q6600 @ 3.15GHz
13. l0ckd0wn------------------90-------------------Q6600 @3.2Ghz
14. lordikon--------------------73-------------------e8400 @ 3.81GHz
15. RoadRashed---------------71-------------------E8400 @ 3.6GHz
16. SiPex-----------------------63-------------------E6750 @ 3.6GHz
17. j_canna---------------------57--------------------e6400 @ 3.2GHz
18. Vegnagun666-------------38-------------------X2 4000+ @ 2.81GHz
19. Quicks----------------------34-------------------Opteron 170 @ 2.81GHz
Recently i saw some cryostasis shots with sparky particles. How well does that scale on CPU physX physics with quad cores?
Nebula has some experience with crysis sparky particles orgies, maybe he can give us some configs so we can try out the timedemos with millions of particles on different dual and quad core CPUs and lowest gfx settings?
I guess steam p0war3d games @anno 2008 and crysis are actual popular comparison vs. physX physics?
aaronspink
24-Jan-2010, 01:42
That's not particularly relevant at all unless you can point to another engine that scales with multiple cores and produces effects that aren't possible or are slow with PhysX. Most of the angst over PhysX has been over comparisons to GPU PhysX, which is silly to me since that's not its competition.
There are multiple engine that scale with multiple cores. They can produce all the effects that nvidia's solution can, so I think you need to drop this constant stone wall response. There is NOTHING physx can do that other physics engines cannot and all the rest actually have multi-cpu support. ergo, the issue is physx and it limitations.
trinibwoy
24-Jan-2010, 02:26
Of course it is, if it's supposed to influence your next graphics card buying decision.
PhysX's CPU performance doesn't change depending on what graphics card you have. If you want GPU PhysX then that's a whole other story isn't it? What people are complaining about is PhysX's deficiency on the CPU and I'm still waiting for evidence of such.
Easiest physics possible, point particles, valve particle benchmark.
If I'm not mistaken that's a particle system with no physical simulation.
There are multiple engine that scale with multiple cores. They can produce all the effects that nvidia's solution can, so I think you need to drop this constant stone wall response. There is NOTHING physx can do that other physics engines cannot and all the rest actually have multi-cpu support. ergo, the issue is physx and it limitations.
Where was it stated that other engines can't do what PhysX does? You guys are the ones constantly harping that PhysX has a poor CPU solution so it should be easy enough to find examples of other physics engines that prove that point. Interestingly, such evidence isn't forthcoming. Can't really stone wall against nothing.
Physx on the CPU tanks miserably when tasked with any sort of fluid or cloth simulation but since no other CPU implementation even attempts those things then where are the comparisons coming from? Even rigid body stuff is pretty rudimentary across the board.
Dave Baumann
24-Jan-2010, 02:53
You might want to take a look at some of the stuff done in Force Unleashed.
http://www.eurogamer.net/videos/star-wars_the-force-unleashed_physics-dev-diary
trinibwoy
24-Jan-2010, 03:47
Yeah DMM looks very nice (both visually and from a technology standpoint). The first general purpose physics library to integrate something like that would have a nice advantage. I didn't see any of the heavy stuff that usually brings CPUs to their knees though, i.e the fluid and cloth simulations mentioned above. The Havok bits were just the usual crate kinematics.
I couldn't tell from the video but does DMM debris interact with the environment? It was clear that the big wood chunks did but the smaller objects like glass shards seemed to disappear in mid-air.
willardjuice
24-Jan-2010, 04:02
Alright I think this off-topic discussion has run its course. If the respective parties haven't "seen the light" at this point, it's unlikely they will ever. I will delete posts relating to" PhysX CPU efficiency" in this thread from now on. Start a new thread if you feel the discussion must go on.
Broken Hope
27-Jan-2010, 16:36
The bottom line is we have enough; we don't let triple-A or double-A titles go through the net and in fact it's extremely rare for a Saboteur situation to come up. It's very rare for titles as a whole to go past us without seeing our QA and testing labs along the way. Our team is big enough and actually exceedingly good at some of the things they do.
Going back to this again it seems Mass Effect 2 isn't classed as a triple A title since it's seemingly been released with no way to force AA and no Crossfire profile, unless this weeks drivers miraculously fix both issues but I doubt it.
Both issues fixable on Nvidia cards.
karlotta
28-Jan-2010, 19:18
Going back to this again it seems Mass Effect 2 isn't classed as a triple A title since it's seemingly been released with no way to force AA and no Crossfire profile, unless this weeks drivers miraculously fix both issues but I doubt it.
Both issues fixable on Nvidia cards.http://support.amd.com/us/kbarticles/Pages/force-Anti-Aliasing-support-in-Crossfire.aspx
Broken Hope
28-Jan-2010, 20:04
http://support.amd.com/us/kbarticles/Pages/force-Anti-Aliasing-support-in-Crossfire.aspx
Which is nice but they have a bug that prevents monitors going into suspend, so now we have to choose between proper game support and power saving. Not a good trade off to be honest.
Which is nice but they have a bug that prevents monitors going into suspend, so now we have to choose between proper game support and power saving. Not a good trade off to be honest.
Does your monitor lack a power button? If it's really that big a deal, you could turn it off.
-FUDie
Broken Hope
28-Jan-2010, 23:01
Does your monitor lack a power button? If it's really that big a deal, you could turn it off.
-FUDie
Sure it has a power button, still no excuse for a video driver to break such a basic feature such as windows power saving.
eastmen
29-Jan-2010, 04:27
Sure it has a power button, still no excuse for a video driver to break such a basic feature such as windows power saving.
I'm not having the problem you speak of with the 10.1s or the hotfix .
PatrickL
29-Jan-2010, 09:03
I don't have this problem too.
jimmyjames123
29-Jan-2010, 09:09
You might want to take a look at some of the stuff done in Force Unleashed.
http://www.eurogamer.net/videos/star-wars_the-force-unleashed_physics-dev-diary
Interesting, because apparently LucasArts initially opted not to release a personal computer version of The Force Unleashed, stating that doing the game well would be too processor-intensive for typical PCs and that scaling down the game's procedural physics for the PC platform would "fundamentally" change The Force Unleashed's gameplay......until they changed their mind and decided to release a PC version one year after the console version. And this Havok game ended up being critically panned by almost all reviewers (although it was a sales success on the consoles), whereas the PhysX game Batman Arkham Asylum has opened to rave critical reviews, and the developers are not complaining about the game being "too processor-intensive for typical PCs". Go figure.
Ninjaprime
29-Jan-2010, 12:33
Interesting, because apparently LucasArts initially opted not to release a personal computer version of The Force Unleashed, stating that doing the game well would be too processor-intensive for typical PCs and that scaling down the game's procedural physics for the PC platform would "fundamentally" change The Force Unleashed's gameplay......until they changed their mind and decided to release a PC version one year after the console version. And this Havok game ended up being critically panned by almost all reviewers (although it was a sales success on the consoles), whereas the PhysX game Batman Arkham Asylum has opened to rave critical reviews, and the developers are not complaining about the game being "too processor-intensive for typical PCs". Go figure.
Other than cheerleading with green pom-poms, whats your point there?
Bouncing Zabaglione Bros.
29-Jan-2010, 13:49
Interesting, because apparently LucasArts initially opted not to release a personal computer version of The Force Unleashed, stating that doing the game well would be too processor-intensive for typical PCs and that scaling down the game's procedural physics for the PC platform would "fundamentally" change The Force Unleashed's gameplay......until they changed their mind and decided to release a PC version one year after the console version. And this Havok game ended up being critically panned by almost all reviewers (although it was a sales success on the consoles), whereas the PhysX game Batman Arkham Asylum has opened to rave critical reviews, and the developers are not complaining about the game being "too processor-intensive for typical PCs". Go figure.
The reason why it was a success on the console and panned on the PC is because it was a console game ported to the PC, and the PC guys have much higher standards. This is especially true coming from long line of Jedi Knight games that were head and shoulders above Force Unleashed in many, many ways.
It wasn't because of Havok that PC gamers didn't like FU. It wasn't because of Physx that people liked Batman: AA. You're trying to make a connection that doesn't exist.
John Reynolds
29-Jan-2010, 14:33
Not to mention that the tech behind a game and the game's design and gameplay are just about totally separate. Batman: AA is just a damn good game, regardless of what physics middleware it uses.
Silent_Buddha
29-Jan-2010, 18:31
Interesting, because apparently LucasArts initially opted not to release a personal computer version of The Force Unleashed, stating that doing the game well would be too processor-intensive for typical PCs and that scaling down the game's procedural physics for the PC platform would "fundamentally" change The Force Unleashed's gameplay......until they changed their mind and decided to release a PC version one year after the console version. And this Havok game ended up being critically panned by almost all reviewers (although it was a sales success on the consoles), whereas the PhysX game Batman Arkham Asylum has opened to rave critical reviews, and the developers are not complaining about the game being "too processor-intensive for typical PCs". Go figure.
Next you're going to predict that Diablo 3 is going to get panned and fail due to Havok. ;)
Not to mention the long long list of PhysX games that have been utter trash and panned, through no fault of PhysX but just the fact the games were rubbish.
Regards,
SB
willardjuice
29-Jan-2010, 19:05
:facepalm:
Alright let me make this a little bit more broad/clear: I would appreciate if we had a separate thread that compares physics engines/middlewares. I feel that we often have the same argument over and over again in various threads. Having one unified thread would go a long way consolidating these arguments (I hope :razz:). I'd rather not split the thread as I wouldn't even know where to begin; thus I think it's best if we start fresh (so again, someone should start a new thread). Thanks!
[PREVIEW] PhysX Simulation on a 16-Core CPU: http://www.geeks3d.com/20100304/preview-physx-simulation-on-a-16-core-cpu/
So, is this fine grained multithreading or is he simply running 16 separate simulations? (AFAIK fine grained multithreading only exists on the console editions of PhysX.)
Arnold Beckenbauer
18-Mar-2010, 00:19
http://physxinfo.com/news/2390/new-physx-fluidmark-1-2-first-tests/
“# of CPU cores” is used specify number of CPU cores dedicated to simulation (up to 32 in current version), however this option is no so transparent as it looks – increased number of cores adds additional fluid emitters to the scene (one emitter per core or two in general), and with equal number of particles, various number of emitters can affect performance.
vBulletin® v3.8.6, Copyright ©2000-2013, Jelsoft Enterprises Ltd.