[RoOoBo]

There are caches and buffers between the texture units or the ROPs and the memory controller. They can hide the fact that the pipelines are reading or writing less data than the minimum memory transaction. Of course larger buffer or cache lines are inneficient if not enough parts of those lines are 'touched' by the fragments being processed.

However the minimum transaction size coupled with compression algorithms and 'inexperience' can produce some 'weird' results. For example DXT1 has a 1:8 compression ratio, a DXT1 block is 8 bytes, the mimimum transaction is 128 bits, there is no L2 cache, data is decompressed to the texture cache and the texture cache line size is 64 bytes. Guess what happens

[Ailuros]

Originally Posted by Jawed

Well the decouple pipelines I'm thinking of in R520 are, like Xenos, dependent on the scheduler.

Since I'm expecting the scheduler to "smooth" the peaks and troughs of texture demand by "re-ordering" 16-way texture operations, I don't see how R3xx-R4xx style partially decoupled texturing is relevant.

Those earlier GPUs can't re-order texture operations to fill time when the texturing pipelines would be otherwise idle. Decoupling in Xenos provides that ability (in addition to ensuring that other batches of fragment shading can swap-in while batches are waiting for texture results), and I'm speculating that R520's fragment-shader scheduler will do the same.

It's all about increasing utilisation, both for the shader pipelines and the texturing pipelines. Out of order fragment batch scheduling suits both, as far as I can tell.

Jawed

I think by now it should be perfectly clear what I was trying to get at. This so and so many pipelines nonsense has to stop some time. What matters is what comes out at the other end and while I expect R520 to be a highly competitive part compared to G70, I simply cannot see a "G70-killer" everyone has been hoping for. This "24/32 pipe" nonsense doesn't by far help anyone, in the very least the main interested party which is ATI in this case.

[kyetech]

Good God,

This thread has become the second biggest thread in the 3D hardware forum ever.

and is 200 replies and 40,000 views from being the biggest and most viewed thread in the 3D hardware forum EVER !!

hehe

Just thought Id share that with you all.

[digitalwanderer]

It's about to disapear, I HATE IT when people delete me posts without telling me.

[Geo]

Yes, well, I like the name change but we really should pinch it off about five pages ago and start a new one from there.

[digitalwanderer]

Originally Posted by geo

I like the name change

I don't.

[CMAN]

Originally Posted by geo

Yes, well, I like the name change but we really should pinch it off about five pages ago and start a new one from there.

I second that notion.

[IbaneZ]

Originally Posted by digitalwanderer

I HATE IT when people delete me posts without telling me.

The size tag si teh evil!!11

[Bowen]

Originally Posted by Jawed

We're talking pixel pipes - so no need to get "clever".

Also, what are the disadvantages of de-coupled pipes?

Jawed

I sorry, I just a caveman and I don't understand big words like cache and buffer and fragment pipes and ROP. All I know is better play game fast. If game don't go as fast as G70, me get angry. Me get angry for waiting on ATi waisting my time. On otherhand, ATi make me happy if faster than G70. Me want R520 much faster and R520 XT better be at least 24 pipe but hopefully 32 pipe card. More importantly, it better be out soon or caveman smash ATi headquarter. Make people go ARGGGGHHHH!!!

[Geeforcer]

Originally Posted by kyetech

well since the NV45 has

222 million transistors @ 287mm² @ 130nm

http://www.beyond3d.com/misc/chipcom...r=Order&cname=

I would say that 90nm 288mm² chip would offer around :

463 million transistors :

?

Any 1 care to develope on that?

We know that R520 is larger then NV40, despite using a much smaller process (288mm > 287mm; .9 <<< .13)

We also know (despite some ass-covering by certain sites) that it has been a 16-pipeline design from the get-go.

So, what taking up the rest of R520 monster die? SM3 logic? Extemeness of pipelines? Large caches? Flux capacitor? My inability to solve the R520 die size mystery has been driving me (and few other people, lol) crazy.

[Verte[X]]

Originally Posted by Geeforcer

We know that R520 is larger then NV40, despite using a much smaller process (288mm > 287mm; .9 <<< .13)

We also know (despite some ass-covering by certain sites) that it has been a 16-pipeline design from the get-go.

So, what taking up the rest of R520 monster die? SM3 logic? Extemeness of pipelines? Large caches? Flux capacitor? My inability to solve the R520 die size mystery has been driving me (and few other people, lol) crazy.

