You are right – I was not very clear about the ATI Stream brand. I can see that ATIs implementation of OpenCL will be branded and distributed as part of the new ATI Stream SDK 2.0 – and I certainly do not doubt ATIs commitment to support OpenCL.

What I tried to say was, that I don’t think there is room for other APIs than OpenCL and DirectCompute in the future. When I said ’stream’ I was referring to ATIs earlier ‘Close To Metal’ SDK and the ATI Stream SDK 1.4 – which, if I understand it correctly, used yet another GPU language (Brook+).

I have updated the blog entry to make this a bit more clear.

Great piece, even for a non-engineer like myself. Just wanted to point out that ATI Stream is alive and well, not abandoned as indicated in the article. While the move to open source and industry standards is exactly what AMD has supported for GPGPU all along, there is still opportunity for AMD to optimize its drivers and compilers to exploit specific hardware features and help developers produce stronger code. i.e., programmers can \write once\ for OpenCL and then easily compile for different hardware using the vendors’ tools optimized for their platforms. ATI Stream is our brand for hardware and software optimized to leverage those tools and to best take advantage of both the GPU and the CPU, not just GPGPU programming. As the only hardware supplier that offers both CPUs and GPUs, we don’t push developers toward one architecture or another, it’s up to them to decide where their code runs best. Thanks for the opportunity to comment. – Gary

I don’t suspect I’ll be getting involved into low-level GPU programming, though – I’d rather use some higher level libraries, such as for instance the RTfact real-time raytracing library (some screenshots here). I’ve been looking at a few CUDA/OpenCL tutorials and they look a bit hairy to me.