...or another way of playing with terms for semantics. Which IHV is likely to adopt CUDA for its architecture? None.
AMD RV770 refresh -> RV790
- Thread starter w0mbat
- Start date
...or another way of playing with terms for semantics. Which IHV is likely to adopt CUDA for its architecture? None.
The difference lies in who or what it is proprietary to. DirectX is proprietary to Microsoft, but not to any specific piece of hardware. Indeed, ATI and Nvidia hardware is actually designed to fit the DirextX API, not the other way around, and all hardware designers are therefore on an equal footing when it comes to supporting it. CUDA is specific to Nvidia - it's an API designed by Nvidia to be a good match with existing Nvidia hardware.
As I said above, the correct analogy is not Direct3D but Glide. Glide was an API designed purely for 3Dfx hardware, and it made no sense for anyone else to try and support it. It did pretty well, because it was far easier to programme for than early versions of Direct3D, and most gaming hardware was made by 3Dfx anyway. Once Direct3D caught up in terms of ease-of-programmability (which was somewhere around version 5) and once other hardware vendors were producing products that rivalled anything from 3dfx, Glide quietly faded away.
I fervently hope that PhysX does not become the established Physics API; I don't want to see good quality Physics support limited to one hardware vendor.
I fervently hope that PhysX does not become the established Physics API; I don't want to see good quality Physics support limited to one hardware vendor.
It can't purely on the basis that real PhysX (PPU) is incompatible with GPU Physics. That's what I ment with shot itself in the foot.
Sure, but now you're talking about the relative market positioning of Nvidia and Microsoft. There isn't anything inherently more open about DirectX except for the fact that Microsoft has a massive OS monopoly.
Or let me put it this way. Is it any harder for AMD/ATI to adopt CUDA than it is for them to adopt OpenCL? Nope.
nicolasb: How is CUDA specific to Nvidia hardware?
But with a proprietary solution like CUDA, developed by a competitor which has an interest in your cards being slower, you risk getting screwed. Just like nVidia is screwing people with quad-core CPUs which can't run PhysX fast enough as they can only use one core. However, if there's a third party developing the spec, and neither nV nor ATI have any big weight over the development process, it's safe for everyone.
This may be slightly tangential but that is akin to Apple adopting DirectX.
While it could be done, but it makes ZERO sense from a competitor perspective.
Jawed
Legend
I'm quite sure about this too, but I'll check with Mirror's Edge soon on how many cores it utilizes with physx on
Yep, completely agree. At this stage in the game AMD would be crazy to adopt CUDA. My point was that the comparison to DirectX wasn't particularly valid. This can go several ways. The most likely scenario is that OpenCL becomes the de-facto industry standard and the IHV's target their hardware accordingly. Another (albeit very unlikely) alternative is that Nvidia keeps pace with CUDA development and consistently provides richer and more functional software and hardware solutions for GPGPU relative to the potentially slower moving OpenCL spec. This could eventually vault CUDA into DirectX status: a proprietary standard that everyone adopts. But Nvidia doesn't control the GPGPU platform like Microsoft controls the PC so it's very unlikely.
Along these lines, I'm not sure how much innovation there can be in the parallel computing space in terms of API development. I would think the problem space is so broad and generic that the basic requirements of the API should be nailed down in just a few years and then it'll be all about hardware performance and efficiency.
Jawed
Legend
http://forums.techarena.in/web-news-trends/1027042.htm
Larrabee of course brings us the 2013 feature-set in 2010.
Is OpenCL just another GPGPU phase before Larrabee arrives?
Jawed
Larrabee of course brings us the 2013 feature-set in 2010.
Is OpenCL just another GPGPU phase before Larrabee arrives?
Jawed
I remember the software PhysX mode has been single-threaded since the the first tryout of CellFactor "promo" game. Mirror's Edge impl is no different by my account, as it's evident by the CPU load graphs.
Well to be fair, Nvidia's 2013 GPU also has a TB/s of bandwidth and 20 teraflops of compute power
But yeah, the general feature set should be nailed down pretty soon. But who knows what other "fixed-function" stuff will creep up in the next few years.
While the statement itself is undoubtedly true (even Nvidias own physx demos do not utilize more than one core) the real question is: Just how parallel is physics in itself. (I know, the question sounds a bit ridiculous - but give it a second's worth of thinking)
And with a blip more gaming realism: How much processing power would you really want to be taken away from the rest of the games' threads by PhysX?
Yes it does sound ridiculous. Obviously, physics through PhysX is parallel enough to run well on an array of parallel stream processors. I suppose it wouldn't make much sense to run physics on a GPU if it was a single-threaded task, would it?
Think about fluid simulation for example. If the recursive depth is high enough, you'd basically have every simulated particle potentially influencing every other particle, which would make the problem to solve quite serial, wouldn't it?
Now, nobody would do such a thing apart from scientific simulations and techdemos. But the larger your "kernel" (or whatever the influence diameter would be called in a technically correct way) becomes, the less parallel your physics becomes. Talking about the butterfly effect.
Sure - you can make it scale almost perfectly like in 3DMark Vantage's physics test, where no single system can influence the other systems. You can parallelize also things like particle systems for smoke and a system for cloth sim and some rigid body simulation - okay. But the more realistic it becomes, the more serial it gets.
Now, nobody would do such a thing apart from scientific simulations and techdemos. But the larger your "kernel" (or whatever the influence diameter would be called in a technically correct way) becomes, the less parallel your physics becomes. Talking about the butterfly effect.
Sure - you can make it scale almost perfectly like in 3DMark Vantage's physics test, where no single system can influence the other systems. You can parallelize also things like particle systems for smoke and a system for cloth sim and some rigid body simulation - okay. But the more realistic it becomes, the more serial it gets.
Jawed
Legend
http://www.pcgameshardware.com/aid,...hysx-effects-benchmark-review/Reviews/?page=2
Jawed
Looking at the CPU graphs on that page it appears that PhysX is indeed wasting huge amounts of available CPU capability.
Jawed
Jawed
Legend
What has any of this got to do with effects physics in games like Mirror's Edge, effects that are trivially parallelisable, not taking full advantage of available CPU when running on the CPU?
Jawed
Just switch to conspiracy mode!
Mirror's Edge is a console port scaling with more than two cores on PC. It even scales quite a bit with a dedicated physx-processor, which means, that there's not too much unused cores left in the system. Now, of course you could fill those remaining cores up with physics calculations, but how to control the amount of processing time? If there's a window breaking into n pieces, then you'd have to have them processed - even more so, if a game should add physics not only for effects but for real gameplay reasons.
You simply cannot sell a PC game running decently only on quad- or octacore machines.
See above. I have difficulties imagining how to effectively control the FLOPS used for physics. The obvious solution would be a slider for the amount of pieces some stuff would break up into, but AFAIK every instance of this slider would have it's own set of pre-tesselated geometry to work on, i.e. pre-defined breaking points.
Not to mention games which use physics for gameplay, which has happened quite rarely until now i admit.
edit:
As to how scalable physics are in Games, just look at the link you've given above: A 9600 GT achieving a mere 10% higher Fps-Performance than the might 8600 GT. Physics does not even scale that well within Nvidias Geforce-GPUs - and there rather with clockrate than with number of cores.
Depends how you look at it. In PhysX games, you don't have to enable the advanced effects (and if you do, a quad-core is useless anyway).
And by the way, what about Supreme Commander? I guess you could say it did not run *decently* on anything slower than quad-cores...