AMD: Pirate Islands (R* 3** series) Speculation/Rumor Thread

AIB partners said, reportedly, at CeBIT that they're expecting fall launch for Pirate Islands

 

the 290x is 2,816 stream processors . That could be a nice improvement.

 

Fiji planned for next year, so big time gap between it and the other GPUs?

That means close launch of all the three GPUs.

 

This would be perfect, i'd like to sell my 7950 and replace it with something more energy efficient but roughly the same performance.
With at least 4GB memory.

 

Weird... 66CUs?

6 * 12CUs, 1 disabled in each er... array? engine? what's the new terminology? pirate ship? booty?

Something else?

 

Fair enough.

At any rate, I'd be more interested in changes to caches... (not sure what else to expect).

 

This should be useful for future reference;

Via Anandtech

 

I really don't know, if it's true, but it looks like the L2-Cache scales now with the ROPs and not with MCs. Could just be a coincidence...

 

Can you clarify?
Tahiti has 768 KB of L2, 6 memory controllers, and 32 ROPs.
Hawaii has 1 MB of L2, 8 memory controllers, and 64 ROPs.

 

I've seemingly been out of the loop on this silly season.
No super secret squirrel rumors from me.

 

Thats a bit of a mystery, but I'll try:
For GCN 1.0, the L2-Cache is always coupled to the MCUs, which means the L2-Cache scales according to the number of the MCUs. The L2-Cache per MCU can be 128KB or 256KB.
Tahiti: 128KB per MCU -> 6 x 128KB = 768KB L2-Cache
Pitcairn: 128KB per MCU -> 4 x 128KB = 512KB L2-Cache
Cape Verde: 256KB per MCU -> 2 x 256KB = 512KB L2-Cache
Mars/Hainan: 128KB per MCU -> 2x128KB = 256KB L2-Cache
Bonaire: I dont know

For GCN1.1 aka Hawaii there seems to be a difference according to the presentation. First the ROPs are now part of the Shader Engines and not decoupled anymore, additional to that the L2-Cache looks like to be partitioned in a different way.
But thats just speculation...

 

Bonaire and Hawaii are on the same IP level, Bonaire is GCN 1.1 too.

 

If that affects the cache system? I don't know.

 

Well, for APU integration I dont think you can really put your cache on DCTs, since they are shared with the CPU part. So it makes sense to decouple them from the memory controllers, I guess.
having the design already done, maybe they just reused it. Or maybe it offers additional benefits, especially in the optic of a unified address space? Who knows...

 

Hawaii 128KB per MC -> 8 x 128KB = 1MB L2
What is the evidence of a change to the L2, aside from the L2 happening to be on the same marketing slide as ROPs?

Current APUs actually maintain the GPU memory controller, and that then hops over to the physical memory controllers.
Yes, it is that hacky.

Unless the L2 is significantly changed and made capable of coherent snooping, it can't be decoupled from the memory controllers. The individual slices can only guarantee coherence and if they can only contain data from a linked memory channel.

Suddenly making an L2 slice capable of storing data from a non-exclusive set of memory devices will allow more than one slice to contain data from the same address.
If the same address cannot exist in more than one slice, why decouple it?

 

A quick(15min) search on google and i got nothing on Bonaire caches except some trueaudio cache slide.

Via Bit-Tech

 

Yeah, the 'garlic' bus is essentially what connects the GPU MCT to the CPU DCTs.
But I was under impression that they did change the design to unify the L2 so it was not sliced any more.... ah well, maybe I was wrong.

 

Guys, take a look at what's going on there, page 3, comment 17:

http://www.techpowerup.com/199750/nvidia-geforce-gtx-880-detailed.html?cp=3#comments