Hi Seni,

Seni (seniike@hotmail.com) on 2/24/11 wrote:
---------------------------
>> There's just no way a contemporary game using high quality setting is going
>>to run at decent framerates on this IGP.
>
>Well, it's an IGP. Current IGPs aren't about decent framerates. They are about
>getting crap framerates but still playable.

Exactly. And software rendering isn't too far behind. Make use of AVX, add FMA and gather/scatter, and replace the IGP with more CPU cores and you get adequate graphics while also having a CPU which can do way more than legacy rasterization.

>Hopefully they will catch up a little in the future, but I'm not expecting much from Intel just yet.

They can't catch up. AnandTech has tested aggressively overclocking the IGP and the performance didn't go up by much. It's limited by the socket's bandwidth. This also means that spending more die area on the IGP would be a waste. And increasing the bandwidth while keeping a low latency is expensive. So the IGP isn't going anywhere any time soon, while the CPU is catching up in effective throughput.

>>>They increased the GPU clock but not the memory bandwidth. This resulting in poor scaling.
>>>Increasing GPU clock but not bandwidth has always resulted in poor scaling. Nothing new here.
>>>How this shows anything about trends in future hardware is beyond me.
>>
>>It shows that the die area percentage for the IGP can't simply be increased in
>>the next generations to save it from its fate.
>
>I don't see why not, especially if memory bandwidth rises for unrelated reasons, as it has been doing for decades.

Bandwidth is only increasing slowly in comparison to throughput. A Core 2 Duo E8400 had 10.7 GB/s of bandwidth, and 48 GFLOPS. An i7-2600K has double the bandwidth but over four times the GFLOPS. And FMA, gather/scatter and replacing the IGP with CPU cores would dramatically increase the throughput again.

>>Certain people here insist on comparing
>>theoretical compute density but fail to see the bigger picture
>
>But I'm not one of those certain people, so... strawman?

No, I merely added it as an additional observation, not in response to any of your arguments. When we agree, we agree.

>>The CPU is catching
>>up and unification gives it an area advantage, which can also be traded for reduced power consumption.
>
>Except that the best way to trade area for reduced power consumption is likely to de-unify.
>Specialized hardware is more power efficient and can be powered down completely
>when not in use. The only cost is area.

If power consumption was that important we'd have specific GPUs for playing different games, not a continuing expansion of capabilities and unification of functionality. I also seriously doubt we're ever going to see physics ASICs ever again. People care a lot about the price and flexibility of their hardware.

So as the architectures and workloads converge closer, there's simply a point where unification gives you more than the sum of the parts. Power consumption determines how small the gap has to be, but it doesn't stop the convergence itself.

>>In particular it means that as the convergence reduces the gap, the IGP is the first to go.
>>
>>>>The CPU is catching up and clearly there's little point in investing more die space
>>>>into the IGP. So CPU manufacturers should look into using the die space for something
>>>>more interesting, or cut it out entirely.
>>>
>>>They cannot use the die area for something more interesting, since IGPs are maximally interesting.
>>
>>With all due respect that's as short-sighted as saying the architecture of an R300
>>is the maximally interesting use of 195 mm2 of silicon. Beyond low-end graphics,
>>the IGP's capabilities are pathetic so you can forget about GPGPU. There's a lot to be improved.
>
>See, the thing is, what's interesting and what's not is all opinion. You can't disprove an opinion.
>If I claim that IGPs are maximally interesting to me, well then you have no ability
>to dispute that, because only I know what is interesting to me.

True, it's all a matter of opinion. But let me just repeat that it would clearly have been foolish to consider an R300 maximally interesting several years ago, or any other architecture really. History tells us that innovation has never been at a standstill. NVIDIA and AMD can't stop innovating now either, or it would seriously hurt their business. That's hardly an opinion.

Heck, continuously scaling the same architecture is simply physically impossible. As the transistor budget increases exponentially, you need to compensate for the growing gap between bandwidth and logic density. The relative excess of transistors allow to increase programmability, implement a memory hierarchy to take advantage of spacial and temporal locality, increase ILP, etc. Moore's Law has held true for over four decades so any other proposition is a much bigger gamble.

If you want to stick to your opinion that things won't evolve any further, fine, but then the discussion ends here and we'll meet again in several years...

