I'm well aware of the application of GPUs for general computing purposes. However, GPU programming involves several layers of abstraction, and that's why I refer to anything using PhysX or CUDA as software, running on top of the GPU HW.
Right, and none of the other HW supports DX11, DX10 or OpenCL either. So when I hear NV mention DX11 or OpenCL, it's obvious to me they're referring to video cards. If Ati were going to support the PhysX API on their GPU's, they'd still have to do the hard part of making it work on their HW with their own drivers, so what benefit would they have from adopting NV's standard as opposed to some other API which isn't owned by a competitor?
AMD CPU's just happen to support the same instruction set as Intel CPU's. The Ati and Nvidia GPU's are much more different architecturally.
We are not talking about CPU physics, for which there are at least a dozen alternatives to Nvidia's PhysX. With regard to Ati running PhysX, it specifically means GPU-accelerated physics. And NV continues to push the adoption and development of CUDA using PhysX as leverage. You think it's purely a coincidence that PhysX is owned by NV and just happens to require CUDA on the GPU?
OpenCL is owned by the Khronos Group, in which Ati, NV, Intel and numerous other companies have a stake. Any similarities to CUDA are inconsequential, just like any similarities between Cg and GLSL. And until the open standard is adopted, it doesn't make it any more beneficial for Ati to adopt NV's proprietary standards.
Because with OpenCL all those apps would run on their AND their competitor's HW, whereas CUDA only runs on NV HW.
Statistics can be bent to show just about anything, not to mention it's irrelevant to the discussion.
Why should Ati support CUDA when it's owned by NV? Ati didn't adopt Cg, and they got along just fine because the market shifted towards cross-platform standards. The same thing will happen with physics and CUDA.
Wreckage
Banned
- Jul 1, 2005
- 5,529
- 0
- 0
This thread is about GPU physics. Given that PhysX is much more mature, it probably would have been easier to get PhysX running on ATI cards than Havok.
I think this is just a PR stunt really.
I think Havok will remain limited to the CPU in any game coming out over the next 2 years.
Maybe after Larrabee launches things will change.
Havok is owned by Intel.
Modelworks
Lifer
- Feb 22, 2007
- 16,240
- 7
- 76
I think something people are not understanding about Havok is that it is not just physics. Havok works best as a package covering animation, AI, behavior and physics. If I am working on a project and I use PhysX for the physics I still would need Havok for the AI , behavior and animation. I then have to deal with two API instead of one and also work out how to pass the information between the two. Or I can just use Havok from the start where everything was designed to work together. It is much easier for the developer.
Originally posted by: Wreckage
This thread is about GPU physics. Given that PhysX is much more mature, it probably would have been easier to get PhysX running on ATI cards than Havok.
I think this is just a PR stunt really.
I think Havok will remain limited to the CPU in any game coming out over the next 2 years.
Maybe after Larrabee launches things will change.
Havok is owned by Intel.
This thread is about GPU physics. Intel is not trying to push Havok as a means of furthering its own GPGPU business, because they have no appropriate HW, and Havok does not rely on proprietary abstraction layers, the way PhysX relies on CUDA.
Where exactly can one buy a Larabee GPU? Nowhere! In how many game titles does Intel promote Havok as a means of boosting Larabee sales? None!
On the GPU it DOES. Futhermore, I put my previous post in one sentence for a reason, not to be conveniently split up to obfuscate the big picture.
Don't refer me to non-existent technologies. Intel is nowhere as big of a threat to Ati right now as Nvidia.
Nvidia GPU is the ONLY GPU it's supported on. Wii does not run PhysX on the GPU.
And so can Havok, or a number of any other physics API.
Isn't what munky said true? Even if Wii has PhysX it wouldn't be running on the GPU would it? The ironic thing is that it's an ATI GPU.
I don't think you guys are seeing the big picture. GPGPU and GPU physics are still in their infancy at this point. Whatever technology gets a head start in this early stage can potentially make a huge impact on the future of all companies involved. Nvidia has the advantage of owning both the HW and SW to their GPGPU solution, which they are trying to leverage as much as possible. That's why they are supposedly "offering" PhysX and CUDA to Ati, because if CUDA could emerge as the dominant SW solution, it would be a huge advantage to NV, which they in turn could leverage to drive their HW sales. Preventing CUDA from gaining widespread acceptance is of much more importance for the future of ATI/AMD than whatever temporary benefit they might get from adopting it.
Imagine if Microsoft and Intel merged 20 years ago... Anyone think that things would be a lot more "unpleasant" right now if that happened? How would it affect Intel's competitors, like AMD? How would it affect the consumer in general? What you're seeing now with GPGPU is the next wave of technological progress. It makes perfect sense to me why NV is offering PhysX/CUDA to its competitors, and also why the competitors are refusing the bait.
Imagine if Microsoft and Intel merged 20 years ago... Anyone think that things would be a lot more "unpleasant" right now if that happened? How would it affect Intel's competitors, like AMD? How would it affect the consumer in general? What you're seeing now with GPGPU is the next wave of technological progress. It makes perfect sense to me why NV is offering PhysX/CUDA to its competitors, and also why the competitors are refusing the bait.
SunnyD
Belgian Waffler
Being that the Wii uses a revised ATI Hollywood GPU, I'd be willing to say that's about a 110% correct assessment.
In fact, the Wii GPU is not much different from the old GameCube GPU, and there's no way you'd be running PhysX on it.
No we're not talking about CPU physics, it just drives home a fundamental point you consistently fail to recognize despite mounds of evidence supporting the fact: PhysX be it GPU/CPU/PPU, hardware, software, middleware, Nvidia, AMD, Intel does not rely on CUDA in any way, shape or form. You claim to understand the differences between software, APIs and abstract layers, yet you cling to this piece of misinformation as if its true or meaningful, when its not.
LOL @ any similarities being inconsequential. Its probably not an accident given Nvidia's SW team probably wrote most of the code:
- OpenCL for NVIDIA
OpenCL (Open Computing Language) is a new heterogeneous computing environment, that runs on the CUDA architecture. It will allow developers to harness the massive parallel computing power of NVIDIA GPU?s to create compelling computing applications.
In partnership with NVIDIA, OpenCL was submitted to Khronos by Apple in the summer of 2008 with the goal of forging a cross platform environment for GPU computing. NVIDIA chairs the OpenCL working group with direct support from NVIDIA?s SW engineering team. The SIGGRAPH ASIA Khronos OpenCL presentation by Neil Trevett of NVIDIA can be found here.
Given the other links, facts and evidence have gone ignored I doubt any of this will deter you from continuing to insist GPU PhysX is strictly tied to CUDA and Nvidia hardware only, when its not. As has been shown numerous times, its AMD's decision to cripple their parts with regard to PhysX and always has been.
And they wouldn't care, as they'd be confident their HW runs that software faster than their competitor's HW. When you're eating 60-70% of the pie, you don't care that you have to share, you only care that the pie gets bigger. This all goes back to Jensen's multiple statements about Nvidia and Intel's "battle for the soul of the PC".......
Right, and in this case statistics show Nvidia dominates market share with GPU physics-capable parts and has a fully functional API and middleware that takes advantage of that hardware, making it completely relevant to the discussion.
Again, its not about CUDA, as Nvidia and ATI have both claimed they will be compliant with common ground "industry standards" like DX11 and OpenCL. Its about ATI being deliberately deceitful with regards to their reasons for not supporting PhysX.
I don't have a problem with ATI saying they're not going to back PhysX because they don't want to support their direct competitor. But I'm also not going to let them hide behind a BS excuse about not wanting to support "closed and proprietary standards" and excuses like "when it makes sense" to deflect blame away from themselves as to why they're not supporting features and functionality their parts are fully capable of.
PhysX on the GPU does require CUDA, don't mix it up with other implementations on the PPU/CPU. I dare you to try and run a GPU-PhysX app on an Nvidia video card without having the appropriate CUDA drivers. Go ahead and report what happens.
LOL, again, simple question for you, if CUDA did not exist, do you think Nvidia would be able to accelerate PhysX on their GPU? Simple question, yes or no. If the answer is yes, then PhysX does not rely on CUDA. Its that simple. Its been shown and proven on both the CPU and PPU, PhysX has numerous back end solvers that can easily be interchanged as needed with whatever platform-specific or industry standard API.
CUDA is simply the C-based programming language Nvidia created in the absence of a suitable alternative. If OpenCL or DirectX11 preceded CUDA, there would be no need for CUDA as both standard API are compatible with Nvidia's DX10 hardware. Just as they're compatible with ATI's DX10 hardware. For someone who claims to understand these simple relationships this should be easy enough to digest.
You need to be careful with comments in made to the press about allowing "anyone" to support PhysX with any actual meaningful approach to doing what has been said.
However, to just dismiss the open standard path we are taking is wrong. If NVIDIA were serious about having other GPU vendors support CUDA then this would have been a much quicker path to take - but because of the open standards nature that we have we've taken a much longer term approach to this; during the period that we announced that we were working with Havok OpenCL was still going through work group, had to be ratified and then we have to create the SDK to enable it (which we are still doing).
Also, I see in this topic the proclamation that this is "Only about GPU Physics", well, actually it?s not, now. OpenCL is designed as a true heterogeneous compute API and hence the movement here is about creating an environment that puts the best processor device to the requirements of the processing task at hand; and, additionally, automatically shifting that balance dependant on the processing devices in any particular system. When you only have a Hammer, everything looks like a nail - fortunately AMD has more tools in the box.
No its not. "C for CUDA" is that. CUDA is a software stack that allows access to their hardware. The CUDA Driver model is more low level and more commonly used - this is specific to their hardware and likely the way PhysX gets to NVIDIA's hardware.
PhysX on (nVidia's) GPU(s) uses CUDA because nVidia wanted to use that.
As chizow is trying to say, suppose nVidia had PhysX in their pocket but hadn't created CUDA yet. They'd just have to use something else instead.
If ATi were to use PhysX, they would most likely use their "CUDA equivalent" called Stream.
PhysX is only tied to CUDA if you are discussing nVidia hardware (exclusively) stemming from the GeForce 8 series and higher.
So you admit that Nvidia intentionally tied GPU-PhysX to CUDA. Which perfectly explains why Ati refuses to support it in its current state. There are reasons for these things that go beyond your technically-oriented tunnel vision.
Which is exactly the way it's implemented right now, and how I would've done it if I was in charge of NV. There's no technical reason why GPU-PhysX should require CUDA, but at the moment it does, which explains why Ati refuses to support it.
Sweet, Dave Baumann folks, product manager for AMD's GPG division, maybe we'll get some straight answers now.
If you're referring to the NGO HQ/Badit articles, I can understand wanting to control development for quality control or branding reasons, however, the associated comments from AMD/Godfrey Cheng don't convey that point, they deflect blame toward Nvidia for promoting a closed and proprietary standard when their solution is really no different than AMD's preferred solution with Havok + Stream/Brook/OpenCL.
I can also understand wanting to support an open industry standard, yet you surely didn't expect Nvidia to wait around if they had a viable alternative, did you? Not to mention they've made all required tools for AMD to make their parts compatible with PhysX long before OpenCL was ratified.
CUDA download
PhysX SDK Download
Certainly more available than Havok, which won't even allow you to demo without authorization, or OpenCL, which again was only ratified a few months ago and only available to registered members.
Now for what-ifs. Now that ATI has demonstrated a GPU accelerated OpenCL Havok client based on an industry standard, when will we see it in production? What will ATI's response be if Nvidia also supports hardware accelerated Havok? If Nvidia supports Havok on their GPUs, will ATI support PhysX on their GPUs? Any answers would be appreciated thanks.
TRENDING THREADS
-
Discussion Zen 5 Speculation (EPYC Turin and Strix Point/Granite Ridge - Ryzen 9000)- Started by DisEnchantment
- Replies: 25K
-
Discussion Intel Meteor, Arrow, Lunar & Panther Lakes + WCL Discussion Threads
- Started by Tigerick
- Replies: 22K
-
News NVIDIA and Intel to Develop AI Infrastructure and Personal Computing Products- Started by poke01
- Replies: 384
-
Discussion Intel current and future Lakes & Rapids thread- Started by TheF34RChannel
- Replies: 23K
Facebook
Twitter