R600 how many pipes

[Turtle 1]

I keep hereing R600 is a 48 pipe unified arch . At other forums . I read that its a 64 pipe unified tek. Any one heard anything? I have no interest in the R580 as I posted what it was going to be before R520 was released . Even though I believe there a little more to R580 than whats been discussed.

 

[MuFu]

No pipes.

 

[Turtle 1]

Ok no pipes How many alu's than

 

[Farid]

Seeing the commitment of Ati to HDTV, I wonder how many ROPs the thing will have.

 

[fellix]

May be it's time for eDRAM, if we want some ROP rate increase - I don't see how, even a fast external gDDR-4 frame buffer, would satisfy HD modes with mucho MSAA and z/stencil op's, unless everybody goes for SLi/XF.

 

[no-X]

I keep hereing R600 is a 48 pipe unified arch . At other forums . I read that its a 64 pipe unified tek. Any one heard anything? I have no interest in the R580 as I posted what it was going to be before R520 was released . Even though I believe there a little more to R580 than whats been discussed.

Xenos = 64 unified shader units, built-in "northbridge", no ring-bus, no Z/Stencil units ~ 230MT
R600 = ring-bus(?), more complex ROPs, w/o northbridge, lets say 400-550MT, so I would expect around 96 unified shader units

 

[Dave Baumann]

Xenos is 48 ALU's. I think it would be safe to suggest soething more than that for R600

 

[no-X]

Xenos is 48 ALU's. I think it would be safe to suggest soething more than that for R600

48 in hardware?

 

[pc999]

Xenos is 48 ALU's. I think it would be safe to suggest soething more than that for R600

But Xenus does have 16 disable for redundancy (total of 64), Right?
If it does, the 250M number includes it right?

 

[Moloch]

Pipes is such an old term.
Why we still using such a dated measurement?
Given we already have a card on the market right now they redefines "pipes" and one coming out soon which does the same thing, using pipes to compare graphics cards can get confusing.
We already had the G70 have more FP then rops,as with the the NV43, ati just took a step futher by decoupling texture units.
We can see with the X1600 it doesn't behave like you would expect a 4 pipe card to, but it also doesn't behave like you would expect a 12 pipe card, so really using pipes is meaningless at this point.
Am i right?

 

[Megadrive1988]

R600 should have between 64 and 96 unified shader ALUs compared to the 48 in Xenos.

the concept of pipes will be completely thrown out the window with R600, like it has with Xenos, and unlike R520, R580.


I predict R600 will have at least 24 ROPs and 32 texture units

 

[Jawed]

Well, what'll be really interesting to see is if R600 duplicates the "wide" shader array we see in Xenos. 16-wide (or wider). It's easiest to see the texture array as defining the width of the architecture.

If you look at R580, for example, you could say that it has four "mini" shader units inside it - each consisting of 3 shader arrays and 1 texture array - 4-wide. It's not a big step to think of these as four mini-Xenoses, but obviously without vertex shading. Thread scheduling/load-balancing in each of these shader units is independent of the others.

To me there's a conflict between the locality that ATI's traditional backbuffer tiling requires (with nominal 16x16 tiles) and the irrelevance of locality when processing vertices. So the tiled approach that we see reflected in the four shader units of R580 may not suit the organisation of R600, once vertex (and geometry) shading is taken into account. On the other hand, vertices generally gain no meaning when joined-together in a thread as they do in Xenos. So both approaches seem to work against vertices. Confusing...

32-wide for R600 has a sort of appeal to it: three arrays of 32 shader pipes and one array of 32 texture pipes.

Alternatively R600 may push for a higher-than 3:1 ALU:TEX ratio. This would make the arrays narrower - e.g. six arrays 16-wide with one 16-wide texture array. 16-wide would also keep threads to a reasonable size - if four phases are required, then the thread size would be 64.

The L1/L2 cache patent that surfaced recently would sort of imply that texturing is going to be shared across the entire chip making wide arrays more likely. L1 would support the currently active thread (which would require texturing over many passes), while L2 would support the multitude of threads that are in the current work queue.

Jawed

 

[Moloch]

R600 should have between 64 and 96 unified shader ALUs compared to the 48 in Xenos.

the concept of pipes will be completely thrown out the window with R600, like it has with Xenos, and unlike R520, R580.


