Intel scrapping all-in-one CPU/graphics chips? [Now a CPU vs IGP Debate]

Davros

Legend
A new leak http://theovalich.wordpress.com/200...ns-45nm-auburndale-and-havendale-fusion-cpus/
indicates that Intel may be abandoning at least early plans for its first mainstream processors to include built-in graphics. Versions of the company's Auburndale and Havendale desktop and notebook processors with graphics cores on the chips themselves have reportedly been shelved due to economic concerns. As Intel can less afford to keep plants making 45 nanometer processors, the company allegedly hopes to shut down sooner by focusing only on 45nm Core 2 and Pentium parts for the low end and Core i7 for the high end.
 
Hypothetically, you might say this gives AMD a potential "in" if they continue with their Fusion part. Obviously either stance is now a gamble -- can AMD pull it off and make it profitable? Or was Intel right and that it will only serve to suck further R&D only to end up as a low-cost, low-margin part due to the targetted platforms?
 
Hypothetically, you might say this gives AMD a potential "in" if they continue with their Fusion part. Obviously either stance is now a gamble -- can AMD pull it off and make it profitable? Or was Intel right and that it will only serve to suck further R&D only to end up as a low-cost, low-margin part due to the targetted platforms?

amd is lucky in the fact that they already poor money into ati . intel doesn't really have an ati so i think its more of a win for amd.
 
If economic conditions do not improve and Abu Dhabi and Intel don't both prove to be more generous than thought, Intel's decision not to manufacture jet packs is just as much a win for AMD's jet pack product ambitions as any delay in integration of graphics by Intel is for Fusion.
 
"But, this is not the end of Fusion concept in Santa Clara. Intel is going to replace Auburndale/Havendale with their 32nm die-shrink, known as Arandale." - hmm? So how does Theo (which is not really the best source in the world, mind you) claim Intel is giving up on Fusion-like products? :)
 
Next-gen MediaGX comin' our way. I see a new ultra-low-end PC market coming if these ever show up. What else could they be good for? Might be a Geode replacement....
 
a dual core nehalem isn't exactly ultra low end :).
the new MediaGX might be the Loongson 2H, Vortex86MX or nvidia Tegra.

(in no particular order. Among these vortex86 should be the weakest but x86 compatible, loongson may have the best CPU, tegra the best GPU)
 
By the time these come out, a dual core Nehalem might be the new Celeron. I just see these super-integrated chips as a way to get rid of the chipset too. At least, as much as possible.
 
Intel is planning a next generation of Atom processor with integrated graphics on core, codename "Pineview." It's slated for 2H 2009. Although I hope they use a better graphics core, at least with H.264, VC-1, and MPEG-2 HD acceleration, otherwise it won't be very competitive.
 
By the time these come out, a dual core Nehalem might be the new Celeron. I just see these super-integrated chips as a way to get rid of the chipset too. At least, as much as possible.

That's exactly what I'm thinking -- an entire system on a chip essentially. But the entire point for something like that would be component cost and overall system footprint reduction, with the obvious tradeoff being performance. And I can only see those being aimed at "cost-minimal" solutions such as the next gen of net-tops and whatnot.

So, I'm sure it will get done eventually. But is the economy right now going to give them the spare cash to sink into that R&D? We could probably argue that they already have spare cash laying around in small piles the size of some 3rd world countries, but their shareholders may not agree with the expenditure right now.

Thus, I think this is just a pause which allows the R&D budget to shrink a tad, which then allows the bottom line to make up for the expected decrease in sales. Once they feel they've weathered the recession (how ever long that is), then I bet money will start going in that direction again.
 
Yeah there are already system-on-chip options out there, just not really for a PC. This would be a new, even lower cost way to make those Walmart machines. :) That's about the only way I can see integrating all of this into one chip makes sense.

Intel wanted to do this with a Celeron back in 2000 or so (Tinma link), for those who don't recall. And then before that there was the Cyrix MediaGX as I've already mentioned. I think that hardware is small enough now that a featurerific-but-slow IGP would be so tiny that it makes sense for those super cheap machines. Less chips and less reliance on other sources is only a win. I doubt that using the transistor budget like that for a performance class chip makes sense though.
 
Last edited by a moderator:
These architectures will only be of temporary nature. It won't take long before they realize that a graphics core with support for DirectX 11+ starts to look a lot like just another CPU core. FSX is playable at Medium High 1024x768 purely software rendererd on my Core i7. So by the time such CPU is considered a 'Celeron' we might not actually need a GPU core. Advancements such as AVX, FMA and gather instructions also make it far less sensible to have dedicated silicon for graphics.

After unified shader units and a fused CPU+GPU this is the only logical next step.
 
FSX is playable at Medium High 1024x768 purely software rendererd on my Core i7.

