AMD's Fusion CPU + GPU Will Ship This Year
mr_sifter writes "Intel might have beaten AMD to the punch with a CPU featuring a built-in GPU, but it relied on a relatively crude process of simply packaging two separate dies together. AMD's long-discussed Fusion product integrates the two key components into one die, and the company is confident it will be out this year — earlier than had been expected."
Sup dawg. We herd you like processing units, so we put a processing unit in yo' processing unit so you can computer while you compute!
It doesn't really matter, any more than AMD's "proper" quad core mattered more than Intel pasting two dual-core dies together. This is really just AMD getting beaten to the punch again, and having to try to spin it in some positive way. It's great news that it will be out earlier than expected, but I think they would have been better off taking the less "beautiful" and just throwing discrete dies into a single package. Particularly as it has yet to be seen how big the market for this sort of thing is. More exciting to me is that AMD is ahead of schedule with this, so hopefully they'll be similarly ahead with their next architecture. I'm yearning for the day when AMD is back to being competitive on a clock-for-clock basis with Intel.
Even faster than current generation discrete GPUs? I think not.
They'll move data inside the chip instead of having to send it off to the internal bus, they'll have access to L2 cache (and maybe even L1 cache), they'll be running in lock-step with the CPU, etc, etc. These have distinct advantages over video cards.
AMD Fusion was meant to compete with Larrabee which is not released. The Intel package with two separate dies is not interesting. The point of these products is to give the programmer access to the vast FP power of a graphics chip, so they can do, for instance, a large scale fft and ifft faster than a normal CPU. If this proves more powerful than Nvidia's latest Fermi (GTX 480 I believe), then expect a lot of shops to switch. Right now my workplace has a Nvidia Fermi on backorder, so it looks like this is a big market.
In addition to the CPGPU or whatever what they're calling it, Fusion should finally catch up to (and exceed) Intel in terms of niftilicious vector instructions. For example, it should have crypto and binary-polynomial acceleration, bit-fiddling (XOP), FMA and AVX instructions. As an implementor, I'm looking forward to having new toys to play with.
I hereby place the above post in the public domain.
This is great for mobile devices and laptops but I don't think I want my CPU and GPU combined in my gaming rig. I generally upgrade my video card twice as often as my CPU. If this becomes the norm then eventually I'll either get bottlenecked or have to waste money on something I don't really need. Being forced to buy two things when I only need one is not my idea of a good thing.
Call me when they can fit 9 inches of graphics card into one of these cpu.
Size isn't everything!
Forget thrust, drag, lift and weight. Airplanes fly because of money.
Actually Intel had a radical way to handle this - Larrabee. It was going to be 48 in order processors on a die with Larrabee new instructions. There was a Siggraph paper with very impressive scalability figures for a bunch of games running DirectX in software - they captured the DirectX calls from a machine with a conventional CPU and GPU and injected them into a Larrabee simulator.
This was going to be a very interesting machine - you'd have a machine with good but not great gaming performance and killer server performance - servers are naturally "embarrassingly parallel" because you can have one thread per client. A sort of x86 take on Sun's Niagra.
Of course there are problems with this sort of approach. Most current games are not very well threaded - they have a small number of threads that will run poorly on an in order CPU. So if the only chip you had was a Larrabee and it was both a CPU and a GPU the GPU part would be well balanced across multiple cores. The CPU part would likely not. You have to wonder about memory bandwidth too.
Larrabee was switched to be a GPU only and then canned.
Of course as a pure GPU it is a bit of a poor design. Real GPUs don't drag in x86 compatibility - they can implement whatever instruction set is best and nothing else. The instruction set is not publicly exposed and can change from generation to generation. You can cram a lot more than 48 cores onto a GPU and the peak performance is higher. Power consumption is lower too.
Still a modern gaming GPU is huge - there's no way you're going to cram it and a modern GPU onto a die and get something affordable. Then again CPUGPU chips are probably not aimed at gamers - there's an argument for having a CPU and a stripped down integrated GPU on one chip for netbooks like the latest Atoms do.
You could cram in a chipset too to reduce the price on netbooks.
echo -e 'global _start\n _start:\n mov eax, 2\n int 80h\n jmp _start' > a.asm; nasm a.asm -f elf; ld a.o -o a;
Arguably, the "off-chip FPU" nowadays IS a GPU - hence all the GPGPU stuff.
Thats what the guys tell themselves.
Balderdash!
There's two sides to this coin and Intel's is pretty neat. By not having the GPU integrated into the CPU die, Intel can improve the CPU/GPU without having to redesign the entire chip. For example, any Power management improvements can be moved into the design as soon as it's ready. Another advantage for them is the fact that each die CPU and GPU are actually indepenent and can be manufactured using what ever process makes the most sense to them.
AMD's design offers a major boost to overall CPU performance simply through the fact that the integration is far deeper then Intel's. From what I've read, the Fusion ties the Stream Processors (FPU) directly to a CPU and should offer a major boost in all Math ops of the CPU and I expect that it will finally compete with Intel's latest CPU's in regards to FPU operations.
Mod me up/Mod me down: I wont frown as I've no crown
If AMD puts a competetive GPU onto the CPU die, comparable to their current high-end graphics boards) then this is a really big deal. Perhaps the biggest issue with GPGPU programming is the fact that the graphics unit is at the end of a fairly narrow pipe with limited memory, and getting data to the board and back is a performance bottleneck and a pain in the butt for a programmer.
Putting the GPU on the die could mean massive bandwidth from the CPU to the hundreds of streaming processors on the GPU. It also strongly implies that the GPU will have access directly to the same memory as the CPU. Finally, it would mean that if you have a Fusion-based renderfarm then you have GPUs on the renderfarm.
This is exciting!
I love Mondays. On a Monday, anything is possible.