R520 Infomania

"Adding SM3.0 etc." isn't necessarily a trivial task; does it stand to reason that the pipeline structures will be the same as the old architecture even if they are not in a unified architecture?

 

thanks for clearing that up..

 

All I know about R520 is that I can't go out buy one right now nor do I see any official technical description. Until than, I know nothing. No speculating on my part.

About the clock difference, you have it right now with GF68U and X850XP - which perform roughly the same. So that means nothing as such.

 

I heard a big game developers studio (that I'm not going to name here) has some G70 prototype (and R520 prototypes too) since March.
If this is true G70 is around way before the last tape out The Inquirer wrote about.

 

I have no idea how complicated it may be, but in such case I'd speculate that the structure won't be fundamentally different than before in case you're talking of quads. Even if should be, where should the speed increase come from in that case? 16 pipes are 16 pipes after all. Come with a 24 or 32 pipes part and you'll stomp all over that, even if less efficient. All IMHO, of course...

 

Let me do it for you: Valve, id, Epic

 

Crytek.

Jawed

 

I don't expect the performance ballpark between R520 and G70 to be much different than today to be honest.

My example merely showed how you can reach equivalent fill-rates with a high clockspeed and the same amount of quads as today or alternatively the same clockspeed as today with more quads than today.

As for the non-unified units, if reliable sources claim that there's still some heritage in R520 from R3xx/4xx, chances are higher that it didn't inherit SM2.x.

 

That's a different story then.

_xxx_,

Higher clock speeds. 650-700MHz isn't exactly low for SM3.0 level of complexity.

 

How do you reconcile that with you previous comment regarding NV40 and R420 and clockspeed not being everything? That was precisely the case. Take a look at the GammaChrome review today - 4 pipes are 4 pipes, right? Of course not.

Pipelines mean very little these days. Its whats going within those pipelines and how many ops per cycle they an achieve that is rapidly becoming more important.

 

OT: a Gammachrome review? *runs to read it* 8)

 

I wonder if Dave's hinting at a shader-pool architecture for the pixel pipelines. Not unified shaders, since they're exclusively for the use of the pixel shaders.

The vertex shaders are organised as per R420, but with texturing of their own.

If R520 took the R500 approach of a queue of pixel shader command threads, and allocated them to the ALU or the TMU according to the code, R520 could deliver a formidable texture-latency hiding mechanism. For something this complex, ATI may well be forced to stick to 16 pipes.

What happened to those rumours about R500 being a hybrid?

Jawed

 

I'm not hinting at anything, I'm just trying to get across that increasingly "comparing pipeline numbers" is going to tell us less and less about the performance of a part, especially when we are talking about one unannounced/unreleased part to another unannounced/unreleased part and no understanding about their architectural nuances.

 

I think he's hinting at there being more ALU's per pipe. ATI have been talking about this for a while, right (there was some slides floating about somewhere)?

 

Interesting notion, but at least those 16 pipes should perform a hell of a lot better than the current 16 pipes if true.
(I think, I'm a tad in over me head here. )

 

That's an argument...

 

They were talking that math/texture ops ratio will increase in the future(have to increase). Currently they recommend 4:1 math/texture ops(1 bilinear fetch) looking at asm. It means if you are doing trilinear or aniso this ratio might be higher like 8:1 currently to get a good balance.

Looking at the r300 architectur considering r520 is based on it the most obvious thing they could to is adding some more functionality to the mini ALUs not necessarily upgrade to full ALUs but give them a little more than current ones and that with the higher clock speed should give them already a nice increase overall in shader output

 

That's the first thing you've wrote in this thread that I actually understand clearly!

(I speak emoticon pretty good, even when it's the rare Baumannese emoticon dialect. )

 

Funny that, Beyond3D has a front page.