One of the more interesting aspects to the GPU computing craze is the diversity of solutions that are emerging from the chip vendors. NVIDIA is currently out in front of the pack with its CUDA-architected Tesla GPUs, purpose-built for HPC. Intel, with the reintroduction of its Larrabee technology (now known as the “Many Integrated Core” (MIC) architecture), is pursuing the un-GPU model of data parallel computing. That leaves AMD, with its dual path of FireStream GPUs for “stream computing” and CPU-GPU Fusion technology for everything else.

But its the Fusion technology that sets AMD apart from its chip-making rivals. Because of the 2006 acquisition of ATI, the company stands alone as the processor vendor with mature technologies for both CPUs and GPUs. This makes the integration of the two architectures onto the same piece of silicon a natural fit for the company.

AMD, of course, was looking to exploit that advantage from the start. They originally planned to push out the first Fusion parts in 2009, but the complexity of folding ATI into the company and the subsequent recession slowed down the effort considerably, delaying the roadmap for two years. AMD is only now gearing up to launch its first Fusion processors, also known as Accelerated Processing Units (APUs), sometime in 2011.

These first CPU-GPU products are aimed at the desktop and laptop market to improve the visual computing experience for PC users (mostly via Microsoft’s DirectX framework). But technical computing users are starting to look at the Fusion architecture as a way to bring GPU-style parallel processing much closer to the CPU.

To date, all serious GPU computing is being done on relatively high-end discrete graphics processors that are hooked up to a host CPU system via a PCI-express (PCIe) link. This is the case for both NVIDIA’s and AMD’s GPU computing products — Tesla and FireStream, respectively. Although some HPC applications have recorded performance gains on the order on of 10X to 1,000X, the overhead of shuttling data back and forth across the PCIe link and the clunky software used to support this model suggests that off-chip acceleration is just the first chapter of the GPU computing story.

Last week, Northeastern University, in Boston, held an academic research day for GPU computing to get the word out about how it’s being used for technical computing applications in the research community. The event was organized in conjunction with AMD’s External Research Office as part of an outreach to the other academicians, and to put forth the company’s vision of heterogeneous computing as well as its upcoming CPU-GPU products. HPCwire spoke with Dave Kaeli, the director of the Northeastern University’s Computer Architecture Research Laboratory, who gave the event’s opening talk on “Exploiting Heterogeneous CPUs/GPUs,” in which he talked about some of his experiences with the technology.

Much of Kaeli’s work is focused on using GPUs for biomedical imaging applications — work that is being funded by the NSF and by AMD itself. There are two classes of problems he’s working on. The first is for image-guided biopsies, where real-time visual processing and high data bandwidth are the principal requirements. The other is for the digital reconstruction of a single image, which can take on the order of tens of hours — certainly not real-time, but time-critical for certain medical scenarios.

In the latter case, Kaeli is using an ATI Radeon 5870 GPU, which boasts a raw performance of 2.72 teraflops (single precision floating point). Compared to a CPU-only implementation, an order of magnitude speed-up is possible for this type of image reconstruction. Detection of breast cancer and coronary blockage are two of the main applications here, and in this case, the patient goes home and then returns later for a second consultation. The reduced turnaround time has the potential to produce better outcomes as well as reduce costs.

Some of Kaeli’s effort has gone toward developing GPU-based biomedical imaging libraries in OpenCL, an open language standard for parallel processing across GPUs and CPUs. He says the work has reached the point where they’re now engaged with a major medical equipment manufacturer to help design the company’s next-generation ultrasound devices. The plan is to incorporate GPUs to support very high-resolution 3D ultrasound in a portable, low-power device.

Currently, the medical manufacturer is using a combination of FPGAs and DSPs for this class of device. Not only does that design stretch the power envelop for a mobile platform, but the lack of a commodity-driven solution makes the upgrade path problematic. Being able to write the application in a language like OpenCL, which is portable across multiple silicon generations (not to mention chip vendors), is a much more attractive proposition for manufacturers.

Initially the ultrasound appliance will be equipped with a discrete GPU, with the idea of migrating to a CPU-GPU processor later on. “The whole idea of moving from a high performance graphics card to an embedded GPU to a hybrid, heterogeneous Fusion chip is a very attractive in that domain,” explains Kaeli. “It’s really why we’re so engaged with AMD at this point. We recognize that they are providing leadership in this particular area right now.”

Kaeli says heterogeneous processing presents a lot of attractive features, both in terms of ease of coding and from a power-performance standpoint. On the power usage side, the benefits of CPU-GPU integration extends across both traditional and technical computing applications. For scientific codes though, the current process technology (45 nm) limits the size of the GPU that can fit on the same die as the CPU, and thus the ultimate performance of the chip. But as Moore’s Law works its magic, a very respectable-sized GPU will be able to be share the die with a CPU.

From a programmer’s point of view, having the CPU and GPU sharing the same RAM is a big improvement from the split memory model with discrete devices. And the latency associated with passing data back and forth between two separate devices is much better (i.e., lower) when the CPU and GPU are on the same die. This is especially true for real-time embedded applications, where latency is particularly critical.

Kaeli is also involved with a surgical simulator application for training doctors. In this case, finite element analysis (FEA) is used to simulate blood flow, cutting, skin tension, and so on. “We can’t do all of that on a GPU,” says Kaeli. “A lot of that has to be done on the CPU.”

Besides biomedical image research and other medical applications, Kaeli is involved with GPU compiler work, developing techniques for efficient mapping of algorithms onto GPUs, and looking at virtualization technology that leverages multiple GPUs. His group is also researching cross compilers that can take CUDA applications for NVIDIA GPUs and convert the source code to OpenCL. “We actually have working examples of that already,” he says.