Print
Ever since multicore processors appeared a few years ago, programmers have been complaining about them. Distributing a software workload among multiple CPUs isn’t as easy as running a single-threaded program on a single CPU. Now AMD is doing something even more difficult—but it’s the future of computer science.
Image courtesy CNET
As you’ve heard, AMD’s new Fusion processors combine multiple CPUs and a GPU on one chip, like Intel’s “Pineview” Atom processors. In some cases, programmers can distribute workloads across all the CPUs and the GPU, and those workloads needn’t be graphics. This general technique is called asymmetric multiprocessing on a heterogeneous multicore processor.
No doubt you’re familiar with AMD’s CrossFire technology, which boosts performance by linking multiple graphics cards together. Usually, this is symmetric multiprocessing on homogeneous processors (identical GPUs). But AMD’s Hybrid CrossFire works with different graphics cards or even with a graphics card and an integrated-graphics chipset. Before, adding a graphics card usually bypassed the weaker integrated graphics.
AMD derives Fusion graphics from ATI Radeon discrete graphics, so the latest integrated GPUs aren’t the weaklings they used to be. Why waste the Fusion GPU if the user upgrades to a full-fledged graphics card? So AMD will allow Hybrid CrossFire configurations using Fusion graphics and discrete graphics.
Image courtesy Legit Reviews
It’s logical but nontrivial. The graphics driver must balance the workload across an integrated GPU and a discrete GPU that are related like cousins but not identical like twins. The GPUs use different memory and different I/O buses. In addition, some programs will try to use the GPUs and the multiple CPUs!
If you just heard a scream, it was probably a programmer. Buy the poor soul a Jolt cola. Asymmetric multiprocessing on heterogeneous multicore processors is a tough challenge, but it’s the future of computing. I’m confident the programmers are ready.
Tom Halfhill was formerly a senior editor for Byte magazine and is now an analyst for Microprocessor Report.
Comments are closed on this article
stradric
August 24, 2011 at 5:35am
There are already some languages available that abstract away the complexities of multicore programming. Microsoft's Axum is one. I haven't played with any myself, but I think it's an interesting topic. I like AMD's concept here, but I can't imagine the first iterations of their driver being very stable. It seems like a very delicate and error-prone process to balance computational load like that. Immensely promising stuff though.
TheZomb
August 23, 2011 at 4:33pm
To be fair, it would be alot easier of the coporations that create or back software solutions adopted languages with better support for multi-threading and multi-processing. Very few of the commonly used programming languages have robust support for multi threading and processing.
Its very hard for the software engineers designing a product to also design the tools required to make the product.
Until language support catches up with the hardware, presuming AMDs own tools for using the hardware are good, programmers won't be capable of developing software solutions that can take full advantage of the hardware.
I Jedi
August 23, 2011 at 2:54pm
I can appreciate that AMD is trying to take the step further, and offering up the ability to use both the chip set/CPU GPU and the discrete graphics card at the same time. The only problem I foresee is adoption by the programming community to actually take advantage of this unique opportunity to use this new function from AMD. Only time will tell how it fairs.
