AMD: CPU/GPU 'Fusion' May Be More Gradual, Past 2009

During a Webcast Friday afternoon, AMD executive vice president Henri Richard told BetaNews that, although one of the goals of his company's joint CPU/GPU combination project with its ATI division, code-named "Fusion," remains to merge pipelining with multicore architecture for everyday applications, its first few iterations may be limited to getting the two chips to share the same die and conserve power, for now.

"My sense is that Fusion will be an evolution," Richard told BetaNews. "Fusion is a vision more than a product. It's a vision that you can put on the same piece of silicon really multi-purpose computing cores, and really whether one core is going to compute x86 instructions and the next one's going to do shading, you get my message."

Last October, after completing its acquisition of graphics hardware producer ATI, AMD announced it would actively pursue the development of technology that uses the pipelining capabilities of ATI's GPUs in tandem with its multicore track for AMD's CPUs. For multicore architecture to achieve nominal improvements in performance, chips must have the ability to allocate tasks or threads among separate cores. For even greater improvements, software could be compiled in advance so that programs enter a system prepared for delegation to multiple cores, for a kind of parallelism more akin to what Intel had in mind when it first inaugurated its Itanium architecture.


Graphics chips, meanwhile, are best suited to handle specific mathematical procedures and algorithms where repetition is prevalent, which is why they're now so adept at shading 3D scenes consisting of hundreds of thousands, or even millions, of polygons. Pipelines serve like broadcasters, of a sort, of the objects of a function, so that a single function can be deployed on multiple items of data, or operands. In multicore parallelism, the functions and the data are distributed through different channels and processed in independent logic units; in graphics-style parallelism, the operands are distributed through multiple pipelines, while the function reigns supreme, like the taskmaster on a row-boat, beating the rhythm to which the oars must keep time.

Because this type of parallelism is so different, software has to be adapted to take advantage of it. Conceivably, drivers could be created that recognize tasks best suited for graphics-style parallelism. But those drivers will require cooperation from Microsoft to create, which may be why AMD is coming to terms with the reality that 2009 may be too soon for its initial goal of cooperative parallelism prototypes.

As Richard told BetaNews, AMD wouldn't be confident about its capability to pull off its Fusion product at all if it hadn't spoken in-depth with Microsoft first - as it did when it catalyzed the 64-bit revolution in 2005.

But doesn't Microsoft also have to cooperate with Intel on essentially the same project? How comfortable is AMD with that fact? "Obviously, before we go and look at a new technology, you can imagine that we talk to the people that are fundamental stakeholders in its implementation," Richard responded. "So we wouldn't go out and talk about Fusion if we thought Microsoft thought it was a really bad idea."

When AMD cooperated with Microsoft on 64-bit x86 processing, Richard said, it did so with the understanding that Intel might eventually catch on. But in so doing, he feels that guaranteed Intel's position as a runner-up in the race. "I don't think this is a very different situation [than x86-64]," he said, "except that if you look at the AMD that we are today, we're a lot more relevant to the ecosystem than what we were five years ago. So my sense is that, that reinforces our leadership position in innovation, because when we come up with an idea, we represent a much bigger part of the market."

Next: The first generation, followed by a CPU/GPU "sandwich"

3 Responses to AMD: CPU/GPU 'Fusion' May Be More Gradual, Past 2009

© 1998-2021 BetaNews, Inc. All Rights Reserved. Privacy Policy - Cookie Policy.