Quote Originally Posted by Farinorco View Post
IMO, the most likely reason holding AMD back from adopting CUDA is the fact of being propietary itself.

If AMD would have adopted CUDA, it would have been probable that CUDA would have been standardized (given the absence of other standards that are starting to appear now.

Then, being a propietary API, everything would be in the hands of their main (only?) competitor:

What if they want to, from a certain version of the API, not allow the use of the latest versions to the competitors, to keep themselves ahead? (Creative and EAX).

The developement of the API would depend only on the criteria of NVIDIA, and they wouldn't have a word on that, also.

Of course, there's what you say about performance, but IMO it would be one of the less problematic here.

There are tons of reasons why AMD isn't interested in a propietary API from it's main competitor becoming the de facto standard for GPGPU, so better if they don't help their enemy to achieve that.

About OpenCL, I have seen them very enthusiastic. They have send a driver to the Kronos group that is approvation pendant (for compliance), even before (little before, I know) than NVIDIA. And the same that NVIDIA, they have a pre-release driver for developers with which you can work. They are not publicising so much as NVIDIA, but they are using it more. They are working with Havok, Bullet Physics and Pixelux, for example, to implement OpenCL. So I don't know how is NVIDIA beating AMD in OpenCL ground.
CUDA is a computing architecture. the API for CAL and CUDA are both just C with extensions so they are really both proprietary. the API must have a compiler for both architectures. CUDA is not something you just port to another gpu. there would be really no point because they are the same thing.