<combjelly: How the Crush chipset will use memory.>
There are some aspects of the article that I don't understand - or that at least would apply differently to an Athlon/Duron version of it. Take part of the second paragraph:
Next, as shown in Figure 1, a maximum of 1 GBps is allocated to the CPU, with CPU requests getting higher priority than the graphics pipeline. The CPU will rarely use its full allocation (which is considerably more than most current PCs support), but let's allocate the full 1GBps anyway.
(Although it doesn't really explain anything the link directly to "Figure 1" is: ddj.com
1 GB/s may be considerably more than the 800 MB/s that a 100MHz FSB PIII uses (even though it is slightly less than the 1.064 GB/s that current crops of CuMine use). AMD chips, however, can use about 2x that. It's also widely expected that Intel's upcoming version of the PIII will have a much higher FSB (likely 200MHz). That pretty much ruins his whole argument.
All that said, he's just not right. Current crops of graphics cards reach their memory bandwidth limit rather quickly, and the fact remains that the effective (SDRAM) bandwidth available to the NV20 in an XBox will be much smaller.
So how will the NV20 pull it off? I don't know, but it certainly won't be solely through "better programming". Abrash is (most probably) right when he says that the NV20 will employ a number of tricks to reduce bandwidth, including z-compression (similar to ATI's HyperZ) etc.
Abrash also hints at clipping (as in Transform, Clipping and Lighting - a step up from just T&L). By disposing of triangles that will be overdrawn later, this technique reduces the total effective overdraw, thus reducing the bandwidth requirements. How much is questionable, since most game engines already include some elements of this.
In the end, though, the NV20 will probably need some sort of embedded memory to really shine.
-fyo |
