Ok so in the 5 years since SSE3 we're going to get 4x CPU FP throughput. Is that supposed to be impressive when you consider how much faster GPUs have gotten and how much more demanding graphics workloads have become in the same time frame?
It's an eightfold increase since Prescott, and a fourfold increase since Nehalem,
per core. The number of cores is going up as well, and by ditching the IGP there would be room for even more cores.
Keep in mind that high-end GPU dies became a lot bigger, and a lot hotter. This means the performance/area and performance/Watt didn't increase as spectacularly as one might assume. Also, the earliest floating-point GPUs only spent a tiny fraction of their die space on ALUs. Nowadays they can't cram any larger ratio of shading units onto a die. So while GPUs did rapidly increase their computing power, those days are now over (unless of course they get rid of the remaining fixed-function hardware).
Yes, and it would be deficient in memory bandwidth, texture filtering, texture decompression, rasterization and a whole slew of things that would chew into those 435 GFLOPS that GPUs currently get for free. CPU flops != GPU flops.
As I've said before, the average texture sampling rate is far lower than the peak texture rate GPUs waste their transistors on. And this is also true for all other fixed-function hardware. Furthermore, GPUs can get bottlenecked by numerous things, stalling the ALUs and thus wasting FLOPS. CPUs indeed have to spend some cycles 'emulating' fixed-function hardware, but it's less than you might think and they're not bottlenecked by any of it.
Last but not least, brains can win from muscle. A GPU doesn't bother to skip processing invisible geometry. It just uses raw computing power to process massive batches as fast as possible, wasting part of it on things that never end up on the screen. With a CPU you can make more fine-grained decisions, using the available FLOPS more wisely.
Ah, so Intel is going to storm the mainstream graphics market by increasing the thermal and power requirements of even the highest end CPU configurations today? Does that really make sense to you? The main issue with your claims is that a 200w CPU with 4x the throughput will still be slow at graphics. Current CPUs are just that slow.
A 200 Watt CPU with AVX-1024 would have way more than 4x the throughput.
...unlike GPUs, CPUs will not get much wider each generation.
Why not? If OpenCL has any future at all, then multi-core homogeneous CPUs have an even brighter future since they can handle a wider range of applications. Only a year ago people still claimed quad-core was overkill, but nowadays they've gone mainstream and applications actually start to benefit from it. Even NVIDIA's mobile Kal-El chip will feature four CPU cores.
You also have to realize that going multi-core is pretty much a one-time investment for software developers. It can be a heavy investment, but once you have an software architecture that scales up to four cores, it usually automatically takes advantage of more cores as well, or requires just minimal effort. Also, we're starting to see ever more tools to assist in writing multi-threaded software. So it's only a matter of time before you'll see serious benefit from having a multi-core CPU in a wide variety of software.
Heck, even for a heterogeneous architecture the CPU has to continue to scale to keep supporting the otherwise helpless GPU.
When Haswell arrives in 2013 it will be facing Maxwell and 2nd generation GCN. How much faster do you think they will be than today's Fermi and Cayman parts? I would wager at least 4x (nVidia claims 8x).
Maxwell won't appear on the shelves in 2013, and only 1st generation GCN is slated for 2013.
Do we even know how fast gather will be or if Intel's schedulers and memory subsystem can actually feed 16 FMAs/clk? How efficiently will they emulate fixed function hardware?
There is no confirmation of how fast the gather implementation will be, but since Knight's Corner is rumored to support gathering any number of elements from one cache line every cycle, there's no reason to expect anything less from an architecture with less wide vector units and already two load units per core. Most people also expect them to double the width of the load and store units. That actually creates an interesting opportunity for the gather implementation: The first load unit has minimal latency and handles most regular loads, while the second load unit supports gather instructions at a slightly higher latency, and also pitches in when there's a high amount of regular loads.