>>More interesting GPUs (programmability) and more interesting CPUs (throughput)
>>are released every major generation. So they're on a collision course. Replacing
>>the IGP with two more CPU cores makes the use of that die area a lot more interesting
>>because they can then be used in combination with the already existing CPU cores.
>
>On the contrary, putting more cores on the chip is boring since they are exactly
>like the existing cores. I mean, it's just a numerical increase. How much more boring can it get?

If I can run *any* software with reasonable efficiency on the die space occupied by the IGP, I call that more interesting than just the ability to run mediocre graphics. Also note it's not just a numerical increase in the number of cores, the cores themselves would also get FMA and gather/scatter to increase the effective throughput.

>If you buy loaves of bread at the store, and see that the manufacturer decided
>to put raisins in the bread, that might be interesting.
>If they just increased the size of the loaf by 1 slice, that's not interesting. That's a boring numerical increase.
>You might prefer it, if raisins aren't your thing. But that doesn't make it interesting.

With all due respect that's a terrible comparison. A heterogeneous architecture is more like a small loaf of bread and a pile of raisins next to it. A homogeneous architecture is actual raisin bread. The fact that this makes it a bigger loaf doesn't mean it's boring.

You can have the best of both worlds with an architecture which is latency and throughput optimized. This is a major benefit for mixed workloads, which would otherwise have to communicate between the heterogeneous cores or perform work on a suboptimal core for the task. This benefit is only getting bigger, because DLP is limited by Amdahl's Law and at the same time software is getting more complex.

>>>>I think I've clarified by now that eventually there's just 'computing'. A homogenous
>>>>CPU with FMA and gather/scatter can handle both latency-sensitive and high-throughput
>>>>workloads (and most applications are a complex mix of these). So the main thing separating the markets is price.
>>>
>>>There are many market segments separated by more than price, and your refusal to see them is baffling.
>>
>>Other than CPUs and GPUs, which are converging, I don't see what else could be
>>relevant to the discussion. So instead of implying I refuse to see them, why don't you show them?
>
>So you want a list of market segments, eh?
>Down from the top:
>
>-supercomputers
>-mainframes
>-workstations
>-database / transaction processing servers
>-web servers
>-cloud computing / consolidated servers
>-Gamer Desktops
>-DTR laptops
>-game consoles
>-Cheapskate/Corporate Desktops
>-mainstream & thin&light Laptops
>-Cheapskate/Corporate Laptops
>-netbooks
>-tablets
>-portable game consoles
>-smartphones
>-embedded / industrial / military
>-embedded automotive
>-embedded consumer appliances
>
>Let's look at some of the differences here.
>Supercomputer and workstation for example are mostly floating point. More specifically,
>double-precision floating point.
>Mainframes and transaction processing have very little floating point, and a heavy
>focus on reliability, branchy integer code, i/o, and throughput
>Gamer desktops, game consoles and so on are also heavily floating point, but it's all single-precision.
>For Corporate / Cheapskate Desktops, performance isn't a big issue, but what little
>performance is needed is all latency-sensitive integer code.
>For laptops and all other portable stuff, power efficiency is important.
>For military, industrial and automotive, reliable operation under harsh conditions is important.
>
>So you see, this stuff is all different, and it's not just about cheap vs. fast.
>There are other issues. Efficiency, reliability, suitedness to different workloads.

And despite all that the very same CPU core design used for desktops are also used for supercomputers, workstations, servers, laptops, military systems, etc. Likewise, the same GPU architectures are used for gaming and HPC.

You're underestimating the cost of differentiation, you're underestimating the value of flexibility, and you're overestimating the cost of unification. An organization buying a supercomputer doesn't want to be caught with its pants down when suddenly someone needs to run integer intensive code. The cost of adding an integer ALU next to a floating-point ALU (or having a unified design) is almost negligible compared to the potential value for customers.

Creating a new design is insanely expensive. Intel can bring a new generation of chips to the market ever two years, but it still takes multiple teams to work in parallel and costs billions in R&D. Likewise AMD had to buy ATI for 5.4 billion to be able to produce discrete GPUs and fuse an IGP into the CPU. So you'd better make sure your architectures are well balanced for multiple workloads.

And for a CPU+IGP the reliability of both components has to be the same so this doesn't change for a homogeneous architecture. Also, while some CPUs feature ECC support and such, that's not relevant to the unification of cores we're talking about (plus GPUs for the HPC market feature it too).

