G80 vs R600 Part X: The Blunt & The Rich Feature

He who dies with the most frames wins.......

 

When you aren't TMU limited, it does almost pan out:
http://www.ixbt.com/video3/images/rv670/d3drm-ps-2.png
(320 SPs at 775MHz vs. 112 SPs at 1500 MHz. Still waiting on GT200 and RV770 reviews...)

In terms of TMU count and poor design, you can easily look at it the other way around. NVidia devotes as much space to TMUs as it does to SPs, as you can see from the die shots. There will be many times where NVidia's TMUs will be sitting idle waiting for the SP's to reach a texture instruction.

What do you define as "paper spec margin"? I can say the GTX 260 should beat the HD4850 by 47% according to texture rate.

Like I said, I agree with you. I think there are plenty of posts in this thread from me arguing with Jawed.

Basically nobody expected ATI to improve like this. My best guess was 32 TMUs, 480 SPs in 300 mm2. I gave up on ATI's competitive ability after R520, and though a little respect was restored with R580 (and lost with R600 and restored with RV670), I figured NVidia would always have the upper hand.

I'm sure NV figured R600 was way less competitive than it could have been given ATI's TMU and ALU density in R580, but once RV670 came out they probably thought all major improvements were exhausted. After all, NV couldn't get any significant density improvements from G80 to G92 to GT200 aside from process scaling.

There's no real mystery behind GT200. I'm sure they have plenty of fine-grained redundancy as well, and they could probably sell it to AIB partners for well over twice the price of G92. I think GT200 would have been high margin if RV770 wasn't around, but it came down upon them like a ton of bricks.

Now they're really screwed. Instead of the 9800GTX being worth $300 (maybe $80 per chip), it's worth $200 (maybe $50 per chip). Instead of the GTX 260 being worth $450 (maybe $150 per chip), it'll barely sell at $400. Etc, etc.

This repricing hits the huge chips the most for obvious reasons.

 

Exactly my thoughts, now if we could start to (at least) move texture filtering over the shader cores so that we can trade TMUs area for ALUs area.. sorry I couldn't resist

 

Yeah, it's not happening. Transferring the data alone will require signficantly more complex shader cores if you want to retain performance. In fact, I bet this would cost more than the filtering math.

Filtering arithmetic logic operates on fixed data paths, so it's really cheap. Even if you could remove it, you still need to keep the addressing, caching, decompression, LOD, aniso calcs, gamma correction, etc. All you're saving is a few 8-bit MULs and ADDs (plus whatever logic is needed for reduced speed FP16 and FP32) per texture unit.

My guess is <10M transistors for the lerping logic in the filter units of G92. A drop in the bucket. Moreover, having the filtering run in parallel is great for shader utilization when multiple cycles are needed.

EDIT: There is one glimmer of hope for ATI cards, though, because they spend a lot less area on TMUs than SPs. Each quad of TUs services 80 SPs. How do you feed them data for vertex shading? The point samplers are no longer there in the diagram...

 

IIRC rv670 and rv770 have full speed FP16 filtering

 

RV670 has.

 

cho's #s agree with Carsten.

 

Would an entire SIMD's worth of ALUs be needed for the given TMU capacity?

If not, it's a bit of a waste.
In the interests of geography, it would seem more tempting that only a few processor clusters nearest the texture caches would be merged with the texture cluster.

 

Yeah, I know, I was just trying to keep my sentence short.

Hmm, good point. Nonetheless, it still complicates TMU design in the output to the shader, even if I was wrong about needing more inputs to the shaders.

As an aside, I still don't understand why the RBEs are used to feed data back to the ALUs. It's not like you can Load() from the current render target, and it just makes sense to use the TU because it really is just like a texture fetch. Moreover, aside from this functionality, data is always flowing out of the ALUs and into the RBEs.

Maybe gamma correction is underused, but decompression absolutely must still be free to maintain performance. Same with LOD.

In any case, the point is that filtering math is a small part of a TMU. I only mentioned those things to dispel the notion that a significant chunk of the ~150mm2 devoted to "texturing" in the clusters (as per the diagram) is due to filtering logic. That's probably why nAo made the suggestion.

 

Low ALU:TEX = brute force (G8X)
Low TEX:ALU = elegant (R6xx)

/boggle

 

Mint: then we have to put to some use those LOD/texture addressing and texture fetching units

 

Would a test count in your books, where the pure pixel shaders have been grabbed from a real game, run through a fillrate-meter and then been normalized in relation to a given card?

 

How is that supposed to improve anything?