Significant IP blocks are developed in TO and contribute to just about every ASIC.
AMD: R7xx Speculation
- Thread starter Unknown Soldier
- Start date
- Status
Yes, im quiet shure.
So they're saying ATI made this decision roughly just after R580? That's interesting. That would be after the discussions with AMD began (Dec 2005), tho before they were consummated (July 2006). And possibly nearly simultaneous with when the decision was made to go forward with the AMD marriage.
Remember the AMD/ATI merger briefing docs and the pics of the multiple gpu boxes for high end and whether that meant anything for real or was a representation of x performance?
Well, ATI had a lot of catching up to do with multi-gpu. About two years worth, probably. They seem to have largely done it now tho. Altho. . aren't we still waiting for the profile editor that Terry finally conceded they needed about 18 months ago?
Tho personally I've yet to dip toes in that water, and there are still considerable downsides to multi-gpu, some of which likely won't ever be entirely conquered.
My guess: not in the center
.Seriously though I can't spot much on that die shot apart from the 10 shader clusters - where are the 4 rop blocks, for instance?
Even the shader clusters remain mysterious: seems to me there are 4 blocks (with 4 vec5 alus) starting from the right (lighter areas are cache? Register file?) Then comes another smaller block - TF? - followed by another - TA? - and to the left of each cluster (the biggest block) is thread arbiter and stuff?
Hmm....
leoneazzurro
Regular
As far as I can tell, there is no more the "ring" but there is the "bus"
So there should be also the bus stops.
PS: I was just thinking that RV770 is in some way a more radical departure from the RV670 architecture than GT200 is from G92... I think it will need a lot of time for the driver time to optimize for it (and they will not be at ease with so many TU at disposal.. maybe they will continue to use only 16 until they will not gain enough practice
)
Strange - until very recently i was (supposed to be...) under the impression, that a ring bus MC was to deliver a much more efficient memory architecture than an old-fashioned crossbar-controller.
Remember that most of the time caches in GPUs are there for very different reasons for caches in CPUs. It's more about input/output streaming, latency compensation and bandwidth optimisation. Classic % hit rates just aren't relevant - miss with every access and it will still run at full rate. Reuse tends to be intensely localised (e.g. bilinear filtering reading 4 values and the next texture fetch happening to need 2 of those again) rather than 'now and in 1000 cycles time'. And the cache is sized 'just right' because for a given scenario there is an optimum size above which more makes no difference...
Yes, cause AMD said so. But theres a reason why the changed it. And i didnt say that it will be old-fashioned
leoneazzurro
Regular
There is not (only) the crossbar AFAICT there, there is another interconnection bus that has no more the form of a ring, if the diagrams could be trusted.
I heard the reason is that to connect more than 4 SIMD, a ring bus is not very efficient, whereas the new interconnect is.
Mintmaster
Veteran
Now that we have better die shots, I found that the ALUs on RV770 occupy either 28.0% or 25.3% of the die, depending on whether that similar looking sliver next to the left of the 4x10 array is redundancy or not. Feel free to update your numbers.
Anyway, a quad of 5x1D units, capable of 20 MAD/cycle, is 1.8 mm2.
An 8x1D SM on GT200, capable of 8 MAD+MUL/cycle, is 5.1 mm2. Maybe 4 mm2 on 55nm.
That's pretty remarkable. Even for serially dependent scalar instructions and 20% efficiency, ATI's ALUs can do as much per clock per mm2. If ATI can figure out how go asynch and double the clock without doubling the size for next gen, we'll be looking at insane computational density.
We're already talking about 100 flops and 2.5 texture accesses per pixel at peak color fillrate.
EDIT:
Bad mistake. I fixed my numbers.
Last edited by a moderator:
Looking at the physical size of the arrays gives me pause.
Which is harder to upclock, the superscalar arrays that span most of the chip's width or pretty much every other portion of it?
Nvidia likely kept their SIMD widths small and the units scalar just for this reason.
Which is harder to upclock, the superscalar arrays that span most of the chip's width or pretty much every other portion of it?
Nvidia likely kept their SIMD widths small and the units scalar just for this reason.
Doesn't look like a redundant part to me. It's similar but clearly different to half-a-quad 5x1D unit (for a start it's less than half the size).Now that we have better die shots, I found that the ALUs on RV770 occupy either 28.0% or 25.3% of the die, depending on whether that similar looking sliver next to the left of the 4x10 array is redundancy or not. Feel free to update your numbers.
shouldn't that be 20 MAD/cycle?
Well yes but designing the ALUs for twice the clock would surely make them bigger - maybe not quite twice, but by a significant amount.
(As a side note, if you'd compare a 9800GTX+ vs. HD4850 the G92b alus now run at _three_ times the clock of those of the rv770...)
I don't know if the ALUs are the primary problem. It's the control logic and signal distribution.
For reference, Itanium is the widest VLIW chip I can think of, with an issue width of 6 at ~2 GHz.
One SIMD array is equivalent to a sustained issue width of 5 ALUs, 1 branch X 16 =96.
It's not apples to apples, but there's no getting around the fact that 1/10 of RV770's ALU resources is sixteen times as wide as Itanium.
Nvidia's SIMD arrays are much more narrow.
Larrabee, will allegedly have a SIMD unit with much more restricted data flow 1/5 or 1/6 (don't know about the branch unit) as wide.
The SIMD sequencers would probably blow up in size faster.
- Status