I predict R600 will have at least 24 ROPs and 32 texture units

Well what I meant is that the 1600 can't be called a 4 pipe card despite 4 tmus since it has 12 shader units, but its' not a traditional 12 pipe card either.
So really you can't compare like the X1600 and a 6800gs/nu.

 

[turtle]

First of all, I bet you'd like my screenname...Sorry, it's not for sale.

I think R600 will be like many others have said, 32rops, 3 ALUS per rop, with 32tmu's and 64 shaders. In theory, that should be quite efficient.

While before the full disclosure of R520/R580's arch, that old rumour of R600's specs seemed odd (http://www.cdrinfo.com/Sections/News/Details.aspx?NewsId=14184) but now it seems possible, considering the freq that was possible with 90nm, where GDDR4 is heading, and how Xenos FWIU uses 3(4) alu's per rop (one for buffer so really 16x3) No doubt R600 will use a combination of R520/Xenos tech...So 64p/32t seems possible with 32 (32x3) Rops. It'd also put it at an interesting 2:1 ratio...being somewhere inbetween the current 1:1 of R520, and the future 3:1 (R580) and 3:2 of G70,(and G71?[32/24], G80 [48/32]?) ratio we've got going now.

Perhaps what I said doesn't make sense, I don't know all the logistics as well as the hardcore here, but from what I gather it seems possible...and could be damn powerful.

 

[Ailuros]

I just read a couple of tidbits about D3D10 requirements in the 3DCenter forums. Nothing very specific but the general consensus seems to be that the added requirements add quite a bit of extra complexity.

Personally I'd wait the above to clarify a bit further in the foresseable future, before I'd speculate what is or isn't good enough in terms of amounts of units for any D3D10 GPU.

 

[boltneck]

I think R600 will be like many others have said, 32rops, 3 ALUS per rop, with 32tmu's and 64 shaders. In theory, that should be quite efficient.

So you think they are going to go from 16 to 32 ROPs in one generation?

Xenos is capable of HD with only 8 ROPs (with the help of its eDram). I would expect R600 to have 16 ROPs just like the current generation. The major changes will be how the rendering blocks will be arranged, and how data is moved/accessed between the blocks. R600 will differ from Xenos in a number of ways, but basically it will add a 4th rendering block, giving it 64 ALU's.

 

[no-X]

It's not much... R580 has 48 pixel shader units and separated vertex shader units. R600 is unified, so when we would use 16 units for VS and 48 for PS, it would be very similar to R580. And "only" 48 pixel shader units + 32 ROPs and 32 TMUs? I don't believe it.

 

[Jawed]

It seems to me that in general there's an upper limit on the number of TMUs and ROPs for a certain amount of available bandwidth.

Sure, different kinds of rendering will consume wildly varying amounts of bandwidth in those operations, but there are diminishing returns - e.g. 32 ROPs with 30GB/s of bandwidth is overkill (unless the GPU is doing Z-only fill and doesn't have double-rate Z).

Having said that, by the end of the year we should have graphics cards with ~75GB/s available. Perhaps 90GB/s. So clearly there is room for more TMUs and ROPs.

Unless:

• geometry shading consumes a lot of bandwidth (2-pass GS may well do so!)
• enhanced TMUs (with more cache?) can suck in even more texture data (FP16 textures become more common?)
• enhanced ROPs (e.g. X1600XT's seem fairly beefy) can chew through more bandwidth than we're used to

Jawed

 

[Arun]

I feel being able to do 64 Z-Writes/Reads per clock, when working in 4x MSAA, would be a very worthwhile venture once you've got GDDR4. That is, if geometry isn't your bottleneck, although with an unified architecture, it just isn't going to be (triangle setup could be, though!) - IMO, it's unlikely to happen though, but still some rather nice improvements in such situations would be nice.

Personally, I'm more than tired of Z-Passes being a win for half the cards within a SAME chip family and a loss with the other half (some NV4x really aren't that impressive with Z-Only IIRC). I hope it isn't too much to ask for that to have semi-coherent performance characteristics for a single architecture family...

Uttar

 

[Dio]

the concept of pipes will be completely thrown out the window with R600, like it has with Xenos, and unlike R520, R580.

Well, the concept of pipes as the term is usually used on the Web disappeared in about 2001