GPU accelerators shouldn't cross over into CPU territory too much

Dec 12, 2011 21:11 GMT  ·  By

Advanced Micro Devices hasn't said anything much about its upcoming collection of graphics cards, but it did reveal a few things about some other matters.

Among other things, the Sunnyvale, California-based company has spoken its mind in regards to GPGPU computing.

In supercomputers, while x86 CPUs do much of the work, there are areas where parallel processing is ideal, especially since the parallel capabilities of GPU computing accelerators is, simply put, humongous.

AMD doesn't think special-purpose GPU-based accelerators should be made compatible with CPU sockets though.

In other words, if one really must have parallel processing in the CPU, it should be due to an on-die graphics part while not giving up the x86 part.

In other words, its Fusion technology is supposed to have a great potential in HPC installations.

“APU is a better and cleaner solution than sticking a GPU in the same socket,” said Neal Robison, senior director of content and application support at AMD.

Oddly enough, AMD actually did entertain the thought of CPU socket-compatible GPUs several years back.

In the early 2,000s, it came up with Torrenza, a special-purpose accelerator that would install in the same sockets as AMD Opteron server microprocessors.

At this point, it is rather clear that nothing will come of Torenza, even though Intel is doing its best to promote similar solutions, the Knights Ferry and, eventually, Knights Corner.

One cause behind AMD's stance is that the investment in Fusion has already been made and there is no point in not using an already available resource.

The other matter is that, while GPUs have very high compute performance, they can't work at full potential because the software isn't as efficient.

GPUs also can't use features already available in x86 CPUs, so Fusion APUs apparently make more sense since they lack these disadvantages, except the software one which is out of AMD's hands or Intel's for that matter (barring participation in software development consortia and the like).