So seriously, the CPU and GPU core designs for these market segments are practically identical, leaving price as the biggest differentiator. And with the CPU and GPU converging, it's only a matter of time before we get one architecture to do all forms of computing. The IGP is the obvious first victim.

>>>>Again, most applications are a complex mix of workloads. But even if some tend
>>>
>>>No they aren't. It's not a complex mix.
>>
>>Have you ever taken a look at the various shaders used by a various games? They
>>differ significantly. And they would differ even more if the GPU wasn't so restrictive.
>>Like you said yourself, sometimes a texture access is replaced by procedural code
>>and sometimes arithmetic code is replaced by a texture lookup, to better match the
>>architecture. A more unified architecture would allow to use the operations they
>intended to use, and get a net speedup.
>>
>>As a matter of fact that's what I've already observed for the past decade. In the
>>early days there were no dependent texture lookups so some effects were simply not
>>possible or there was usually just one workaround with acceptable performance.
>
>There was always multipass rendering, which is Turing-complete. And also you could
>always render a bitmap on the CPU and upload it as a texture. So no effects were ever not possible.

Don't be ridiculous. I know the GPU is Turing-complete, but when you have to use multipass to implement dependent texture lookups on architectures that don't natively support it, that definitely counts as a complex workload, for which a generic homogeneous architecture would be far better suited.

So stating that "no effects were ever not possible" is true in itself but it's not helping you forward with anything relevant to the discussion. On the contrary, it shows just how limited GPUs were, and even today certain workloads may be possible in theory but are a no-go in practice.

>>This
>>and other limitations made every game look like a clone of other contemporary games
>
>And yet they weren't. Early 3d games do not, in fact, all look the same.

The artwork was different, but the graphics techniques were largely the same. With Direct3D 8 most surfaces simply had a base texture and a lightmap, and if they had a bump map it was the same effect based on the texbem functionality.

>>(not in gameplay but in graphics), which started to change as the capabilities expanded.
>>The unification of vertex and pixel processing also allowed developers a lot more
>>freedom in the workloads,
>
>Actually it made very little difference. It was a big letdown.

And yet they never looked back. Sure, most existing games of that time didn't benefit all that much from unification, since they still attempted to balance the vertex and pixel workloads. But now that pretty much everyone has a unified graphics chip, games have a greater variety in vertex and pixel workloads. So you have to take more than just the instant benefit into account. Furthermore, geometry shaders, computer shaders, tessellation, etc. it all greatly benefits from unification.

>You can't use it to increase the vertex count, because there is a bottleneck in vertex fetch & triangle setup.

Exposing another bottleneck is not an argument against unification. They fixed that with later generations.

Also note that a homogeneous CPU with gather/scatter would never have such a bottleneck in the first place.

>You can't use it to increase pixel detail by much, since the hardware vertex shaders
>were only like 10% of the total shader hardware, and thus exposing them to pixel
>workloads only give you about 10% speedup.
>The tradeoff is a little better on Fermi as there are multiple triangle setup units.
>But at the time when unified shading was introduced it was surprisingly ineffective.

Again, that wasn't the fault of unification itself. It's irrelevant how well it did or didn't work back then. The reality is that it's currently unthinkable to go back. Besides, it has only been four years since the first unified chips hit the market. That's a very fast return-on-investment.

>>between applications but also between scenes in the same
>>application. Floating-point textures and render buffers enabled deferred shading,
>
>Deferred shading is a mistake. All it gives you is performance, but it comes at
>the expense of breaking your AA algorithm, thereby costing more performance than it saves.

That was fixed with Direct3D 10.1 by allowing access to anti-aliased buffers. Besides, floating-point textures and buffers have more applications than just deferred shading.

>>which differs quite radically from previous approaches. And that's just the things
>>that immediately popped into mind, and I wasn't even just talking about graphics.
>>Other applications you may run on your system also have diverse and complex mixes of workloads.
>
>They have diverse behavior as a group, but each individual program is mostly homogenous, not a complex mix.

So? You still want to keep the data passed between them on-chip as much as possible. For instance geometry shaders are a specific workload but it's faster to run them concurrently with the other shaders so you don't consume bandwidth. So the chip is actually running a complex mix or shaders. And to dynamically balance vertex, geometry and pixel shaders a unified architecture makes most sense.

