ATI, owned by AMD, has come out with a fantastic SDK that allows developers to port floating point operations and basic number computation to the highly suited Radeon GPU. These GPUs operate in a very parallel nature, the acronym they use is SIMD (single instruction, multiple data items). The point being that if you need to do a single operation to a large array (say matrix multiplication on two matrices of size 12 x 10 and 9 x 15 for instance) why do that on your logic based single, dual, quad, or if your really on the bleeding edge octo core CPU system, when you can do the same thing on you GPU that will do it with tens, hundreds, or on the real high end stuff thousands of parallel threads. The performance gains become pretty obvious to see when you compare a single digit number of threads to the tremendous power of GPU arithmetic computation.

The basis of the SDK falls on Brook+, an extension of the C programing language developed by Stanford University to give easier access to CPU GPU level operations. What AMD is distributing is basically a compiler for a language made specifically to boil relatively complex arithmetic operations down into simple instructions (referred to as kernels) that can be executed in parallel on the GPU. This then utilizes the “compute abstraction layer” (CAL) which is basically hiding all of the GPU specific instructions, so that the developer only has to learn C/C++ and the additions brought by Brook+, and not ATI’s proprietary instruction language as well (something they probably don’t want to release anyway).

To anyone that has spent much time looking into Microsoft’s .NET development environment this all starts to sound pretty familiar, a complex base that is simplified to increase usability and portability across development environments, but the one thing that I haven’t talked about yet that .NET and ATI Stream depend upon is intermediate language, the last layer of programming that AMD is giving developers access to with their SDK. This is also the realm that will be occupied solely by the masochistic type of people that have to try and get two more megaflops out out their GPU when you’re already talking about gigaflops, but since AMD had to develop this language to make everything work to begin with I guess it doesn’t hurt for them to release it to the public.

So I’ve thrown out some jargon and tried at least to make it sound like I know what the hell I’m talking about, but what does this really mean to the average user? Well that depends on how often you do a large amount of similar arithmetic calculations. If you don’t think you do any then you’re probably wrong. A plug in exists today to make Adobe Premier CS4 significantly faster because encoding video requires a ton of arithmetic operations. In fact pretty much all of the CS 4 creative suite could benefit from Stream processing. Also converting video for play on mobile devices is good use that I see in the near future. Accounting software, especially the type used for corporate taxes, could see an advantage if you’re talking about a lot of tax files. I could go on, but really the only limit to the realm of usefulness of this technology is the developers willingness to utilize the SDK. Hopefully this will go along with multi threading and become a very standard thing for programs that can see a performance boost out of it.

Linky goodness:

AMD/ATI Stream Computing FAQ’s: http://forums.amd.com/devforum/messageview.cfm?catid=328&threadid=95060&enterthread=y

AMD authored whitepaper: http://ati.amd.com/technology/streamcomputing/firestream-sdk-whitepaper.pdf

Stream Computing Overview: http://developer.amd.com/gpu_assets/Stream_Computing_Overview.pdf

More information on Brook+ that you could ever want: http://graphics.stanford.edu/papers/brookgpu/brookgpu.pdf

AMD, ATI, brook, computer computation, GPU, high speed, parallel, Radeon, sdk, Stream Hide