For various obvious or less obvious reasons (I'm no programmer so I don't know that much) it's not as straightforward, well documentated or as easy to work with OpenCL as with CUDA.
The reasons are actually almost entirely marketing driven.
Nvidia pushed CUDA very hard, and paid out
millions of dollars to developers (in both direct cash payments, and in support costs) to "promote" its use. By the way, CUDA is not really a "technology" in the classic sense of the term, but a broad marketing term for a collection of programming interfaces designed to work with Nvidia GPUs. The goal of this marketing move was simple: drive adoption of CUDA (a proprietary "language") which requires their GPUs. Then CUDA support would be a viable "value-add" for their GPUs, which would allow them to market them to consumers more effectively (you can't use that AMD card, even if it is faster/better/cheaper, because it doesn't support CUDA). AMD has a similar "product" called Stream Computing, but they aren't "pushing" quite the same thing.
Apple, AMD, and Intel (along with a variety of other companies) are pushing an interoperable GPGPU programming standard
called OpenCL (while Microsoft is pushing DirectCompute). These systems all do essentially the same thing, they allow the programmer to access the massive parallel computational resources available on modern GPUs and multi-core CPUs. However, with less "skin in the game" they didn't market the technologies as directly, or with as much money or support (OpenCL got "support" from Apple by them designing it and building it into their OS). Therefore, adoption by third-party developers (particularly smaller ones) has been slower. However, OpenCL was actually developed by Apple
along with Nvidia. It is absolutely based on CUDA, and can sort-of be viewed as a CUDA+ that can run on a much wider variety of hardware (and isn't artificially limited on multicore CPUs like CUDA-proper for marketing reasons).
There are certainly some advantages to the current CUDA approach. However, there are some huge advantages to developing interoperable code, and new C++ programming interfaces are coming around the bend. And, because CUDA did NOT get the kind of massive adoption that Nvidia was looking for (I think mainly because Fermi was underperforming and terribly power hungry with the first release), Nvidia has dramatically reduced the amount of money they're dumping into that hole for now. CUDA never caught on like wildfire like they'd been hoping, and, frankly, Sandy Bridge is so powerful that you really don't need the GPU acceleration for most things (and when you get right down to it, current GPUs are still not perfectly suited to GPGPU style usage).
Interoperable GPGPU APIs are
almost certainly the future (as is a unified memory address space, one of the biggest problems with current GPUs for general purpose programming).
Author
Topic: Power Consumption: Red October Standard vs HQ (with LAV CUVID) (Read 9637 times)