May I ask you how NVIDIA should go about shifting GPU's (particularly to OEM's and desktop consumers) for the sake of running CUDA?
I just can't picture the Dell's and HP's to spend the extra money to integrate an NVIDIA GPU into their systems, just to increase performance of a range of select applications (which the average Joe user probably won't even use in the first place).
But that's the key point: quad-cores also only increase performance on a range of select applications in practice! So the key isn't to accelerate a billion applications; the key is to make it more valuable for Joe Consumer to have a powerful GPU than a quad-core or even a tri-core. For the 2009 Back-to-School cycle, Intel's line-up will look like this:
Ultra-High-End: 192-bit DDR3 Quad-Core Nehalem
High-End: 128-bit DDR3 Quad-Core Nehalem
Mid-Range 1: 128-bit DDR3 Dual-Core Nehalem
Mid-Range 2: 128-bit DDR2/3 Dual-Core Nehalem [Third-Party Chipset]
Low-End: 128-bit DDR2 Dual-Core 3MiB Penryn
Ultra-Low-End: 128-bit DDR2 Single-Core Conroe [65nm]
So let's make the goal clear: encourage OEMs and customers to stick to dual-cores, and potentially even Penryn, in favour of using a more expensive GPU. As you point out, this won't work if you only accelerate select applications; so the solution is simple: do massive in-house R&D for a wide variety of suitable applications, and release the results as freeware and free closed-sourced libraries for third party applications to use.
I have a list of suitable applications if you are interested. However, it should be easy to make up your own by looking at any modern CPU review and pondering whether the multi-core applications benchmarked could be accelerated via CUDA. The answer is 'yes' in a surprisingly high number of cases; you're unlikely to parallelize LZMA/7Zip, but there are a lot of things that you *can* do in CUDA, especially with shared memory.
CUDA and NVIDIA's GPU revolution sounds great, in theory. But the idea runs out of steam very quickly, IMO.
It runs out of steam instantly if you don't have enough applications on it. But if you got a bunch of applications running on it, you can simultaneously reduce the value-add of quad-core and increase the value-add of GPUs. You won't get many design wins in the enterprise space for it; but honestly, if the decision makers are rational (errr, that's a bit optimsitic) that market should become a pure commodity market and ASPs should go down 10x. So yeah, you can't add value there, but that's really not the point.
Besides, isn't this one of the reasons why Intel is designing Larrabee? Should GPU's truly spark a revolution in the processing landscape, then Larrabee will be Intel's insurance. Of further note is that AMD has ATI for back up as well.
Yes, but once again, basic arithmetic tells us that Intel will be in big trouble if GPU/GPGPU ASPs grow while CPU ASPs lower, because the chip represents nearly 100% of the BoM for a CPU but much less than half for a GPU. So if the end-consumer market is constant, replacing every CPU by a GPU would result in 50-80% less revenue; i.e. utter financial disaster.
Larrabee is a great product for Intel if it just eats away at GPUs. But sadly for Intel, the world is more complex than that, and their fate will be decided in the 2009 Back-to-School and Winter OEM cycles, likely before Larrabee will be available. This is another reason why in-house development is key by the way; in that timeframe, third-party software developers might want to hedge their bets with Larrabee, and clearly that would have negative consequences. And given the fact that the potential profit opportunities here dwarf those of traditional GPU applications, I'd argue it'd be pretty damn dumb to let third parties decide of your fate. Such a strategy has very rarely worked in the past, and it's not magically going to work now. Can they still help? Well yeah, duh. But once again that's not the point.
Sorry for having to contradict you in your first post, but if that makes you feel better apoppin is indeed a bit crazy here (no offense intended!) 