>>The IGP's share of the other costs (fab buildout, etc.) is not entirely clear.
>>
>>The fabs are the #1 cost. But how much of that cost can be spread out per chip
>>depends on how many customers you can find to buy one chip each.
>>If there are lots of customers, smaller chip are gonna cost less.
>>If there are few customers, you can only utilize the fab fully by making big chips,
>>in which case the extra area per chip has no effect on fab costs.
>>If you have multiple generations of fabs at once, then the cost of idling a fab is more complicated.
>>An increase in the area of one product at a new fab may cause another product to
>>be shifted to an older fab that would have been idling.
>>
>>So, for example, by moving Sandy Bridge's IGP on chip, they consume 32nm capacity
>>at a greater rate and free up some 45nm capacity.
>>They then use up the extra 45nm capacity by delaying the 32nm shrink of Atom.
>>Would it be any cheaper if they made IGPs on 45nm and both Atoms and non-IGP Sandy Bridges on 32nm? Hard to say.
>>And if they did that, but replaced the 45nm IGP with software and idled the 45nm fabs?
>
>I don't see how any of this is relevant. Either you have an IGP at 32 nm, or two
>more CPU cores at 32 nm. The fab cost is the same.

You proposed two designs: one with 6 cores and one with 4.
The 6-core supposedly would be the same die area as the 4+IGP, and hence similar cost.
The 4-core was supposed to be cheaper, but by how much? This is what I was talking about here.
I argue that the cost of the chip is not proportional to die area, and that the savings is quite likely very small.
Now that I point that out, you suddenly pretend that the you never proposed the 4-core design.

>>The IGP's cost of design, v&v, drivers, and so on is shared between current IGPs
>>and any future products that use the same IGP (e.g. future Atom),
>>and to some extent future products with next-generation IGPs based on modified
>>versions of the current IGP. (e.g. Ivy Bridge)
>
>That applies to CPU cores between generations as well. But within one generation,
>having more cores is a negligible R&D cost while having both CPU cores and an IGP is a higher cost.

There is no savings whatsoever to be had by shutting down the IGP R&D program, unless you do it completely, across the entire product line.

Besides, saving money by shutting down R&D programs on a product line where they have ~50% market share of a huge market? This is your plan?

>>I think mask costs are pretty much a constant term + a linear term for chip area.
>>So the mask is more expensive with an IGP than without, but sublinearly, and if
>>the die area were spent on cores or cache instead, the cost would come out the same.
>>Package and pincount cost is pretty small for an on-chip IGP, but is dramatically
>>higher for a northbridge IGP or a discrete video card.
>>Software rendering would probably have comparable pincounts to on-chip IGP, except
>>if it makes inefficient use of bandwidth or power (which it almost certainly would).
>
>That's what I said. The IGP's mask and pinout cost is proportional to the area.

It isn't proportional.

>No, not at all. Programmability does not mean the end of APIs. Look at OpenCL for
>CPUs, and the many other choices of APIs and programming languages application developers
>get to choose from. But while some will pick a high-level API or even a full-fledged
>engine to create their applications, some will create totally new possibilities.
>So the software ecosystem expands instead of starting over.

So your plan is to have exposed software rendering competing with driver-based software rendering DirectX and OpenGL.

>Also note that software rendering would enable both backward compatibility AND
>forward compatibility. Running a game which demands DirectX 12 would require merely a software upgrade.

A software upgrade of what software? The OS? The drivers? The game?

>>Each sampler does a 4-texel quad at a time, so 2 of them do 8 texels per cycle.
>
>Why would samplers process a quad at a time? Do you have any proof of that?

Texels are processed in quads because it is needed to calculate mip-levels for dependent texturing.
This of course only applies to GPUs that support dependent texturing, so anything DirectX 8+.

>I was wrong about the 2 samplers though, it's actually 4 (32-bit textels): http://www.techarp.com/showarticle.aspx?artno=88&pgno=23

I seem to have been wrong about some of the numbers. I took your word for it that there were 2 samplers, but it looks like there is actually only one, so it's only 4 texels/clock.
Which is staggeringly poor. An original Geforce from 11 years ago could do 8 per clock (at like 150MHz though).
Anyway, redoing the calculations, it looks like 4cores=IGP, which makes unification somewhat feasible.

>Still, 5.4 GT/s peak isn't a whole lot, especially considering that the IGP will
>be arithmetic limited much of the time.

I doubt it. Those texturing numbers look terrible.
High end GPUs do 64+ texels per clock. This does 4 per clock.
Unless you feed it characteristically different workloads than what high-end GPUS see, it's mostly going to be texture-limited, except when it's bandwidth-limited.

>>If you beef up the gather unit so it can pull multiple source texels from a single
>>L1 cache access in a single cycle, you could catch up a little.
>>But this would require a swarm of enormous multiplexers in the middle of the L1D/LSU
>>datapath, which would probably add 2 or 3 cycles to L1 latency and would devastating to all non-graphics code.
>
>It wouldn't be all that costly. There's already a 512-bit to 128-bit 'shift' networks
>with byte granularity in place for each of SNB's load units. Turning this into a

