R520 - talk, rumours, speculation; the lot!

It seems inconceivable that if there is indeed any change to the die size that it could possibly be a feature change. No, if this is true, it is most likely a fix in the latest respin to get yields to where they should be (some sections of the die may have had too many transistors/area, for example, and thus gotten too hot).

Edit:
Better yet, maybe somebody just misread the ruler.

 

Maybe millimeter instead of cm...

 

Noone got it...

 

If there was a change in die size then the revision would no longer be A1x but A2x or Axx as a dies size change would indicate a silicon change as well.

 

Don't know if this has been posted yet - if so my apologies; it's a long-ass thread and I could only bare to go back three pages worth to check.

Haven't checked in on the R520 in a couple of weeks, but found this today to be fairly interesting.

Looks like HKEPC got a hardware sample of the R520 and did some benchmarking, although they are not at liberty to disclose their numbers just yet. They also imply that there *will* be 24 and 32 piped versions of the chip, and at the same time seem to indicate that the 16 pipe version won't exceed the performance of the 7800 GTX.

Anyway here's the 'preview,' written in English by HKEPC - which is pretty rare for them to be sure.

http://www.hkepc.com/hwdb/r520firstlook-e.htm

 

Ah, good point. Somebody must've misread their ruler (or calipers, if they were actually attempting to be careful).

 

It just doesn't sound right that there would be 16, 24, and 32-pipeline versions all of the R520. If they exist, you'd think they'd take on different model numbers. I think we've confirmed that so many disabled pipelines on the R520 is ludicrous.

 

I agree on that point - maybe they mean R580 and are just using R520 as the designator for ease of refering to the architecture?

But whatever the case, it certainly seems that at least somewhere along the line there either are... or were... plans for a chip with a greater number of pipelines.

I guess we'll see how it all plays out in the end.

 

Who's claiming that external bandwidth will be increased?

The only claims about external memory are to do with a finer-grained access to memory. 8x32 instead of 4x64.

Jawed

 

32/24 pp theory isnt correct. (for the nth time)

Mr. HKEPC confirmed a 3dmark05 score of 8600.

 

Interesting to see UMC making thier flagship.

 

Assuming we're talking about the same chip, of course?

 

Serenity I'm just going with what the article says. Since Mr. HKEPC is responsible for both claims, I don't know why you accept one so readily while tossing out the other. Like I said before, it's not that I think R520 itself will have locked off pipes - rather that I think R580 will have a greater number of them.

EDIT: And remember that 'confirmed' 3DMark05 score was in reference to a 10vs24pp configuration - a configuration you believe not to exist. I mean not that I believe it exists either mind you. It's just if I'm going to 'trust' anyone, it might as well be the people who have their hands on the card and are in touch with the card manufacturers directly.

 

Right, and so what's the point?

 

Increasing the internal bandwidth? Sounds good to me...

 

But internal bandwidth shouldn't a problem with GPU's anyway. I can see this as being a nice move for a general-purpose processor like Cell, but for a GPU, well, it just seems silly.

Consider, if you will, that GPU's are still processors dedicated to very specific tasks. It is extremely easy to predict at the design time of the processor just how much bandwidth is going to be needed between the various parts. So any design that doesn't have enough bandwidth at design time is basically a broken architecture. I don't see a ring bus as solving this problem.

 

Is that really the case when you bring conditionals / branching into shading? Seems to me that the more "general purpose" GPUs become, the more it makes sense.

 

But what if a ring:

• reduces latency for the most bandwidth intensive tasks (ROPs)
• reduces space consumed on the die compared to a bus (or busses)
• increases bus concurrency meaning that average intervals between accesses are shorter, even for low-priority transfers, hence allowing reduced buffer sizes

The list prolly goes on.

Jawed

 

Show me where HKEPC claimed that the 16pp R520 was slower than 7800GTX. I think its your wishful thinking that you interpreted their ending statements. Read it again.

Like Dave already pointed out they may not have the drivers etc., to know the amount of pp by the time the article was done. They may have had it up and running later and may have ran a couple of tests. Also note that the admin doesnt say that the 8600 score is 24pp* or the clocks or both*.

*I do not believe that there are 32/24pp configurations of the R520 and am using it purely from a hypothetical point of discussion.

Can we please end the 32/24pp discussion now ? Thanks.

 

Actually, Chalnoth makes a good point here.

The most bandwidth intensive operations are simple old school shaders: single texture alongside some register combiner math with per-vertex values like diffuse and specular. The sheer throughput of one pixel per cycle makes this very bandwidth intensive, and if you cover this case, you won't have any problems with more advanced shaders.

My guess is this "ring bus" (is it even confirmed that it's used in R520?) makes it easier to share texture units (and possibly some math units, who knows) between the VS and PS. Bah, I need to read more about what's going on with these theories and rumours.