NV55 wrote:
> GPU Computing Gets Ready for Act II
>
> The idea of general-purpose computing on graphics processing units
> (GPGPU) continues to capture the imagination of the HPC community. But
> the three big players -- Intel, NVIDIA and AMD -- all have their ideas
> on how this new technology should play out.
>
> When Intel rejected the whole notion of general-purpose computing on
> graphics processing units (GPGPU) at the spring 2007 IDF meeting with
> its announcement of its upcoming Larrabee product line, the digerati
> began to buzz about what the future might hold for the GPU. For those
> who might not have heard about it, Larrabee is Intel's answer to the
> programmable GPU, the technology that is bringing GPGPU to the m*****.
>
> The Larrabee architecture could be characterized as the anti-GPU
> entry. The overall approach is an attempt to evolve the CPU into a
> terascale data parallel engine. According to Intel, Larrabee will be a
> manycore (i.e., more than 8 cores) device and will be based on a
> subset of the IA instruction set with some extra GPU-like instructions
> thrown in. Intel has not elaborated on how it intends to do this, but
> one could imagine super-sized SSE units with just enough x86 CPU
> silicon to enable general-purpose flow control and data access. The
> first product release will probably come in 2009, but Intel says it
> may have something to demo as early as next year.
>
> The idea behind Larrabee is to bring both traditional graphics
> processing and data parallel computing under the IA umbrella. I'm not
> going to talk about the traditional graphics side of the story here
> (I'll let the game weenies argue about the advantages of ray-tracing
> over rasterization.) What's interesting about Larrabee and its GPU
> brethren is the extent to which a graphics engine can become a general-
> purpose computing engine without compromising its performance.
>
> The combination of a data parallel engine with more of the general-
> purpose flexibility of a traditional CPU could offer a powerful model
> for scientific computing applications, which usually consist of an
> irregular mix of matrix math and other logic. One of the drawbacks of
> traditional GPUs is that they depend upon an accompanying CPU for
> virtually all of the non-vector logic. That's fine if the application
> divides neatly between a vector computing kernel and the rest of the
> application logic in such a way as to keep both types of processing
> engines busy. But if it doesn't, the software developer has to find a
> way to tease out enough parallelism for the GPU to make sending the
> vector data on a round trip from the CPU worthwhile. This will only
> get worse in the future, since chip-to-chip bus performance is not
> expected to keep pace with either CPU or GPU performance.
The key here is going to be software, not the semantics.
If it is IA+GPU or GPU+IA, that's going to be hidden from the end users
anyway.
If Intel et al want to pitch general-purpose computing on a "GPU", they
have data-access and data-bandwidth hurdles to cross, as well as the
vital software tool chains.
Hopefully the slow migrations from single core, to dual/qaud cores,
have laid some groundwork on all this, and the manycore might have
practical uses, inside 5 years rather that outside 5 years.
-jg
|
