AMD: Volcanic Islands R1100/1200 (8***/9*** series) Speculation/ Rumour Thread

[3dilettante]

The "Sea Islands" document when it was posted earlier in the year had multiple obvious cut and paste errors from documentation for older GPUs. The Sea Islands thread has a number of them pointed out.

From that thread, it should be noted that the document was allegedly pulled because the use of Sea Islands instead of some kind of IP signifier was misleading.
Since AMD has seen fit to re-post it with no changes, I guess reality changed itself to comport to said document ...

AMD's standards for accuracy apparently remain constant.

 

[3dcgi]

The Sea islands manual still seems to suggest that LDS is 'per simd', yet their phrasing still mean it 'per CU' to me.

LDS is still per CU.

 

[Nakai]

GCN has 4*64KB Vector Registers(64KB for each SIMD) and a 64KB LDS for one CU.
ATI/AMDs latest GPU designs were all register monsters.
Sadly the GDS is pretty small. Hawaii should increase the GDS dramatically.
GCN has a 128KB Cache foreach memory controller(correct me if wrong). A 512bit MI should consist of 8 memory controllers(8x64), so there should be at least 1MB of L2-Cache on Hawaii. Maybe AMD doubles that with Hawaii, there's a good chance, we get at least 1MB of GDS for Hawaii.

In my opinion, LDS and registers are pretty awesome on GCN. AMD needs to increase the GDS, if it wants to bring a GPGPU-Monster with Hawaii.

 

[RecessionCone]

In my opinion, LDS and registers are pretty awesome on GCN. AMD needs to increase the GDS, if it wants to bring a GPGPU-Monster with Hawaii.

Is the GDS exposed in OpenCL? If I wanted to use it, how would I go about doing so?

 

[Nakai]

OpenCL doesn't support global snychronization, but GCN does. If it doesn't use the GDS for caching general memory accesses, i hope GCN 2.0 will support new features for memory accesses. Interesting is the fact, that OpenCL2.0 is in the pipeline, which adds many new interesting features. In OpenCL 2.0 kernels can spawn new kernels, as well new workgroup functionality is added(workgroup broadcast, subworkgroups). Interesting is, that the standard barrier is renamed to work_group_barrier, which implies that there could be a global barrier call in the future...

€: What i really hope is, that AMD introduces some proprietary OpenCL libs for their gpu architectures, because GCNs feature set is far more advanced, that any OpenCL functionality.

€2: Maybe this helps: http://industrybestpractice.blogspot.de/2012/07/global-synchronisation-in-opencl.html

 

[Gipsel]

ATI/AMDs latest GPU designs were all register monsters.

They always were. The VLIW architectures had 256kB registers for each SIMD/CU (and a single wavefront could even use up to 128kB, not "only" 64kB as with GCN).

Sadly the GDS is pretty small. Hawaii should increase the GDS dramatically.

As long as it is not really exposed for higher level languages, an increase won't help much.

GCN has a 128KB Cache foreach memory controller(correct me if wrong).

The L2 cache can be 64kB or 128kB per channel. CapeVerde with an 128bit memory interface has also 512kB L2, same as Pitcairn.

Is the GDS exposed in OpenCL? If I wanted to use it, how would I go about doing so?

IIRC it is only exposed through the atomic counter extension (which uses GDS atomics).

 

[Nakai]

They always were. The VLIW architectures had 256kB registers for each SIMD/CU (and a single wavefront could even use up to 128kB, not "only" 64kB as with GCN).

You are right! AMD/ATIs architectures always had huge register files.

As long as it is not really exposed for higher level languages, an increase won't help much.

It would be nice, if we get some extension by AMD for their architecture.

The L2 cache can be 64kB or 128kB per channel. CapeVerde with an 128bit memory interface has also 512kB L2, same as Pitcairn.

Mhh, Cape Verde has 2 64bit channels. You mean 128kB and 256KB, right?

€: Ah, now I know what you mean: Each controller has two channels(dualchannel). I thought the cache scales according to the number of memory controllers, not the channels.

IIRC it is only exposed through the atomic counter extension (which uses GDS atomics).

Hmm, which one?

 

[Gipsel]

Hmm, which one?

This one.

 

[RecessionCone]

This one.

Interesting. I wonder why they exposed this as opposed to just allowing users to build counters themselves with atomics. Maybe because they could ensure the counters are placed in GDS. Still, the API is very restrictive and can't use GDS to its full potential.

 

[Gipsel]

Still, the API is very restrictive and can't use GDS to its full potential.

That was kind of my point above, that any changes to the GDS or also just an increase in size won't help much, as long as it is not really exposed in high level APIs.

