As far as technology maturity goes, GPGPU (general-purpose computing on graphics processing units) is just a baby. But there’s already an effort underway to produce an industry standard for this new programming model: OpenCL. With people still kicking the tires on NVIDIA’s CUDA and AMD’s Brook+ GPU programming languages, the effort to come up with a vendor-independent way to access GPUs for computing might seem premature. It isn’t.

For one thing, OpenCL’s ultimate purpose is broader than just GPGPU. It’s real goal is to define a standard low-level API for a whole range of parallel architectures, including GPUs, multicore CPUs, the Cell processor, Larrabee, and DSPs. In fact, OpenCL stands for Open Computing Language, which is about as broad as it gets. The standard will impose some requirements on the hardware, such as the presence of floating-point support (which leaves out integer-only DSPs) and dynamic control flow (which leaves out pure SIMD processors, like ClearSpeed*). But the fact that the OpenCL working group includes the biggest players in chip making — Intel, AMD, NVIDIA, IBM, Motorola, Texas Instruments, and others — suggests that the standard will enjoy broad industry support.

Apple Computer initiated the work in an effort to find a way to extract computing performance out of GPUs and multicore CPUs in an architecture-independent way. In June 2008, the company turned over the project to the Khronos Group, an industry consortium that develops and maintains open standard, royalty-free APIs, primarily at the level of the hardware-software interface. Up until now, the consortium has been mostly focused in the graphics and media realms. OpenGL is perhaps the most well-known API in this regard. With OpenCL, Khronos has taken on a much more general-purpose standard.

“From the get-go OpenCL is intended to address both high-end systems, mobile and embedded devices,” explains Khronos President Neil Trevett, whose day job is VP for the embedded mobile group at NVIDIA. OpenCL could certainly be welcome news for HPC developers considering a long term strategy with GPUs and other accelerators but wary about getting locked into proprietary hardware or software stacks. Trevett also sees a great deal of opportunity for OpenCL-enabled devices in the handheld space, where the next generation of GPUs and DSP can be used for mobile supercomputing.

Compute-intensive applications such as image processing, augmented reality, and location recognition are already on the drawing boards of a number of cell phone makers. The missing piece is tapping into the GPU and DSP processors for general-purpose computing. An API standard seems especially important to this market since the hardware moves very rapidly in the consumer handheld space. By establishing a foundational layer, OpenCL will help preserve software investments and enable platform independent applications and libraries to be developed.

But if OpenCL succeeds, what will become of proprietary solutions like CUDA and Brook+? Wearing his NVIDIA hat, Trevett says his company is fully supportive of the OpenCL effort and they’re going to be careful not to set up CUDA as an OpenCL competitor. He says the two platforms offer essentially the same level of interface, and as far as they’re concerned, the more ways the programming community is able to get to parallel processing goodness, the better it will be for all the players. AMD, likewise, was an early OpenCL advocate and is committed to supporting an implementation on its “stream computing” processors.

The presence of IBM and Intel in the OpenCL working group suggests that implementations for Cell and Larrabee, respectively, are in the works. Another OpenCL member, RapidMind, is looking forward to being able to use a common API for its parallel programming platform, which essentially offers a high-level programming environment that can be layered on top of OpenCL. According to RapidMind Chief Scientist Michael McCool, one of the nice side effects of the upcoming standard will be to establish a minimum set of requirements for processors, such that new hardware will be designed with the OpenCL specs in mind.

Version 1.0 of OpenCL is currently scheduled to be released in early December at SIGGRAPH Asia 2008 in Singapore. If they succeed, that’s got to be some kind of industry spec development record — basically from prototype to final in 6 months. I think the IEEE study group that was working on the 40/100 Gbps Ethernet standards took that long just to decide on the seating arrangement. Kidding aside, I suspect the rapid gestation of OpenCL has something to do with the members’ motivation to get these standards in place and with the running start the project got from Apple.

Although the spec won’t be ready in time for SC08, the Khronos groupies are presenting an OpenCL technical briefing and reception at the event on Monday, November 17, to bring people up to speed. If you’re interested, check out http://www.khronos.org/news/events/detail/opencl_sc08/. Appetizers and cold beer will be provided!

*ClearSpeed reports that they do, in fact, support dynamic flow control, saying they “have multiple mechanisms that enable either pure dynamic flow control or predicated execution of instructions.” The company believes that their are no significant barriers to supporting OpenCL on ClearSpeed hardware and it is possible that the recently announced CSPX API could be contributed to the OpenCL working group as a potentially very useful layer for users who wish to scale their applications to use multiple accelerators in a single system. Although ClearSpeed is not currently a member of the OpenCL working group, they are “in the process of engaging with the Khronos Group and the OpenCL activity,” adding: “We have always endorsed the position that what the users and suppliers of heterogeneous acceleration need is an open standard as opposed to a proliferation of proprietary or third party solutions.”