As I told a few posts ago... Due to my computations, R520 should have about 230M transistors. That is just enough to implement SM3, new memory crossbar controller and fragment pipeline optimalizations.

The big difference here is the manufacturing process at ATi and nVidia. Just look at the numbers - NV43/110nm/143M/150mm2, R430/110nm/160M/240mm2 and so on (17M and 90mm2? Gosh!). Do you see?

[Xmas]

Originally Posted by Verte[X]

Well... R420 to R430 process shrink means at the same transistor count die size shrink from 281 to 240 mm2, that means about 1,17x which roughly appends to 130/110 ratio. If you have 110/90, it's cca 1,2x smaller die size and therefore 160M transistors (as R420/430 have) would be around 200 mm2. So, 288/200x160 is 230 million, right?

No, because it's an area, with 90nm you can have 110²/90² = ~1,5 times the transistors per area as with 110nm.

[Geo]

I come in around 320-360m on that die size (if it is accurate) and compared to R420, if I use Wavey's (320m) or Orton's (360m) description of size of R420.

And, yeah, that's too many "ifs".

[Geeforcer]

Originally Posted by geo

.... if I use Wavey's (320m) or Orton's (360m) description of size of R420.

I am not sure what those numbers (320m/360m) represent in relation to R420.

[Geo]

Originally Posted by Geeforcer

I am not sure what those numbers (320m/360m) represent in relation to R420.

They are extrapolations to R520 based on R420 die size as reported by those two sources. Wavey reports a bigger die than Orton for R420, so Orton's number goes higher when extrapolating to R520.

I suspect that aside from just insconsistencies, there must be some margin around the die itself in these packages that add to the typical heartburn we all end up with over these things. Orton (in my theory) doesn't include it --Wavey with his calipers does.

[Geeforcer]

Originally Posted by geo

They are extrapolations to R520 based on R420 die size as reported by those two sources. Wavey reports a bigger die than Orton for R420, so Orton's number goes higher when extrapolating to R520.

I suspect that aside from just insconsistencies, there must be some margin around the die itself in these packages that add to the typical heartburn we all end up with over these things. Orton (in my theory) doesn't include it --Wavey with his calipers does.

I myself have in 260-270Mt range based on rather low transistor density of R4xx series. Still, that represents a 40-50Mt transistor increase over NV40 (a 16-pipe SM3 chip). Anyone wants to hazard a guess what they are for?

[Geo]

I'm not *real* comfortable with the reported die size yet myself, and was hanging out in the 280m range before pics started showing up. Soon. . .soon.

[Chalnoth]

If true, the large die size may just be a result of design decisions ATI made that have resulted in the supposed high clockspeed of the part.

[CMAN]

Originally Posted by Chalnoth

If true, the large die size may just be a result of design decisions ATI made that have resulted in the supposed high clockspeed of the part.

I'm confused why a larger die would allow a high clockspeed.

[Verte[X]]

Originally Posted by Xmas

No, because it's an area, with 90nm you can have 110²/90² = ~1,5 times the transistors per area as with 110nm.

I know it's an area, but you didn't read the post carefully, did you?

Originally Posted by Verte[X

]R420 to R430 process shrink means at the same transistor count die size shrink from 281 to 240 mm2, that means about 1,17x which roughly appends to 130/110 ratio.

IF the die size was dependent on process square ratio, the transition from 130nm to 110nm would mean 130²/110² = ~1,4 times smaller die. But it obviously ISN'T that smaller but only, as I wrote, about 1,17x. How do you explain that?

[digitalwanderer]

Originally Posted by CMAN

I'm confused why a larger die would allow a high clockspeed.

Bigger = gooder, silly.

[Geeforcer]

Originally Posted by CMAN

I'm confused why a larger die would allow a high clockspeed.

Larger die = bigger surface area = better thermal transfer properties.

[Arty]

Originally Posted by Geeforcer

Larger die = bigger surface area = better thermal transfer properties.

Also larger die can have a bigger memory bus (or a new memory bus design?)

I am not implying R520 is 512bit though.

[digitalwanderer]

Originally Posted by Peace Angel at Elite Bastards

ATI's X1800, X1600, X1300

Well, these are the final names.

Yo Rys.....

[Nite_Hawk]

Originally Posted by Geeforcer

Larger die = bigger surface area = better thermal transfer properties.

But longer distances that need to be covered inside the chip?

Nite_Hawk