And yes, one can of course also use global atomics (offering a broader range of functions than just increasing and decreasing). But those place the values in memory or the L2 instead of the GDS and are higher latency.

 

[pjbliverpool]

HSA with VI?

I'm not sure if VI is supposed to be HSA compliant, I recall seeing a slide a while back, which then referred to the Southern Islands successor as Sea Islands, which referenced the new high end discrete GPU's having HSA compliance.

But if that's true then I'm struggling to understand what it means. Would we be talking about a unified virtual memory space that addresses both system and graphics memory?

So for example the GPU could read/write directly to the system memory using the virtual address space and the CPU could read/write directly the graphics memory using the same with these reads/writes going over the PCI-E interface and thus limited to it's bandwidth or the bandwidth of the physical pool of memory if slower?

And so thus would it be valid under such a setup to consider available graphics memory bandwidth as say 200GB/s (local) + 32GB/s (PCI-e - assuming system memory was also 32GB/s or more of course)?

And vice versa for the CPU?

Would memory capacity also be valid to look at in this way? i.e. the GPU would have say 16GB of memory running at 32GB/s + 3GB running at 200GB/s?

 

[UniversalTruth]

AMD Radeon R-200 graphics cards naming unveiled

AMD Radeon R9 280X to replace HD 7970, features 3GB GDDR5 memory

WTH?

 

[pjbliverpool]

Not much new info there but the confirmation of only 3GB / 384bit memory on the top end model is pretty dissapointing.

 

[jimbo75]

Both slides contradict each other.

Edit - Now he's updated it.

 

[jimbo75]

If the 7870 replacement is the 280X then it's going to be the mother and father of all smackdowns. If that's the 7970 GHz replacement then it's looking like something they should have released a year ago. Neither seems likely to me, but maybe I'm just hoping.

I think it's safe to say it's 28nm now though, right?

Ok so most of the other specs are a guess, however it appears 384-bit is pretty much confirmed based on the HIS leak. So really, no further forward unless anyone was expecting 512-bit. I couldn't make up my mind on whether that was likely or not but did consider it a decent possibility.

 

[gkar1]

The jump in performance of the top end GPU seems pretty substantial if they can straight up use a Tahiti based SKU to replace the 7850 in the product stack. Less than 2 weeks for the press briefing, hoping we see more/any leaks between now and then.

 

[UniversalTruth]

Both slides contradict each other

Yup, they do. In one of them it is R9 290X (Hawaii XT) and in the other R9 280X...

Edit - Now he's updated it.

What's updated?

Not much new info there but the confirmation of only 3GB / 384bit memory on the top end model is pretty dissapointing.

To me the confirmation is different- that Tahiti will be just rebadged and nothing more. It is not a confirmation for Hawaii.

however it appears 384-bit is pretty much confirmed based on the HIS leak

I don't see what chips will be inside those HIS cards.

 

[jimbo75]

What's updated?

http://videocardz.com/45608/amd-radeon-r9-280x-replace-hd-7970-features-3gb-gddr5-memory

"Because of the new leak I had to update the chart from yesterday."

I think he's still barking up the wrong tree though.

To me the confirmation is different- that Tahiti will be just rebadged and nothing more. It is not a confirmation for Hawaii.

Yes you could be right, and his numbers are off a bit. Would still leave room for a 512-bit single chip 290.

 

[jimbo75]

Ok how's this for a guess...

R9 290X - 512-bit Hawaii die
R9 290 - 512-bit Hawaii die (could also be a 384-bit part)
R9 280X - 384-bit salvage of Hawaii
R9 280 - Tahiti (7970)
R9 270X - Tahiti (7950)
R9 270 - Tahiti LE

And basically continue down from there.

But wait, based on the HIS link that doesn't make sense - http://www.hisdigital.com/un/download.shtml

Goes from 290 to 240, which is way too many segments (6) for them to have more than 1 card each surely? So based on that, is each "Series" just a single card, or are there a ton of rebrands at the low end maybe? Still wouldn't make much sense with the APU numbers having to fit in here as well. (I forgot about the M part of course, so that's not an issue) Ah fuck, I dunno. Gonna be crazy by the end of the month trying to figure this out.

Or hm does it? My numbers look good in some ways, with R9 270 finishing as Tahiti LE, then Pitcairn cards starting at R7 and downwards. Hmm.

 

[Nemo]

R9 280 - Tahiti (7970)
R9 270X - Tahiti (7950)
R9 270 - Tahiti LE

No more Tahiti, because Tahiti has high TDP not for new middle segment and not has a UVD4 with H.265 hw-decoding support. 280 and 270 based on Maui and Iceland, I think.