But AFAICS higher arithmetical throughput doesn't affect memory bandwidth requirements, because the data stays mostly on chip even for loops. And making that interpolator more powerful and flexible will definitely cost transistors. Or are you referring to the option of adding more ALUs? Then I'd have to agree.
I'm talking of increasing the number of usable GFlops any way whatsoever - it could be increasing the number of ALUs, or it could be making each multiprocessor more efficient or powerful.
The net result of that is higher performance with bandwidth requirements that remain ~constant. Because of the higher performance, you can sell your chip for more money, but your non-chip (PCB, memory, etc.) costs are roughly constant. Well, that's not completely true: power requirements might increase, which might make the PCB and the cooling more expensive. But compared to the alternatives, that's really not such a big deal I suspect.
Interestingly, ASPs are also one of the main reasons why MCP78/MCP79 will be much powerful, relative to discrete parts, than previous IGPs. NVIDIA would prefer getting a MCP78/MCP79 design win than a G86/G98 design win, because the ASPs they get there are higher! The PCB/Memory costs are basically not a factor and there's no extra memory required, while you can ask for the combined price of a chipset and a GPU...
But OTOH you could just get the overall ALU clocks a little higher with simpler Units and stay within a given thermal budget at the same time.
Indeed. Nothing prevents you from doing both though, obviously!
In my opinion one of the strengths of the G8x architecture seems to be it's very high utilization which should be close to a possible max taken away the possible overhead of 16x-SIMDs (if we take Atis claim of 95% util on R520 granted).
Sure, that's true. It's not because you're efficient that you can't also be powerful though, I guess. And regarding the MUL, the 'efficiency' of that in G80 is obviously not that good. Most of the time it's either used for interpolation, or it's idling. Errr!
Thanks for the heads up on Blending
But doesn't consume a higher blend rate also more memory bandwidth? That'll (if you want to utilize it to the max) drive components costs up so that you end up having more transistors in your chip and having to sell it for less?
Yes, of course - but you don't *have* to double bandwidth to use that. In chips that have high-end memory, it could be a bottleneck - in ones using DDR2 or low-end GDDR3, obviously not. Here are the necessary calculation to prove that:
8400 GS: 450MHz*4ROPs*4Bytes*2*0.5 = ~7GiB/s
8600 GTS: 675MHz*8ROPs*4Bytes*2*0.5 = ~21GiB/s
The 8400 GS has 6.4GiB/s of available bandwidth, while the 8600 GTS has 32GB/s available. Clearly, in one case it should never be a bottleneck, while in the latter it could sometimes be (although not a major one). I am not taking depth into consideration here, but there is a very good reason for that: particles don't write depth, they only read it - and that can be fairly cheap on average, especially so with Hier-Z helping. That doesn't mean it's free, but you get my point.
Also, in both cases, doing FP16 at the same speed is pure overkill. You are never going to get the bandwidth you need for that on G8x, except with high-end GDDR4 and fairly low core clock speeds!
Anyway, because G98 and G96 likely will have higher clock speeds than their predecessors and likely won't use GDDR4, this doesn't seem like much of a problem for them. Same for MCP78/MCP79 for obvious reasons. G92, on the other hand, could possibly benefit from single-cycle INT8/FP10 blending if it does use GDDR4.
It wouldn't be a major bottleneck in any sense of the term, but it is an interesting 'minor change' to ponder upon - especially so since G70->G71 made the exact same change! This time around, it might make more sense to keep the datapath width identical (32b/clock, see FP16) but double the filtering power (since FP10 likely reuses the same transistors as FP16).