>>There's really no denying that GPUs have become more programmable and more capable
>>at handling this melting pot. And with GPGPU and future graphics research hinting
>>at ray-tracing and micro-polygons and whatnot there doesn't appear to be an end
>>in sight. At the same time CPUs have increased their throughput using multi-core
>>and widening the vectors, and FMA and gather/scatter will make them even better
>>at running more than just latency sensitive workloads.
>
>This is circular reasoning. You say gather/scatter will catch on because convergence
>demands it. Then you say convergence will happen because of gather/scatter.
>It could just as well go the other way: lack of gather/scatter support makes convergence
>infeasible. Then non-convergence makes gather/scatter unnecessary.

It's not circular reasoning. Convergence happens regardless of gather/scatter. MORE convergence happens with gather/scatter support. Convergence isn't a goal in and by itself, it's just that an architecture which balances ILP, TLP and DLP is the most valuable. Unification is an added bonus which allows to bridge the final gap.

Also, this is what innovation is all about. You need sparks (AVX, FMA, gather/scatter) to ignite something bigger (a superior homogeneous architecture). And the industry doesn't leave innovation opportunities unused. The competition is fierce so you can't afford not to look at all the options. The idea for gather/scatter is out there, and the potential of it is being researched as we speak. All the ingredients are there; it has a relatively low hardware cost and it greatly benefits throughput workloads while also allowing vectorization of less trivially data parallel workloads. So it's just a matter of time.

>>So with both aiming to support
>>both types of workloads, a showdown is inevitable.
>
>I think it's quite possible the the showdown is evitable and will in fact never occur.

You're talking as if it would be a bad thing to have a homogeneous CPU which can also adequately handle graphics. There's no reason to fight it. Like I said, convergence isn't a goal in and by itself, but neither is avoiding convergence. CPUs get a big increase in transistor budget with every process node, and one of the ways to spend these transistors is by increasing throughput. Likewise, the GPU is running into DLP limits and has to spend a larger portion of its transistors on storage and ILP. This is merely an observation.

>>Note that there isn't any strict dividing line between them. You can't offload
>>every high-throughput task to the GPU and execute every low-latency task on the
>>CPU. Unless you have a massive amount of data parallelism to exploit it's faster
>>not to send things over to the GPU and just process things on the CPU. The communication
>>latency is too high and the bandwidth too low.
>
>The communication latency & bandwidth is an issue if you are communicating over PCI-E.
>It's a complete non-issue for CPU-IGPs though, where all the communication stays
>on-chip. Not that IGPs are up to task... yet.

It's not a complete non-issue at all. Communication latency and bandwidth between CPU cores and IGP cores is pretty bad.

The round-trip latency involves a lot more than just making an electrical signal cross a few centimeter and back. You have to format your data, issue a command to the API, the data gets copied and the command ends up in a queue, then when the IGP is ready it pulls in the data and starts processing, when completely done it signals the CPU and the results have to travel back.

So letting the IGP take care of all throughput heavy workloads is nowhere near free of issues. In fact GPGPU on the IGP is totally hopeless. Only one-way communication like with graphics is realistic. If Intel wants that die space to have any value beyond graphics it's only option is to equip the CPU cores with FMA and gather/scatter and replacing the IGP with such cores. The data can then stay local for much longer, and even communication between the homogeneous cores can be much more fine-grained than communicating with the heterogeneous IGP.

>>It's better to unify things and keep
>>the data local. Likewise, the GPU shouldn't always leave latency sensitive tasks
>>to the CPU. Often it's faster to use a dumb brute-force approach to get the job
>>done without a round-trip to the CPU. But imagine a latency-optimized GPU which
>>doesn't have to waste computing resources so it becomes even faster.
>
>A latency-optimized GPU would suck.

That's an unfounded claim. There are significant differences in latency between various GPU architectures, yet their effective performance is competitive.

Non-aggressive latency optimizations don't hurt the performance. They may lower the theoretical throughput but compensate it with a higher efficiency.

And for an IGP you get the area benefit of unification on top of that. So a homogeneous chip can have more latency optimizations, allowing it to function as a CPU as well.

