AMD: R7xx Speculation

Which is exactly why they should apply the old 80/20 rule and go for the bottom 80 percent of the customers...

Also, I know it's been said that designing a chip takes *years* that a design can't be tacked onto over night.. But, I do believe I recall reading that AMD had concerns about the texture units well before R600 shipped and were looking to correct that deficency with R700 - hence the roadmap change?



IS it possible that AMD could of changed R700's design to reflect updated/improved texture units or is this simply not possible given the time frame and the architecture design limits?

Thanks

 

Except the whispers on the wind from multiple directions are suggesting whatever was originally R700 isn't anymore. Less sure if the R700 codename itself has been dumped for R720 or the likes.

 

I wonder if R700 as originally planned would have been faster than 2xRV670, and have my doubts.

So if "R780" is the first we'll see of R7xx, then we could be waiting until autumn 2008 or later (11-13 months)?

Jawed

 

Are you suggesting a kind of R300->R420 transition for R600->R700/R720? More of the same, nothing new? Actually not a bad idea: ATi could make up for lost time this way.

 

I shudder at the thought. At least R300->R420 more than doubled pixel and texture fillrates, given ATi's trend recently of barely touching those two, R700 would be DOA. Yet another ALU beast with no texture fillrate or MSAA sampling rate (compared to whatever NV has out at the time) would be R600 all over again. Screw that.

 

Goddamn it, when the hell is Dammit ever going to ship a Rx00 part again?

I'm *still* confused as to what, exactly, happened to R400...

 

It became Xenos...

 

Wow.. R720 is a B3D invention!

 

That's more data than I have available to me today. Surely that's what they did last time they bumped an "00" off the roadmap. Presumably it's not the only model for what they could do.

 

Hah! So far as I know today that is correct! i.e. that it's a B3D invention. Time will have to tell if another contender shows up claiming "prior art"!

 

twice a today.. are you trying to make something clear? 2-D .. after Radeon HD comes 2D!

 

Anyone seen these?





http://pc.watch.impress.co.jp/docs/2007/1204/kaigai404.htm
vr-zone forums (newzhunter)

Translation- (Thanks to Wesker776)

Pic 1- Title: Estimated Trend of High End GPU's

Single GPU Card
R600 Generation
(top to bottom):
First box: Because die is large it has a wider memory interface
Second box: Huge (monolithic) GPU unit
Third Box: The link supports multi video cards for better performance

Dual GPU Card
R680 Generation
(top to bottom):
First Box: The memory is seperated (independant), and now a memory duplicate overhead now occurs.
Second Box: Between the GPU's, there is no connection
Third box (bottom left): Both GPU's perform independant tasks, and there is a possibility of execution overhead
Fourth box (bottom right): GPU die size is half of the previous high end

Dual Die GPU
R700 Generation?
(top to bottom):
First Box: Shared memory has minimum latency, and both can be accessed
Second Box (left): GPU die is half the size of previous high end die
Third Box (right): GPU's are connected to eachother via high bandwidth, low latency interconnect
Fourth Box (right): It is an Multi Chip Module design (multiple dies on the same substrate), and this allows high bandwidth connection
Fifth Box (left): The GPU's are connected very closely and perform together in tandem to minimise overhead.

Second Picture
Dual Die GPU Power Saving Schemes

Left Hand:
High Voltage

Right Hand:
Low Voltage

 

I wonder if a better approach would be if they somehow shared the available memory, so you don't overlap as with current dual GPU cards/SLI/CrossfireX.

As it seems those sketches have dedicated VRAM to each GPU, which quite frankly seems silly if they have integrated both cores on one die (MCM).

They also seem to indicate that one GPU can sleep while not needed but I think the next step is to shut seperate parts of the chip down when they are not used. Why have ex. 320 SPs running when only 32 are needed for 2D rendering.

 

Rv370 already does that to an extent with regards to power saving and shutting down certain parts of the GPU.

And from the diagram, they seem to believe that DUAL GPU will have shared memory with each GPU having access to a pool of memory. Each GPU also has access to the other GPUs pool of memory although not sure how the latency would be of going through an addition path and MC. Appears to be similar to a NUMA architecture. Which wouldn't be surprising considering AMD has some expertise in this area. A sign of engineering overlap finally?

Regards,
SB

 

I'm more interested in what is the bandwidth between the two chips. Assuming high-clocked GDDR4 or even GDDR5 with 256bit channel per chip each chip would have >64GB/s memory bandwidth. In order to make it usable for both chips the interconnect between the two would need to be at least as big. That would require much more than HT3 can offer. Of course HT3 would be kind of an overkill as it has features that are not needed in that scenario.

 

Internal 512-bit or 1024-bit ringbus?

It could properly be done but it would pose some problems.

 

How one makes "internal" bus between two separate dies?

Perhaps it is similar to Power MCM's where there is a piece of complex PCB connecting CPUs and caches with extremely wide and fast buses.

 

Well, they are on the same package. You could properly do some "magic" but I didn't state it would be overly easy

 

Loki #2?

 

I'm not sure, if we need to share frame buffer and z-buffer, which are way more bandwidth dependant than texture memory. I think 16-32GB/s interface (just for textures) could suffice. Other possibility is fast-clocked, but narrow interface (die dimensions, low space for additional pads)