Think about what the console games like today with GF7 and similar-powered but bit more advanced (not quite DX10 though (even if it surpasses even 10.1 and possibly 11 on certain feats)) GPUs and CPUs of that time - now think about how much power for example 18 CU GCN offers compared to what they have now and assume that CPUs will get nice boost too.
But there are also (a few) problems which are computationally bound. And as the aggregate bandwidth to the caches scales with the numbers of CUs (and a GCN CU is quite small with ~5.5mm² [that's actually Tahiti with 1/4 DP rate and ECC everywhere, Pitcairn is probably <~5mm²] while the pad area alone for a 64bit partition of Tahiti's memory interface measures >~10mm², the actual controllers and ROPs come on top of it), it can be cheaper to increase the the CU count than to increase the external memory bandwidth to get a similar performance for everything which has at least some small scale data reuse, even if you are already in the range of diminishing returns. On average it is probably always a bit cheaper to have a bit more raw flops than one would deem necessary for a "balanced" design.
Yes, it may not help much, but as long as it helps something and only inflates the (on the long term) decreasing wafer fabrication costs while reducing the more stable board costs and decreasing the number of memory chips needed, it may still be the better long term (performance/$) choice. And for a console, you can also try something a bit more future looking than focussing on current PC games (like XBox360 had the first unified shader design).
Would that also require an order of magnitude improvement in memory bandwidth, latency, and CPU power to scale everything linearly?
Xenos is actually relatively comparable (from a pure shader perspective) to a R600 design with three SIMDs (R700 through R900 didn't change too much in this respect) if one factor in the reduced efficiency of the vec4+1 of Xenos compared to the more flexible VLIW5/4 layout (if I would be forced to make a shoot from my hip, I would estimate this advantage of the later designs to be ~20% on average, of course it varies significantly depending on the workload), while reducing the relative texture fetch bandwidth a bit (at least for the versions with full size SIMDs). GCN is a different breed which again adds probably something in the range of 30% on average (bringing the total advantage compared to Xenos to ~50-60% per CU/SIMD). But of course this applies mainly to "old fashioned" tasks. In more modern workloads it could easily exceed these numbers even without taking the added flexibility and enabling of new algorithms into account.
The eDRAM of Xenos didn't use any compression (as other GPUs do). You have to compare that with the bandwidth to the ROP tile caches (Color + Z) of recent GPUs. I don't have any clue about the size of these caches, i.e. how much reuse one may achieve on average. But one purpose of these caches is that the external bandwidth is only used for compressed data (and with 4x MSAA one probably easily achieves compression ratios of >2:1).
There aren't enough. Cell's highly multithreaded.
There can't be a single large thread about it, or it wouldn't fit in the LS, it's better to scatter the discussion into small questions.
It's easy to come up with efficient and easy to implement depth compression schemes, as most areas in depth buffer form a continuous surface (triangles are connected to each other, and have linear slopes). For example you could split the depth buffer to 8x8 tiles (256 bytes uncompressed). During the rendering remember the minimum and maximum depth value of each tile (this data is also very useful for depth culling bigger blocks of data, often called Hi-Z by GPU manufacturers). As you know the minimum and maximum values of each tile, you can easily determine how many bits you need to store the range. Most 8x8 blocks do not have that big depth changes, so most blocks would be pretty well compressed (while some blocks of course be left uncompressed).
