AMD: Sea Islands R1100 (8*** series) Speculation/ Rumour Thread

Look like you was right on the shot.

http://translate.google.com/transla..._tenerife-gpu_stellen_eine_falschmeldung_dar/

 

All the CUs in the world won't help them if they don't address the deficit in ROPs. See the performance scaling between Pitcairn and Tahiti.

40CUs coupled with 64ROPs would make for a very interesting chip, though.

 

AMD confirms Terenife slide is a hoax.

http://ht4u.net/news/25227_geruechte_um_amd_tenerife-gpu_stellen_eine_falschmeldung_dar/

 

Or 48, as they should match better with a 384 bit bus, even if being them decoupled in Tahiti this is less an issue. I wonder if in Pitcairn AMD has spared quite some transistors by avoiding to use the crossbar between ROP partitions and Memory Controller, keeping the same configuration as in Cypress/Barts/Cayman... (but in the block diagram this seems not the case)

 

THAT. Decoupling ROPs from memory controllers never seemed to do any good for HD 5830 nor HD 6790 (see the OP of my controversial thread)!

 

They were not really decoupled. As far as I understand, AMD just deactivated half of each ROP partition. That is really different with Tahiti.

 

Ahh I see, thanks. A review article actually said that about the 6790 (being decoupled). Sheesh.. (EDIT: not to you, but to the reviewer saying that).

EDIT- It's actually BeHardware.com that says this:

http://www.behardware.com/articles/827-1/report-amd-radeon-hd-6790.html

So, you think it's just that Tahiti needs more ROPs? What is it that the 7950 really needs to prevent the 7870 from actually beating it in a few games?

 

I don't now, but ROPs are the odd one out:

HD 7870: 2.560 GFLOPs; 32.000 MPix/s; 80.000 MTex/s; 153.600 MB/s
HD 7970: 3.789 GFLOPs; 29.600 MPix/s; 118.400 MTex/s; 264.000 MB/s

Are you sure?

Because that's exactly the point I really don't get: Why would they take all effort to decouple ROPs just to cripple their very top-end chip's rasterization and pixel fill performance? Pitcairn and Cape Verde obviously ended up using the traditional ROP/mem controller ratio - no need to decouple ROPs here.

If anything, I'd have expected the decoupling of ROPs to be used to push more ROPs per mem controller - not less.

What we ended up with is an enthusiast card (aimed at ultra-high-res gaming) that took the (long-avoided) extra step to decouple ROPs just to push less MPix/s than the next best high-midrange offering.

How strange a design choice is that?

 

It could work in both directions. There is a crossbar between the ROP partitions and the memory controllers in Tahiti, decoupling them. Before, there was more likely a relatively simple mapping of memory requests from the ROPs to memory controllers (just some interleaving scheme).

Btw., your theoretical fillrate numbers say half of the truth at best. For instance you could look at some real benchmarks involving some framebuffer formats larger than 32bits per pixel or involving blending and you will see how much the ROPs in Pitcairn (or Cypress or Cayman) can be held back by the memory bandwidth.

 

with a 8 RB to 12 Channel mapping there has to be a crossbar somewhere - whether it is from the engine to the RB's or the RB's to the memory channels. You also have to consider how the engine upstream is working and how you tie in RB redundancy as well.

Note, with Tahiti there is not a full RB to memory channel Crossbar - each RB can access just 3 memory channels in order to keep the crossbar complexibility and size down, but still providing some flexibility.

 

3-way associativity? Well, I guess this is reasonable solution, considering that in a coupled architecture each ROP unit access only it's own memory partition -- direct mapped, sort of.

 

That's quite interesting. Thanks for sharing that.
I was somewhat sceptical of this 32 ROPs on a 384bit interface in the beginning just because of the added effort for the crossbar. But limiting the access of each partition to half of the channels basically halves the complexity too.

Edit:
So in principle it should be possible to cut down the memory interface in 128Bit steps (but not 64Bit steps) without changing the number of ROPs, right?

 

That leaves scope for another salvage part based on Tahiti. They could drop it to 256 bit and 2 GB memory, and disable another 4 CU's. But unless they clock it high enough, 7870 would likely beat or come close enough to this salvage part so it dosent seem likely does it? And given the current pricing of 7870 at $349 and 7950 at $449, it'll have to slot in at $399 and it dosent sound too enticing then

 

The workload may lacks parallelism too, then the higher clock of HD7870 helps.

 

I wonder how feasible would it to produce a salvage Tahiti that is an exact duplicate of an HD 7870? It would allow AMD to seamlessly shore up supplies of HD 7870 and avoid creating a troublesome new temporary SKU.

 

Should be technically feasible..but financially? Might as well produce more dies of Pitcairn..would be far cheaper.

Also i dont think Tahiti and Pitcairn are pin compatible so it wouldnt matter anyway.

 

Don't recall the last time a salvage part had higher clocks than the fully enabled...

Edit- Doing some research, Barts LE had higher clocks than Pro but not XT. Same thing with Cypress.
Like Erinyes, I just don't see the point.

 

actually given the small perf delta between 7870 and 7950 i think it makes sense, remember this is only for parts that have to many failures to make it as a 7950.

doing another X2 BE would be dumb.

 

But then to clock it higher than Tahiti XT???

 

sure, didn't the much gimped 5830 have a higher clock then 5870?