But there's only one of it. You would need 4 or 8 of them to do fast gathers.

>network capable of selecting 4 x 32-bit ins't that much more complicated.

Shouldn't that be 8x32?

>
>It's somewhat comparable to the multiplexers already in the execution units to
>support all the permutation type instructions. Note also that these have a latency
>of 1 cycle. So both in terms of area and timings supporting gather/scatter shouldn't be a big hurdle.
>

But again, there's only one or two of these in the execution units. You would need a lot of them.

>>Also, it's not clear that other supporting parts of the chip could keep up, in
>>particular, the parts of the LSU and TLB associated with enforcing memory ordering,
>>coherency, memory protection checks and so on.
>
>It's only accessing one cache line per clock (per LSU).

This stuff isn't done per cache line. It's done per access.

>So there's no extra pressure
>on any of those parts. It merely needs to be able to collect four elements out of

Isn't it 8 elements? Or are you limiting yourself to 4 per cycle for some reason?

>a chace line, which isn't all that hard. And computing which elements are stored
>within the same cache line is easy too. You don't even need the full address per
>element for that. Just compare the upper 25 bits of the offsets and compute the
>lower 7 bits of the address to determine the position within the cache line (and 'overflows').

This is not a 32 bit processor, so addresses aren't 25+7. They are 57+7.
To check to which elements are stored in the same cache line, you just have to run ALL POSSIBLE PAIRS in parallel through separate 57-bit comparators.
So, for 8 lookups per AVX word, that's 36 comparators.

With all 8 57-bit numbers running as a single 456-bit bus, and then each comparator running out taps to the 114 input bits it needs, I get 456 bits wide and 114*36= 4104 bits tall.
This is a big thing. And that's just the wiring feeding into the comparators.

Maybe it's not as easy as you thought?

>
>>So basically, what we're looking at is that gather/scatter alone needs to make
>>the cores 4 times faster to hit your target of two cores=1 IGP.
>
>Not really. 5.4 GT/s corresponds to 86.4 GB/s bandwidth to the texture cache. With
>two 128-bit gather units a 3.4 GHz CPU would have 108.8 GB/s bandwidth to L1 cache,
>per core! So even if you reduce the clock speed to keep the power consumption in
>check, 6 cores amply exceed the minimal bandwidth required to match the IGP performance.
>

Only because the IGP is worse than I thought.

>>The point is there is are two separate the market segments here served by separate product lines.
>>Gulftown is high-core-count, high TDP, no IGP product, appropriate for mainly for
>>certain uses. (High-end Desktops, Servers...)
>>Sandy Bridge is a moderate-core-count, moderate TDP, CPU+IGP product, appropriate
>>for other different uses. (DTR Laptops, IGP Laptops...)
>
>There's not supposed to be separate market segments, other than high-end, mid-end, and low-end.

What???
You must be masterly with the English longbow.

>An operation is an operation. You need the same ones for any market segment. HPC
>and desktop applications alike are written in C-like languages which use generic
>integer and floating-point operations, memory accesses, control flow, etc. So there's
>little point diversifying for other market segments, other than performance. Server
>chips could be made more power efficient by having more cores and clocking them
>lower, but it can essentially be the same architecture.

I don't think you can just claim "All code is the same."
Granted, Turing completeness and all, differences are limited to such things as speed and power efficiency. But the differences here can be huge.

>>There is just too much room for further improvement in graphics quality in games.
>
>It goes in multiple directions. Serious gamers will never have enough graphics power. But casual gamers won't pay extra to play a ray-traced Super Mario.

Ray-traced Super Mario sounds pretty awesome. I'd get it.

>> So seriously, the group of people for which low-end graphics suffices, is growing.

But is the group for which it does not suffice shrinking? Or are they both growing together?

>Whereas previously IGPs were considered insufferable, they're now considered adequate for a very sizable market segment. The statistics don't lie: http://unity3d.com/webplayer/hwstats/pages/web-2011Q1-gfxcard.html

How representative is unity3d webplayer?
Last I checked, the stats from Steam hardware survey show a quite different picture. Not that Steam is representative either...

>>The wildcard here is the stalled console cycle. This hasn't happened before since
>>the 1970s, IIRC, so it's unclear what effect it will have.
>>If pc games continue to be mostly console ports, even when there is no new console
>>for 7+ years in a row, it could create a temporary plateau effect.
>>There might be no popular game demanding enough to need more than an IGP, thus killing the GPU market altogether.
>
>Exactly. What we need is innovation. A homogenous CPU with FMA and gather/scatter
>would give developers the freedom to develop some new exciting applications that were previously unthinkable.

I'm not so sure about this.
Mostly what we've gained since the NES is better graphics, but you can't have better graphics unless you hire more/better artists, and that costs a lot of money.

I think this is a big part of why so few games are being made for high-end pcs. The art cost of better graphics hasn't scaled well.
Performance won't solve this problem.

>Cheers,
>
>Nicolas