Nearly 6 months after the creation of a work group to develop OpenCL, it has now been ratified by Khronos. As you know, OpenCL (Open Compute Language) is an API designed for massively parallel processing. Its development was initiated by Apple. The Khronos group is a consortium of industry leaders which develops open APIs such as OpenGL.
As you probably now know, GPUs can be used as massively parallel processing units, with CUDA in the NVIDIA camp and Brook+/CAL for AMD. These proprietary APIs create a compatibility problem because a CUDA application won’t work on a Radeon and a Brook+ app won’t work on a GeForce. Apple therefore initiated OpenCL so as to facilite the use of GPU power without being locked in to a range of products from a particular manufacturer (NVIDIA). OpenCL then can be seen as an API designed to standardise this. As always, the reality is more complex. Hence the reason for this little article.
OpenCL versus CUDA?
This is the question many people are asking as CUDA is currently the most-often cited GPU computing API. OpenCL has not however been designed to compete with CUDA. To understand this you need to remind yourself what CUDA actually is: an architecture designed for massively parallel processing. NVIDIA developed an API for it, “CUDA for C”, a point worth remembering because people tend to speak about CUDA both for the architecture and the proprietary API.
CUDA compatible cards (GeForce, Quadro, Tesla) all support both CUDA for C and OpenCL. The same goes for Stream cards (Radeon, FireGL, Firestream) which support both Brook+ and OpenCL. OpenCL, then, is a common language for any architecture. It hasn’t only been designed for GPUs but is also adapted to CPUs and accelerators such as Cell. Does this mean that you can now develop a code that’s compatible wih any architecture? This is where it gets more complicated. In fact, the work group in charge of OpenCL, which includes among others, Apple, AMD, Intel, NVIDIA and Sony, decided to go for a support of all the specificities of each architecture rather than easing porting…
