G70 memory controler

[Richteralan]

yeah agree - it seems to be a game of leapfrog on that one. The nforce2 memory controller kicked arse for the day. I haven't kept up on the Intel side but it's interesting the nforce4 was comparable performance wise with intel's memory controller. I will have too check now but intel, ati and nv all have products that can be compared.

I doubt the ring bus is on radeon express products but it's interesting too me none the less.

nforce 4 doesn't have memory controller in it.

AMD64 CPUs integrated memory controller.

 

[KimB]

nforce 4 doesn't have memory controller in it.

AMD64 CPUs integrated memory controller.

Intel edition does.

 

[Geo]

I'm not sure thats the case, I'd say their focus was on both - remember, its talking about removing the wire density away from the memory controller; the memory controllers are usually running at the memory rate rather than the core rate.

This is the core conflict in my own mind over just what-the-heck-all that gehenna big square of silicon is in the left-center of the R520 die shot. It's being called "the memory controller", and yet we also get phrases like the one bolded above. Combined they do a nails-on-the-blackboard thing in my brain. . .

 

[Jawed]

Changing the subject slightly, is the fancy new memory controller and ring-bus going to be a part of mobile GPUs any time soon?

Jawed

 

[AlphaWolf]

Changing the subject slightly, is the fancy new memory controller and ring-bus going to be a part of mobile GPUs any time soon?

Jawed

Well if they are going to have new parts for the mobile space, an rv530 variant seems likely.

 

[rwolf]

Isn't the change in the mem controller for DDR4 compared to DDR3 rather incremental (= not really huge)? It's not like it's a completely different technology. Anyone in the know?

GDDR4 will clock very high. The transfer rate is 56% faster. It is implemented the same as DDR3, but it scales much better.

 

[fellix]

That hunk of silicon, more or less in the centre, is the memory controller, so I'm told.

I doubt, that this block is something to do with MC. Just look at the uniform structure of the pattern inside of it - it's more like the massive fragment register array present in R5xx needed for ultra-threading dispatching, I think. Or it's missleading to me?!

 

[KimB]

I doubt, that this block is something to do with MC. Just look at the uniform structure of the pattern inside of it - it's more like the massive fragment register array present in R5xx needed for ultra-threading dispatching, I think. Or it's missleading to me?!

ATI has said it's something to do with the memory controller. My guess would be it's the equivalent of L2 cache.

 

[aaronspink]

I doubt, that this block is something to do with MC. Just look at the uniform structure of the pattern inside of it - it's more like the massive fragment register array present in R5xx needed for ultra-threading dispatching, I think. Or it's missleading to me?!

There appear to be 8 identical blocks within there which would correspond well to 8 identical memory controllers. Memory controllers tend to be fairly regular and dense inside with large queue like structures for both data storage and timing control.

Aaron Spink
speaking for myself inc.

 

[Mintmaster]

fellix, it's really not that big if you measure it. It's about 10% of the die. Given the AA improvements we're seeing, and that halving it would buy you at most 2 pixel pipes, it was a very good decision. I suppose some of that block could be Hi-Z memory.

All the stuff you're mentioning related to the pixel shader is probably why each quad is so huge.

 

[Dave Baumann]

HiZ is part of the quads.

 

[Geo]

fellix, it's really not that big if you measure it. It's about 10% of the die.

My first reaction was that you were off your rocker. Tho of course I'm too polite to have said so directly. So I fired up an image program, checked the number of pixels for the whole image, cropped that section (twice --for smallest and largest), and damned if you aren't right.

 

[fellix]

OK, I've made a quess-overlay of the R520 die, based on similar blocks. So the green squares, I presume, are the fragment quads, what about the others - tex samplers, vertex shaders... and where would be the dispatcher? And the border wiring around the die should be the ring-bus.

 

[CarstenS]

I've added another three (?!!?) sections, that very much look alike:

I have to admit though, that i have no idea which functional unit might be integrated three times other than these being the Ring-Bus-Memory-Controller "Bus Stops" with the fourth being integrated into the main controller.

 

[no-X]

fellix: this colored one could be helpful (taken from another thread):

 

[Mintmaster]

HiZ is part of the quads.

I know the actual Hi-Z testing is, because each quad can reject a 4x4 block of pixels per Iclock. (BTW, thanks for still putting things like gl_ext_reme benchmarks in your reviews, because it's great for accurately showing Z-reject performance. I got 240 pix/clock for R420 and R520, 65 pix/clock for G70).

I was talking about the on-chip Hi-Z memory to hold the min for each 4x4 block. You also need to store the Z and colour compression state for each block, so you know how much memory to fetch. This may only be a few million transistors (depending on Hi-Z precision and whether min-max was implemented), but should be visible.

Hmm. Now that I think about it, each quad could have a fixed screen tile allocation, and that would make sense given the patterns people see when they unlock broken pipes. So if the Hi-Z memory is indeed inside each quad, can anyone spot it? I'm guessing around 0.5-1% total die space for this memory.

 

[Mintmaster]

My first reaction was that you were off your rocker. Tho of course I'm too polite to have said so directly. So I fired up an image program, checked the number of pixels for the whole image, cropped that section (twice --for smallest and largest), and damned if you aren't right.

It's quite funny how perception works, isn't it? If you had two concentric spheres (imagine the outer one being transparent), and the diameter of the inner one was 47% of the outer one, the smaller sphere has only 10% of the volume.

If you take no-X's delineation of the MC, it's only 8%.

What may be more shocking is that if you remove the rectangle that bounds all the coloured regions (does the ring bus occupy this outer space? Or does it go around the MC?), then those "slivers" occupy a whopping 17% of the die. What the heck is that?

 

[Dave Baumann]

I was talking about the on-chip Hi-Z memory to hold the min for each 4x4 block. You also need to store the Z and colour compression state for each block, so you know how much memory to fetch.

Yes, I know, so was I. Each quad has a portion of allocated to HiZ storage, or so I'm told - this is why high res support scales better with the parts with more quads (I'm also told it was an error that it was disabled for the 9500's).

 

[Geo]

If you take no-X's delineation of the MC, it's only 8%.

Yup. That was "smallest" of the two I did.

 

[Mintmaster]

Yes, I know, so was I. Each quad has a portion of allocated to HiZ storage

Okay. The last part of my post made that guess.

Regarding my other post, do you know what the stuff around the outside is? It seems silly to put the ring bus here, because the perimeter is so large. I know you were talking about getting away from the centre of the die, but 17% is a lot of space!