>>Both are heading for the same thing.
>>
>>>>to be hugely latency-sensitive or high-throughput, there's no telling what application(s) you'll run tomorrow.
>>>
>>>Unless, of course, for some reason, you know what applications you'll run tomorrow.
>>>Like if it's your job or something.
>>>Like, for example, you are evaluating the choices of what to run right now, so as to buy the necessary software.
>>>Or maybe you bought the software and have no funds left for more software, so you
>>>will have to continue using the same software.
>>>Or maybe they're the same apps you're running right now, and that you've been running for the past ten years.
>>>You overestimate the uncertainty.
>>
>>I don't overestimate it. You're absolutely right that systems are always bought
>>with certain uses in mind, and usually it closely matches the actual uses. But that
>>doesn't mean we should underestimate it either. Someone with a 500 € budget may
>>not expect to be able to simulate the ocean currents, but he does expect to be able
>>to run the vast majority of desktop applications, including some that have yet to appear.
>
>Ordinary desktop applications (excluding games) have barely changed in the past
>fifteen years. I think it's reasonable to guess that they will barely change for the next fifteen as well.
>I know there have been some new applications since then, but I can't think of a
>single one for which performance matters.
>So if you buy a low end laptop now, and expect to run future applications on it, it will probably work fine.

It won't. Try running any modern application on a system from '96. It will be a horrible experience. Even an Atom CPU is many times faster than the CPUs we had back then, so whether you like it or not, the software has evolved a lot in fifteen years.

>>In particular, someone who currently opts for a CPU+IGP, would be better off with
>>a homogeneous CPU with gather/scatter in the not too distant future.
>>
>>>>>Ray-traced Super Mario sounds pretty awesome. I'd get it.
>>>>
>>>>Well, actually, due to the wildly varying latencies occuring in ray-tracing, you
>>>>need an architecture capable of coping with that optimally. A homogenous CPU with
>>>>gather/scatter can handle fine-grained dynamic balancing of the complex mix of workloads.
>>>
>>>There's not really a problem here with varying latencies. Ray tracing on GPUs works fine.
>>
>>This should sober you up: http://www.youtube.com/watch?v=4bITAdWvMXE
>
>He's saying that GPU raytracing is not quite as good as CPU raytracing. But then,
>he's doing the CPU raytracing on a twelve-core multi-socket workstation.

That's only two 6-core CPUs, and he's comparing it against a pair of expensive GPUs. Furthemore, once again the GPUs are worthless without a CPU. The driver needs a fairly powerful CPU. So when comparing the cost you can't look at the prices of the cards alone.

>Also it's not clear how old this comparison is and if anything has changed since
>then. It may be that the GPU is catching up, or already has caught up.
>All signs suggest that the GPU's ability to raytrace is improving at a high rate,
>so it may very well surpass the CPU soon if it hasn't already.

Keep in mind that the CPU is evolving as well. 6, 8 and 10-core CPUs with AVX will be lauched later this year. So by the time the GPU can do all the complex ray-tracing, and do it faster than the 12-core system, it's up against a new generation of CPUs which much higher throughput.

The only way the GPU can catch up with that moving target, is by investing more transistors into latency optimizations. But because this lowers the peak throughput it can't possible surpass the CPU for this workload. The CPU still has FMA and gather/scatter to greatly improve its effective performance. I don't know of any new technology that would give the GPU an advantage over the CPU.

>Also, you see he said nothing about variable latencies being a problem. Because they aren't.
>The actual problem seems to be that GPU can't cast enough rays per second to smooth out the sampling noise.
>It casts too many where they aren't needed and not enough where they are, since
>it lacks the flexibility to make a finer-grained decision about it.

It's probably a combination of things really. But the reality stays the same: The GPU would require CPU technology to catch up, and this also means it will never surpass it.

>>The GPU has lots of limitations and doesn't achieve the same quality as a CPU does
>>in a fixed amount of time. You may note that his 'solution' around 7:30 is a heterogenous
>>architecture, but that's just the current status quo. It fails to take into account
>>that the CPU's vector units got wider, and we still have FMA and gather/scatter to come.
>>
>
>It's true the CPU's vector units are getting wider, but the GPU is widening at an even faster rate.

No they're not. It's not just the vectors getting wider. Simultaneously the number of CPU cores increases, and FMA will also double the theoretical throughput.

GPUs on the other hand are losing compute density:
* Cypress XT: 2154 Mtransistors, 2720 GFLOPS, 320 VLIW5 cores, 850 Mhz
* Cayman XT: 2640 Mtransistors, 2703 GFLOPS, 384 VLIW4 cores, 880 Mhz

