AMD Backs OpenCL, Microsoft DirectX 11
Advanced Micro Devices is throwing its weight behind both the OpenCL programming language and Microsoft's upcoming DirectX 11 APIs for use with its line of general-purpose graphics processing units.
AMD, which announced official support for both OpenCL and DirectX 11 on Aug. 6, will begin upgrading its Stream SDK (software development kit) during the next 18 months to help developers take advantage of GPU acceleration when building new types of applications. In the enterprise, this could mean applications for HPC (high-performance computing), or for commercial uses such as games that require three-dimensional graphics rendering.
On the chip side, AMD is working toward combing a CPU and a GPU on the same piece of silicon in a project called Accelerated Computing. This move was a major reason behind the company's purchase of ATI in 2006, which has drained AMD financially. AMD has also recently released a GPU called the FireStream 9250, which is specially built for the HPC market.
The news of AMD's support for OpenCL and DirectX 11 comes in the same week that Intel pulled back the curtain on its much-anticipated "Larrabee" processor, which Intel plans to release in either 2009 or 2010 as a discrete graphics processor that uses x86 processing cores with an optimized architecture to handle graphics.
Intel is looking to make it easier for application developers to write software for Larrabee, whether that software is for games or HPC, by manufacturing a chip that uses a much more familiar x86 instructional set along with the C and C++ programming languages. Intel is also supporting Microsoft's DirectX and OpenGL APIs.
The efforts by Intel and AMD show the importance that both companies are placing on graphics as a way to enhance computing in the next few years, while taking advantage of a GPU's ability to break complex problems into parallel in order to solve them. IBM is already showing how this can be done with its Roadrunner supercomputer, which uses Cell processors as accelerators for the most complex problems while standard AMD Opteron chips handle the everyday computing tasks.
At the same time, Nvidia is pushing for developers to adopt its own programming language, called CUDA (Compute Unified Device Architecture), which is a C compiler and a set of tools that allow a developer to program a GPU like a CPU. When Nvidia announced its Tesla GPU in June, the company also announced plans to offer a 2.0 version of CUDA.
John Spooner, an analyst with Technology Business Research, said Intel, Nvidia and AMD are each pushing a programming language that best fits with that company's own technological roots.
For example, Intel is pushing x86 because it's what Intel does best and there is also a large base of Intel chip architecture already in the market. Nvidia, on the other hand, is pushing CUDA for the GPGPU market. Programmers are familiar with CUDA and it also has the capabilities to handle Nvidia's latest GPU offerings.
At the same time, AMD is looking to offer a third way to program and take advantage of its vision for a GPGPU. An article in TGDaily suggests that programmers are starting to ask for support for OpenCL, which should give AMD's approach some additional momentum.
"AMD's approach is very similar to what it has done in the past," Spooner said. "I don't see a major departure for any of these companies in their approach. However, I do think it signals a change in the industry, and with large and highly capable graphics processing [technology] coming out in the near future, these companies are jostling to get developers to back their platforms."
While this current approach means an array of options for developers to choose from, it also means that there might be some concerns among programmers about which one to pick and what will happen if the approach they do choose turns out not to be successful. In this case, Spooner said there might be a call for a common language, but Nvidia, AMD and Intel are all developing different chip architectures at this point, which requires different programming approaches.