NVIDIA Fermi: Architecture discussion
- Thread starter Rys
- Start date
Panajev2001a
Veteran
What is about rambus ip that intel's money cannot buy? LRB will debut directly with gddr5. And since lrb is a more bandwidth efficient architecture, it'll beat amd and nv gpu's anyday on the bandwidth efficiency metric. And intel has the pockets to make sure that they'll not be competing with inferir memory technology any time soon.
As gpu's generalize they'll have to give up the luxury of present day inefficiencies to compete with more efficient chips. And yes, edram/tbdr's seem to be the only solution right now.
GDDR5 only use differential signalling for the clock signals
Jawed
Legend
Z isn't compressed. It is fully allocated and static in size for a given render target size.
The data format for Z is optimised to minimise the count of locations that are accessed, e.g. a 4x4 tile of pixels where no edge falls can have Z samples written to a single tile in a burst for only 16 samples, leaving the remaining 48 samples (4xMSAA) unwritten. On-chip tile tag tables are used to keep track of the status of tiles.
Jawed
OpenGL guy
Veteran
Z *is* compressed or else you would see much slower results for single-sample Z fillrate. You still need to allocate the full memory, however, because you can't guarantee a consistent level of compression.
Z buffer was already compressed on r100, which had no idea what MSAA is...
Granted it only had compression ratio of 2:1. You're right that it is always fully allocated, but there's absolutely no reason you had to allocate all of it in your shiny edram. (The 8x compression factor I mentioned btw isn't quite correct, I think today the max ratio is actually a lot higher with AA).
As you said, there's on-chip tile tags - if I'm not mistaken these indicate if a tile has 8x, 4x, 2x or no compression, and when the chip needs to read/write a z tile the chip will read the appropriate amount of data from memory to get the data (decompressed) into the small z buffer cache (or write it back respectively). So you could simply store the first chunk of data of each tile in edram (so all data in case of 8x compression, half the data if it's 4x, down to 1/8 if it's not compressed at all), and leave the rest in ram. Would be quite simple to implement - in fact it's so obvious I'm wondering why noone implemented something like that yet
.
Last edited by a moderator:
EDRAM on the same die as the rest of the GPU logic would incur a cost in additional manufacturing complexity and possible impacts on the design effort and yields.
An upcoming large processor with EDRAM on-die is POWER7, but given the price that thing will go for, the tiny volume, and the service revenues IBM gets, the extra dollars to tens of dollars in per-chip manufacturing costs and possibly less than stellar yields mean very little.
Possibly future nodes will make this design option more feasible. If not, it would be a sign of significant competitive pressure to opt for the more expensive option.
An upcoming large processor with EDRAM on-die is POWER7, but given the price that thing will go for, the tiny volume, and the service revenues IBM gets, the extra dollars to tens of dollars in per-chip manufacturing costs and possibly less than stellar yields mean very little.
Possibly future nodes will make this design option more feasible. If not, it would be a sign of significant competitive pressure to opt for the more expensive option.
And how much edram would you need for runnig eyefinity with 6 monitors
Its always never enough no matter what the targeted resolutions!
Thus, there is a point where you have to go to tiling or render the whole image with some sort of irregular or multi resolution method.Its always never enough no matter what the targeted resolutions!
The good thing with GF100 is that you can take a break for a week or so, drool over your newborn like there's no tomorrow and there still won't be anything worthwhile about it in the net.
Sorry for the OT; as you where
I guess "Congrats" is in order