The focus on getting wider is making way for other optimizations. So in terms of compute density, the CPU and GPU are converging.

>>In fact there are reasonably successful 'hybrid' ray-tracers but unsurprisingly
>>the developer's biggest complaint is the communication overhead between the CPU
>>and GPU. A CPU with FMA and gather/scatter offers the best of both world without
>>such overhead.
>
>So does a beefed-up on-chip IGP.

No, that still has a high communication overhead.

>>You could also make the GPU more latency optimized but that's a lot
>>more work and you still don't get the unification benefit. So the CPU is going to eventually win this debate.
>>
>>>>The casual gaming market is booming, and the potential of WebGL and Molehill is
>>>hard to overestimate. The web allows to reach a whole new market of people, who
>>>are hesitant to set foot in a game store or install Steam.
>>>>Mark my words; the next World of Warcraft hype may very well be an HTML5 or Flash game.
>>>>The emerging Smart TV market also consists of devices with weak graphics chips (shameless plug: http://gametree.tv/platform/).
>>>
>>>The casual gaming market is booming, but I suspect the casual gaming market has little to do with hardware at all.
>>>Casual gamers couldn't care less whether they have a 4-core or a 6-core.
>>
>>Then why would Intel even manufacture a mainstream quad-core CPU with an IGP?
>
>Because the hypothetical software-based graphics that you propose as an alternative does not yet exist.
>Most people buy an IGP because it is currently the cheapest way to get a bootable system with a screen.

That's not an obstacle at all. There would still be basic 2D graphics support. The 3D driver only gets loaded when the operating system starts up, just like what happens today with the IGP.

>Others buy an IGP because its low power consumption allows it to fit in a small laptop where a discrete GPU would not.
>People buy 4-core processors because they don't need 6-core processors and 4 is a bit cheaper.
>Also, this is a clearly superior one-for-one replacement of their previous popular
>product - dual-core & quad-core cpus with northbridge IGPs.

You can have a 6-core CPU without IGP for the same price as a 4-core CPU with IGP. For graphics they can be downclocked to stay power efficient. Alternatively, you can save the price of the IGP entirely with a homogeneous 4-core CPU. Both are more interesting than today's offerings, when the homogeneous CPU delivers adequate 3D graphics. This merely requires FMA and gather/scatter.

>>The thing is, casual gamers aren't just casual gamers. They buy a 'multimedia'
>>system and expect a wide variety of applications to run smoothly.
>
>They buy a "cheap" system and don't know whether to expect anything will run smoothly or not.
>Then they find out that most stuff does run smoothly, except a few games. Then they blame the games.
>So they play the games that work instead of the ones that don't.

Indeed they buy a cheap system, but still the one with the best specs. So if you offer a homogeneous quad-core for the same price as a dual-core with IGP, that's a better deal. It also enables software developers to create applications which use all this extra CPU power.

You may question whether we need extra computing power, but that question has been asked many times before in history and every single time the answer was yes.

>>And with lots
>>of software development turning toward multi-core, it's no luxury to put more than
>>two CPU cores into a system, and beyond, to make it sufficiently future-proof.
>
>Future-proofing doesn't make a lot of sense these days.
>It's cheaper to buy a minimally adequate system now, and then buy a new one years
>later later when prices are lower if/when your requirements change.

It would be more future-proof, for the same price! A quad-core homogeneous CPU capable of adequate graphics is more future-proof than a dual-core CPU+IGP. It means that even when you're on a budget you can buy a system that will last longer than one with a heterogeneous computing solution.

>>>Also, Farmville may be comparable in size to WOW, but I doubt many WOW players
>>>are quitting to play Farmville instead. (Unfortunately, I have no statistics on this.)
>>>They will continue to play WOW for quite some time. And when they eventually stop
>>>it will be to play another WOW-like game, probably with better graphics.
>>
>>I'm not talking about Farmville. I'm talking about actual MMORPGs that are as challenging as World of Warcraft.
>
>Why aren't you talking about Farmville? You said an MMO comparable in scale to WOW. Farmville is it.

I didn't say an MMO comparable in scale to WOW. I said "the next World of Warcraft hype may very well be an HTML5 or Flash game".

But if you want to talk about Farmville, fine: It doesn't require 3D at all, and if a future version does then software rendering will still suffice.

>Also, "as challenging as WoW"? What? There's zero challenge to WoW. You kill
>monsters until you hit the level cap, and then you wait for the expansion to raise the level cap. That's it.
>All the instance raids and gear-seeking is optional. It is a challenge people
>take on themselves because the game has failed to provide one.

That's a matter of taste. Millions of players disagree with you. I'm not a big fan of it myself, I just mentioned it to illustrate the kind of graphics which is considered adequate by a significant portion of the market.

On a quad-core CPU, this game already runs well with SwiftShader. With AVX, FMA and gather/scatter, the efficiency would be much improved so the power consumption can be reduced. So there's no point in paying extra for an IGP, or sacrificing two cores to fit in an IGP.

>>As I've indicated before you can't have a 4 times faster IGP without also scaling
>>the memory bandwidth accordingly.
>
>But you CAN scale memory bandwidth accordingly. Both pincounts and memory clock
>frequencies have been rising at a good rate for quite some time now.
>The 4004 had 16 pins. A 386 has like 100. A modern CPU has around 1000. The number
>is growing and there is no reason to think it's about to suddenly stop.

I'm not saying it's about to stop. I'm saying it increases too slowly for the IGP to keep up with the CPU's increasing performance.

A mainstream Core i5 has twice the bandwidth of a mainstream Core 2 Duo back in 2006. So it took about five years to double the bandwidth. This means that by 2016 you can expect to see a mainstream CPU with an IGP that is twice as fast. But by that time we're at an 11 nm process meaning 8 cores are definitely mainstream, and FMA and gather/scatter are no challenge either. So this two times IGP would be up against a CPU which is well over twice as fast. And this assumes a heterogeneous architecture. A homogeneous architecture can have more than 8 cores at 11 nm.

The other option for the IGP is to add value by becoming more programmable. But this costs area and power. It converges the IGP closer to the CPU.

So the IGP can't outrun its fate.

>>That won't happen unless they put a lot more pins
>>under the chip,
>
>Or if they raise the memory clock. Or both. Or if they improve compression or something.

They'll increase both the pin count and clock frequency, but again, only at a slow pace. Increasing the clock frequency isn't without issues. DDR4 won't go mainstream before 2015. And don't forget the CPU and IGP clock freqencies are going up slowly as well.

>>making it far more expensive.
>
>Except that the cost per pin decreases over time as packaging technology improves.
>So what's expensive now, won't be for long.

Again, the pin count will indeed increase, but too slowly for the IGP to outrun the advances in CPU performance.

>>Low-latency DDR bandwidth is a lot
>
>I don't think there's any such thing as low-latency DDR. All DRAM is high latency.
>Well, there's probably a product called "low-latency DDR" but the latency is still not low, just lower than the usual.

I was comparing system DRAM to graphics DRAM.

>>more expensive than GDDR bandwidth. So you shouldn't expect CPU bandwidth to go
>>up very fast, meaning IGPs remain in the low-end segment.
>
>I think bandwidth will go up fast, and some IGPs will move up from low end-toward the middle.

Based on what? For the bandwidth to increase any faster the consumer will have to pay extra. But there's no incentive for doing that. People who really want better graphics, buy a discrete graphics card. And the IGP is worthless for anything other than graphics.

So it's just going to remain the lowest common denominator. If its performance increases, it's only at the mercy of CPU bandwidth improvements and proportionate increases in transistor budget. The CPU benefits from these things equally, but on top of that it also benefits from FMA and gather/scatter.

>>Even if they pulled out all the stops to make it happen, it would be a big shame
>>if such an expensive chip (we're talking current server market segment here) is
>>mediocre at running Crysis 2 but gets beaten by a cheap multi-core CPU at every
>>other application. There's just no demand for such an abomination.
>
>What? What are you talking about, running Crysis on a server? That's not what servers are for.

If you want to increase the bandwidth beyond the slow current evolution, you need extra memory lanes. This brings us into server chip domain. The extra pins and wires make both the chip and the motherboard more expensive. But like I said, it would be ridiculous if such an expensive solution had poor CPU performance. So it's just not going to happen that the bandwidth is aggressively increased for the sake of making the IGP faster, without also scaling the CPU part. So the IGP isn't going to outrun it.

Cheers,

Nicolas