The LAST R600 Rumours & Speculation Thread
- Thread starter Geo
- Start date
- Status
Not only the pure bandwith is an important criteria for that. The latencies have to be very small. For example:
-a read/write access on a flipflop circut is done in a single clock (registers)
-a read/write access on sram is done in ~10 clocks
-a read/write access on eDRAM is done in ~100-150 clocks
-a read/write access on external DRAM is done much much more clocks
Internal stored data is very dependant to latency. Often there is no real big burst, which would need bandwith, but is not so dependant on latency.
To return to the bandwith topic:
The L2 Cache in G80 would need at least 561,52 GiB/sec (64 TMUs x 4 pointsamples x 32 Bit x 575 MHz). Maybe the Bandwith is a bit higher for better upscaling the clusters. L1 Caches would need less bandwith but lower latency.
The registers would need much more bandwidh 3,9 TiB/sec ( 128 channels * 32 bit * 3 Flops * 2 terms * 1350 MHz)
Of course theses caches/registers are not one pool. There are many of them located where they are needed. Otherwise such high bandwith wouldn't be possible so easily.
MadMaxtrox
Newcomer
Yet another Fuad update
http://www.theinquirer.net/default.aspx?article=37718
I wonder if the NDA expiration is accurate?
http://www.theinquirer.net/default.aspx?article=37718
I wonder if the NDA expiration is accurate?
I have one of those and they are flawed in design for a CPU cooler. For it to be effective, it has to be standing straight up and down. Doing that increases the cooling of the CPU by 5-10 degrees cel.
which is why heatpipes use wicks.
Your numbers are slightly off.
I assume your point of reference are the cache latencies in CPU's? Those are exceptions. They are simply way to big to reach high speeds, so they run at lower clock speeds than the core itself, but even there they have an intrinsic latency of only a cycle or 2 or 3: there is no reasonable way to pipeline the memory array itself. All you can do is register the inputs, pipeline the address decoder and register the outputs. So high latencies on those RAMs must be because they run at a lower clock speed.
But, again, those are exceptions: chips have hundreds of little SRAMs sprinkled all over the die. They all have 1 or 2 cycle read latency.
Those are intrinsic latencies of the RAM device itself: from non-multiplexed input of the RAM to the data output. This is the only useful number without discussing the functionality of the logic around it.
If you have 10 clients trying to write to the same resource at the same time all the time, then your average read and write latency will multiply accordingly or ever more if the arbitration logic also needs pipeline stages to meet timing. But the RAM itself has not part in that equation.
Correct.
Nope. It's 2 clocks to read when you're doing high-speed stuff. (1 cycle to clock the address, 1 cycle to clock the return data.)
I assume your point of reference are the cache latencies in CPU's? Those are exceptions. They are simply way to big to reach high speeds, so they run at lower clock speeds than the core itself, but even there they have an intrinsic latency of only a cycle or 2 or 3: there is no reasonable way to pipeline the memory array itself. All you can do is register the inputs, pipeline the address decoder and register the outputs. So high latencies on those RAMs must be because they run at a lower clock speed.
But, again, those are exceptions: chips have hundreds of little SRAMs sprinkled all over the die. They all have 1 or 2 cycle read latency.
Nope again. A lot of eDRAMs support single cycle reads which again you would have to flop at the output, so it's a 2 cycle read latency. Same story as with SRAM. In some cases there's refresh needed, but in others, you switch between banks to make it happen automatically. You could say that latency is double in that case if you have to access the same bank 2 times in a row.
The exact number varies, but read latency is probably around 15 cycles for high speed DDR, lower for low speed. (It's easy to look this up in a datasheet.)
Those are intrinsic latencies of the RAM device itself: from non-multiplexed input of the RAM to the data output. This is the only useful number without discussing the functionality of the logic around it.
If you have 10 clients trying to write to the same resource at the same time all the time, then your average read and write latency will multiply accordingly or ever more if the arbitration logic also needs pipeline stages to meet timing. But the RAM itself has not part in that equation.
Last edited by a moderator:
Anarchist4000
Veteran
Not sure if this is fake or not but looks reasonable. NDA expires March 15 and the launch is the last week of March. The 6+6/8 power option is mentioned. Internal bridge for crossfire. XTX also comes in both 9.5" and 12" versions.
Not really a whole lot of new information but seems useful nonetheless.
http://www.chilehardware.com/foro/r600xtx-calendario-de-t63761.html
Not really a whole lot of new information but seems useful nonetheless.
http://www.chilehardware.com/foro/r600xtx-calendario-de-t63761.html
Bouncing Zabaglione Bros.
Legend
Bouncing Zabaglione Bros.
Legend
I think yields will be better than that. It's not going to be a PE part.
Aerows
Regular
Whoa, thank you for the heads up. I appreciate the information. I'm still on air for now, anyway. It's loud, but it keeps the cats from sitting on the box (I have a Microfly with a screened in top and sides - that could be disastrous).
If you make a decision like that in the design process, i'd be willing to bet the engineers would find ways to hide the latencies - maybe through minuscule caching, high frequency RAM (what matters is time, not clock cycles) or whatever.
Thanks for thinking i'd be foolisch enough to think you could take any given GPU and substitute its caches with VRAM.
Anarchist4000
Veteran
It could very well use more power and run a little hotter but performance is what should matter more. More ram so expecting more power/heat isn't really unexpected there. Also it's using an 80nm process instead of 90nm on G80 so that should be giving lower temps and higher clocks.
other than size and cooling solution, what is the difference between the 9.5" and the 12" versions?
epic
epic
You won't be able to buy the 12" version. It's for OEMs only.
http://www.theinquirer.net/default.aspx?article=37726
Man, that would be such a kick in the balls for Nvidia it won't even be funny. WHQL Crossfire for R600 on Vista before official launch? That would undoubtedly raise AMD's image significantly and show a serious emphasis on quality. The Nvidia Vista driver situation is really a fiasco. Hopefully WHQL translates to bug-free and high-performance gaming!
Man, that would be such a kick in the balls for Nvidia it won't even be funny. WHQL Crossfire for R600 on Vista before official launch? That would undoubtedly raise AMD's image significantly and show a serious emphasis on quality. The Nvidia Vista driver situation is really a fiasco. Hopefully WHQL translates to bug-free and high-performance gaming!
Are you being sarcastic?
Yeah I think its better to release product later with working drivers than have product released but 5 months without drivers
- Status