We often get questions such as the one we just received via email:
1) Any idea if you will be supporting AMD/ATI cards in future ?
2) Have you considered OpenCL as a potential pathway for the future ?
I can see an advantage there for you (if it takes off) in that you’re not tied to a single vendor any more and potentially you’d be able to take advantage of other accelerators that may support it.
It’s very early days yet but certainly from our point of view the current paradigm of code to a single vendors card doesn’t seem sustainable..
OpenCL is a community effort to create a standard for parallel computing, with early emphasis on GPGPU computing, in the same way that OpenGL has become a standard for graphics. The main thrust is that people want to be able to have portability across the various vendor chips. All of the major hardware vendors have agreed to the OpenCL standard and the v1.0 spec was recently released.
While there will be many advantages to OpenCL in the future, writing OpenCL code right now does not make much sense. The hardware vendors have yet to build OpenCL compatible lower level tools, drivers, and most importantly for Jacket, scientific computation libraries (such as FFT, linear algebra, etc). It’s going to take some time for the vendors to build those critical elements. While the hardware vendors are building from the lowest levels up, we are building from the highest levels (MATLAB) down. In other words, Jacket essentially takes the lower level libraries and “wraps” them into a highly optimized higher-level system, which does all of the memory management, kernel optimizations, and compile-on-the-fly stuff underneath the hood.
If you want to write GPGPU code today that does any reasonable level of scientific computation, you only have one choice – CUDA by NVIDIA. In comparison, AMD/ATI have only devoted a minimal amount of effort into Brook+. They’re the vendor most likely to want to push towards OpenCL early on and they’ve already made comments to that effect. But in order for OpenCL to work for AMD, they’ll need to build the lower level libraries to make the scientific computations available on their chips. Also, on the horizon is Intel with Larrabee slated for release in late 2009 or early 2010. Intel is doing some cool things with the Ct project, but there’s still a lot to be fleshed out on their toolchain.
Given this landscape, it is therefore straightforward for us to build Jacket in CUDA. In anticipation of OpenCL becoming useful down the road, we have made CUDA a pluggable component of Jacket’s backend system. Therefore, when OpenCL is ready to go (i.e. when both NVIDIA and at least one other hardware vendor actually support OpenCL for scientists), we’ll swap out CUDA for OpenCL, which will then open the door for Jacket users to leverage any OpenCL supported hardware platform.
In the meantime, it just doesn’t make sense for us to spend a bunch of energy porting to OpenCL, when it doesn’t buy us anything in terms of the portability of scientific computation to other vendor’s platforms. And it is key to remember that just supporting basic arithmetic in OpenCL will not be enough to be useful for MATLAB/Jacket users. The vendors will need to build optimized scientific libraries that take advantage of their respective chip designs.
We also expect that Microsoft with push to some sort of DirectX-ish GPGPU/parallel computing language, but that is even less clear right now. So Apple is pushing OpenCL and Microsoft will push something else and we’ll see what ends up being the best solution for everyone. Of course, Jacket users will want support for Windows, Linux, and Mac, so OpenCL is probably better positioned for providing OS portability than the Microsoft alternative.
Hopefully this answers some of the questions that people may have about our plans for supporting multiple vendors via OpenCL. Feel free to comment or make suggestions. We’re happy to entertain thoughts on this. In the end, we just want to put our development resources on the projects that will deliver the most scientific computing benefit to MATLAB users.
Pingback: GPU MATLAB Computing » LAPACK Functions in Jacket (eig, inv, etc.)
Since OpenCL is so close to CUDA, one could think of writing a lang translator for the same..
Moreover, OpenCL does NOT offer true hetergenity in that it does not take advantage of all hetergenous components in the system at run-time….
But then, Jacket too does not worry about multi-gpu, or does it?
Once you have Open CL support things will get…
I just wish not to be hardware constrained.
Thanks for the post.
Pingback: StreamComputing » Blog Archive » nVidia’s CUDA vs OpenCL