bit-tech Richard Huddy Interview - good Read
- Thread starter neliz
- Start date
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.
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.
If you spent less money each time yeah but technically that doesn't count as an "upgrade"
gamervivek
Regular
Not really that unique :smile2:
http://www.rage3d.com/previews/video/ati_hd5870_performance_preview/index.php?p=4
http://www.rage3d.com/previews/video/ati_hd5870_performance_preview/index.php?p=4
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.
Last edited by a moderator:
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.
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.
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.
Last edited by a moderator:
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?
Last edited by a moderator:
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.
Last edited by a moderator:
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.)
Mintmaster
Veteran
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.
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.
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.
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.
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.
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.
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.
