GPUs are becoming more like CPUs. But in the critical area of error corrected memory, graphics hardware still lags. The lack of error correction is probably the single biggest factor that makes users of GPUs for high performance computing nervous. Some HPC applications are resistant to the occasional bad data value, but many are not. The good news is that graphics chip vendors are aware of the problem and it appears to be only a matter of time before GPUs get a memory makeover.

Before AMD and NVIDIA brought GPU computing onto the scene, graphics processors didn't really need to be concerned with error-prone memory. If a pixel's color is off by a bit or two, nobody is going to notice as the images go flying by. So it was natural (and cheaper) for GPU devices to be built without support for error corrected memory. In 2006, with the advent of general-purpose computing on graphics processing units, otherwise know as GPGPU, the issue of reliable memory came to the fore.

The problem is that when you're using the GPU as a math accelerator and a memory bit flips in a data value, you've got a potential problem. Obviously in numerical calculations, accuracy matters. That's why all standard CPU servers today come with memory that supports Error Correcting Codes (ECC) as well as with on-chip intelligence for error checking and correction in cache and local data structures. The reason that general-purpose computing can be done on GPUs at all has to do with the relatively infrequent occurrence of these errors on standard graphics hardware. Algorithms are typically run many times in a typical technical computing application, so anomalous results can be averaged out, or even manually discarded.

The only simple way to circumvent the problem on the current crop of GPUs is to run the code twice (or simultaneously on two separate devices). If the results don't match, you assume an error occurred and you rerun the offending sequence. It's relatively bulletproof, but you've cut your price-performance in half for the sake of error correction. A less brute-force method was devised by the Tokyo Institute of Technology, who came up with software-based ECC for GPUs (PDF). But the preliminary results showed the performance overhead was acceptable only for compute-intensive applications, not bandwidth-intensive ones.

There are different categories of memory errors. The kind most people focus on are thought to be the result of cosmic rays, alpha particles in packaging material, or possibly as a side-effect of harsh environmental conditions. They are called soft (or transient) errors and most commonly occur in off-chip DRAM, but can also strike the GPU ASIC itself in local memory or data registers.

Hard (or permanent) errors can also be present on memory chips, but these are easy to detect with simple diagnostic tests. Hard errors are usually dealt with by replacing the offending memory module, but theoretically could be handled in software too. The conventional wisdom is that soft errors are much more common than hard errors, although at least one study (PDF) by Google found just the opposite.

Data errors can also occur at the memory bus interface. Here, at least, the graphics world has made some progress. GDDR5 (Graphics Double Data Rate, version 5) memory, which first appeared in 2008, was the first memory specification for graphics platforms that contained an error detection facility. The motivation behind this was the high data rates of GDDR5, which made the odds of producing bad data much more likely. Since GDDR5 contains an error correction protocol, a compatible memory controller is able to take corrective action -- basically a retry -- to compensate.

That still leaves a lot of data on the GPU board exposed. Adding ECC memory to GPU boards intended for the technical computing market is a relatively straightforward product decision since the extra cost can be passed on to the GPGPU consumer. But changing the GPU core as well as the integrated memory controller to complete the protection requires a tradeoff, since extra transistors are needed for error detection and correction on the ASIC. And because of the expense of designing and testing chips, GPUs are shared across product lines at AMD and NVIDIA.

For example, the latest AMD FireStream products use the Radeon HD 4800 core, while the current NVIDIA Tesla platforms uses (presumably) the GeForce GTX 285. These are the same ASICs used in high-end graphics products. The challenge to the two GPGPU vendors is to figure out how to design processors that offer the data reliability of a CPU server, without impacting their core graphics business unduly.

Patricia Harrell, AMD's director of Stream Computing, admits that the need for more robust data protection in GPUs already exists. She says error corrected memory is a requirement for a number of customers, especially those looking to deploy GPUs at scale, i.e., high performance computing users with large compute clusters. Although individual memory error rates are low, as you add more GPUs (and thus more graphics memory) to the system, and run applications for longer periods of time, the chances of hitting a flipped memory bit increases proportionally.

The AMD FireStream 9270 board already incorporates GDDR5 memory, so data protection is already in place at the memory interface in this product. In this case, whenever the memory controller sends and receives data to and from the DRAM, it buffers the data locally while the DRAM calculates the integrity of the value and returns a status code. If the code indicates an error, the memory controller does the retry automatically.

Overall though, AMD seems to be taking a cautious approach to error correcting GPUs. "It's really important to put in the required features intelligently, and make sure you do the research and engineering to protect the data structures that are going to return the most value," notes Harrell. If not, she says, you end up with devices that are too big and too hot, in which case you lose the performance advantages GPGPU was originally intended for.

Harrell says that they are continuing to look at the memory protection issue, but couldn't offer more specific guidance on AMD's roadmap. "I think it isn't clear if that [error correction] is going to be required for the broad market yet," she adds.

Unlike AMD's more wait-and-see attitude, NVIDIA appears to be fully committed to bringing error protection to GPU computing. According to Andy Keane, general manager of the GPU computing business unit at NVIDIA, it is not a matter of if, but when. From his point of view, ECC memory is a hard requirement in datacenters. "We have to respond to that by building that kind of support into our roadmap," Keane said unequivocally. "It will be in a future GPU."

As far as when ECC-capable Tesla products will show up, Keane wouldn't say. It's likely that NVIDIA's OEM partners and GPU computing developers already have a pretty good idea of the timeline (under NDA of course), so systems and software based on high-integrity GPUs may already be in the works. In a Real World Technologies article that spells out the major costs and benefits of error corrected memory in GPUs, analyst David Kanter predicts that NVIDIA's next GPGPU product release will include ECC.

Presumably Intel is also mulling over its options, since Larrabee, the company's first high-end graphics processor, is scheduled to be released into the wild next year. But Intel insists the first version of Larrabee will target the traditional graphics space, making it unlikely that they would introduce ECC into the mix. Of course, the company could reverse itself and release a true HPC processor variant with ECC bells and whistles.

My sense is that ECC will come to GPU computing products sooner (1-2 years) rather that later (3-5 years). Being able to ensure data integrity in these devices will widen the aperture for HPC applications and help push GPGPU into true supercomputers. Just like double precision performance and on-board memory capacity, error correction is destined to become an important differentiator in high-end GPU computing.