OK, so this is yet more proof that no matter the cost and power of an x86 desktop cpu, it's still no match for even an inexpensive but dedicated 3d gpu?....;) I don't know why it is that you might assume that during the time span between now and when the i7 is demoted to Celeron status, that 3d gpus will just sit still in terms of R&D. I would expect that by then the gap between software and hardware rendering of the 3d APIs will be just as large as it is today, because for one thing we will be talking about gpu capabilities being widely supported by developers that are only now being discussed in the abstract.

I'm also not sure why you might think that as APIs advance to support more and more 3d capability that this automatically means that gpus will eventually become clones of x86 cpus. GPUs serving as DX11 (and earlier) hardware platforms will not have to be x86-compatible, and will not have to serve as cpus, and will not be tasked with running x86 operating systems. This alone, it seems to me, will be enough to continue to differentiate the cpu from the gpu for the foreseeable future.

Even twenty years ago, people routinely confused economic concessions with technological advances, so it isn't surprising to see the trend continue. Twenty years ago, the "multi-function device" was all the rage--but not because it was technically superior, but because it was more economical. There's no difference today that I can see. Integrated capabilities and technologies will continue to serve the lower rungs of the market, whereas specialized and advanced technologies will continue to drive the upper rungs of the market, rungs concerned with resolution display, quality of rendering, performance, and expandability. The PCIe bus is relatively new, still, and is, like all buses before it, dedicated to the proposition of device expansion and upgrade.
 
There are tasks that map very poorly to current general purpose CPUs and most of them are related to texturing.
Texture LOD computation and texture samples address generation are the worst offenders imho (filtering per se is not even that bad..). It's like asking to a current GPU to do some task level parallelism, it's tricky but doable, but also extremely inefficient.
 
There are tasks that map very poorly to current general purpose CPUs and most of them are related to texturing.
Texture LOD computation and texture samples address generation are the worst offenders imho (filtering per se is not even that bad..).
Indeed filtering is not that bad but in my experience neither are LOD computation nor address generation. They are just arithmetic and scale with GFLOPS. So AVX will more than double their performance. What doesn't scale that easily is texel fetch. As vectors get wider, reading elements from different memory locations becomes a serious bottleneck when done sequentially. So a gather instruction becomes essential.
It's like asking to a current GPU to do some task level parallelism, it's tricky but doable, but also extremely inefficient.
Once you start unifying logic, everything becomes inefficient to some degree, yet overall these devices are better at a wider range of applications. So with TEX:ALU instruction ratios still going down and GPUs getting tasked with more generic computations, it's not going to take that many generations before neither the CPU nor GPU can be called "extremely inefficient" at anything.
 
Indeed filtering is not that bad but in my experience neither are LOD computation nor address generation. They are just arithmetic and scale with GFLOPS.
While compiling the current texture sampler states to texture addressing/sampling code remove a a lot of control flow you still end up having to handle dozens of cases that can only be determined at run time. For instance every time you have to take a variable number of samples or when you are calculating the LOD for a cube map and your derivatives have to be computed on samples that map to different faces. Moreover with the vast majority of textures being 8 bits (or worse compressed..) per component filtering texels on a full precision floating point unit is a waste of power and area.

Once you start unifying logic, everything becomes inefficient to some degree, yet overall these devices are better at a wider range of applications. So with TEX:ALU instruction ratios still going down and GPUs getting tasked with more generic computations, it's not going to take that many generations before neither the CPU nor GPU can be called "extremely inefficient" at anything.

Jack of all trades and master of none? :)
 
While compiling the current texture sampler states to texture addressing/sampling code remove a a lot of control flow you still end up having to handle dozens of cases that can only be determined at run time. For instance every time you have to take a variable number of samples...
That really isn't so bad. The loop count doesn't change so the CPU is perfectly capable of predicting when to branch out of it. Furthermore, the compare and branching instructions are handled by parallel execution ports so they don't affect the filtering throughput.
...or when you are calculating the LOD for a cube map and your derivatives have to be computed on samples that map to different faces.
No need for control flow there.
Moreover with the vast majority of textures being 8 bits (or worse compressed..) per component filtering texels on a full precision floating point unit is a waste of power and area.
Just use integer vector operations instead. Also note that I'm not talking about today's nor next generation CPUs, but the generation beyond that. So some instructions can be added that benefit 3D rendering (and many other things), starting with a gather instruction. So it still requires some evolutionary steps, but not a complete overhaul.
Jack of all trades and master of none? :)
Is that so bad? That's what the CPU has always been, and like I said, that's where the GPU is heading as well. Once they get close to meeting in the middle it makes no sense to have silicon dedicated to graphics. Compare it to shader unification. There has been quite a bit of discussion here about whether that would actually be beneficial. Nowadays, nobody doubts about it. So it's better to be Jack of many trades than master of one.
 
Back
Top