GPU on CPU - Memory bandwidth the impossible limiting factor?

[Gannon]

I have read article with people suggesting that GPU's functions will move onto the CPU but I simply do not see this happening for a couple reasons.

GPU's require massive amounts of memory bandwidth, from last I read CPU to main memory bandwidth as it stands is very far behind what GPU's currently have locally and what they need to keep pushing the performanc envelope and keep them fed.

I'm not quite clear on all the specifics but to me it would seem despite the "slow" links between GPU -> CPU (i.e. PCI express, or AGP) that it'd still a superior solution since you stream the data to the card and the card does all the work locally.

So I'm asking just exactly how would moving GPU functions onto a CPU really be a benefit speedwise when it seems to me the bandwidth between CPU and main memory (i.e. DDR2 667 for example) is way behind what GPU's have locally. Comments?

Where exactly would the benefits be for integrating GPU functions onto a CPU at this time? I don't see any at all personally.

 

[Acanthus]

GPUs are highly parrellel, you could never match the power with a general purpose cpu.

 

[DealPanorama]

If you look at AMD's new 4x4 system, it may be possible to add a GPU into the extra socket. This will be great for upgrading, as you can buy your ram separate from the GPU.

As for the bandwidth problem, I think multi-core CPU's will eventually get the same problem if we ever get to 8 or 16 cores. At that point, it may be a good idea to have on chip DRAM. The on chip DRAM would act like memory cache and can be huge 32MB and more. This could possibly be the solution to the bandwidth problem.

 

[vorgusa]

You are also thinking to much about gamers... just think about future CPUs with integrated GPUs to use on work or regular Home computers... probably cheaper and more powerful then a Motherboard integrated graphics and when you upgrade your CPU you would also be upgrading your graphics

 

[imported_Seer]

Originally posted by: Acanthus
GPUs are highly parrellel, you could never match the power with a general purpose cpu.

He's talking about having a GPU core in the same socket as a cpu, not software emulation.

 

[BrownTown]

which of course makes no sense since you have to upgrade them both at the same time even if you dont need the extra graphics power...

 

[vorgusa]

you do not pay extra to upgrade your memory controller when you get a new AMD processor, I doubt you would pay that much more for a graphics one.. At the beginning it will be more expensive then it will go down to a regular price, unless they seperate to two different product lines which would not make much sense since both Intel and AMD are trying for cheaper prices by mass production

 

[Calin]

High-end GPU have lots and lots of transistors - so with current technology, it would be difficult to cram a CPU and a GPU (both high-end) into a single chip/package. Also, both high-end CPU and GPU runs hot - putting two together would be bad.
Where I see this happening, would be in the budget market - low transistor count on processor and graphic (like in Semprons and integrated graphics cores). You might even see a new budget processor having less active (or total) transistor count in the core itself, not only in cache. FPU would be ported/shared to the GPU unit, reducing even more complexity. There will be a simple GPU, with few pixel/texture units, maybe few unified units usable as floating point pipelines (MMX, SSE, 3DNow, ...). This could (or could not) end up as a high-performance, low-power processor for mathematic tasks optimized to run on the GPU-type unit, using very cheap other components (memory controller on board, a very simple chip being northbridge and southbridge). Very cheap computers, and maybe usable as number crunching platforms.
As for memory bandwidth/memory latency for the graphics core, a IGP-type graphics core really don't use any real bandwidth, so a dual channel DDR2 might suffice.

 

[Acanthus]

Originally posted by: vorgusa
you do not pay extra to upgrade your memory controller when you get a new AMD processor, I doubt you would pay that much more for a graphics one.. At the beginning it will be more expensive then it will go down to a regular price, unless they seperate to two different product lines which would not make much sense since both Intel and AMD are trying for cheaper prices by mass production

Maybe in the future when we have more die space than we can reasonably use for CPU.

As it is now, a single GPU takes up more die space than a dual core CPU. (even if you brough GPUs down to the same 65nm process itd be well over half the die, and increase the size of the die to larger than the Core 2 Duo)

And the whole memory bandwidth issue would still be in the limelight, not to mention backtracking to a single core CPU.

Having a 2nd physical socket like AMDs 4x4 solution would be the only way i could see this being feasible, Intel, AMD, Nv, ATi and even SiS have thought of this long ago though.

 

[natto fire]

I think Acanthus and Calin hit both sides of this really well. Especially Calin's take on it being used for more low-end solutions. Bleeding edge will almost always require extra hardware. (Remember when 2D and 3D cards were seperate?)

Not to mention the complexity of dealing with dies that might fail testing. As it stands now, it is quite easy to just design GPUs with redundancy, or to underclock CPUs and sell them for cheaper. Who knows what would happen with having to account for ~600 million transistors on a single die.

 

[CTho9305]

Originally posted by: Calin
FPU would be ported/shared to the GPU unit, reducing even more complexity.

I don't think you'd want to do this. CPU FPUs are usually 32 and 64-bit (and 80 bit for x87), using IEEE754 compliant rouding. GPUs use weird number formats and can trade off accuracy for performance, so they can get more computing power in the same chip area (plus, they tend to have a huge number of parallel functional units, while CPUs tend to have only a small number, e.g. one adder, one multiplier, one MMX unit, etc).