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

Shtal

Veteran
While Southern Islands is only just beginning to roll out, a recently ex-AMD ASIC designer's Linkedin profile reveals the possible codename for AMD's next-gen GPU family - Sea Islands.

During his tenure as MTS Design Engineer at AMD, Alexander Shternshain worked on Evergreen and Northern Islands - branded HD 5000 and HD 6000 families, Fusion APUs - Ontario (C/E Series), Llano (A-Series) as well as Krishna, whose fate is unknown. The final two GPU families mentioned are Southern Islands - which we already have come to know as Radeon HD 7000 family - and the future family, Sea Islands.

Unlike the rather vague codenames of Northern Islands and Southern Islands, Sea Islands directly refers to the chain of islands on the USA's Atlantic coast. We can thus expect the individual chips from the family codenamed along the lines of the prominent islands in the region.

Sea Islands, if that is indeed the final codename, is still a long way away - possibly late 2012/early 2013 at the earliest - while the rumour mill is still digesting Southern Islands. We can expect AMD to build on the GCN architecture with Sea Islands as TSMC's 28nm process matures.
http://vr-zone.com/articles/amd-s-next-gen-gpu-family-codenamed-sea-islands/14391.html
 

fellix

Veteran
I firmly expect the next round of GPUs to be named "Homeland", with the flagship model to be named after the biggest state of... guess who. :p
 

denev2004

Newcomer
Does this thread come out because the Maxwell thread had?

BTW, I wonder know how much improvement can be made this time.
 
Last edited by a moderator:

fellix

Veteran
BTW, I wonder know how much improvement can be made this time.
As much, as the manufacturing process allows, I guess. Tahiti is "only" 365mm², so there's alot of margin left. TSMC is also moving very fast to 450mm wafers, remember. Large chips are ought to get cheaper, in a long term.
 

CarstenS

Legend
Subscriber
With GCN being the basis for a few years to come, I hope the next major overhaul will be in the front-end.
 

fellix

Veteran
GCN seems to cope well with just two prim's per clock rate, safe for the few extreme cases. I think the pixel processing efficiency is more of a problem here with smaller polygons, not the front-end really. Fermi already set the bar quite high enough with its four setup pipes for anyone to claim for more.
 

Jawed

Legend
I think the pixel processing efficiency is more of a problem here with smaller polygons, not the front-end really.
Yes agreed - not a word on this subject with GCN as far as I can tell. But then tests are few and far between.

I'm still waiting for a response to this:

http://forum.beyond3d.com/showpost.php?p=1351232&postcount=4483

And to be quite frank I think GCN is still broken in this respect.

There is a suite of tests written in OpenGL, but these tests didn't work on ATI back in the day, of course:

http://www.icare3d.org/GPU/CN08
 

CarstenS

Legend
Subscriber
GCN seems to cope well with just two prim's per clock rate, safe for the few extreme cases. I think the pixel processing efficiency is more of a problem here with smaller polygons, not the front-end really. Fermi already set the bar quite high enough with its four setup pipes for anyone to claim for more.

Actually, I consider both parts of the front-end.
 

rpg.314

Veteran
Yes agreed - not a word on this subject with GCN as far as I can tell. But then tests are few and far between.

I'm still waiting for a response to this:

http://forum.beyond3d.com/showpost.php?p=1351232&postcount=4483

And to be quite frank I think GCN is still broken in this respect.

I think the pixel processing efficiency is more of a problem here with smaller polygons, not the front-end really. Fermi already set the bar quite high enough with its four setup pipes for anyone to claim for more.

There are hard limits to efficiency for single pixel triangles. Lots of single pixel triangles are a sign of failure on the part of the application, not the GPU.

Unless the pipeline is tuned for single pixel triangles, and that will take some radical changes at the API/semantics level, trying to optimize for single pixel triangles is putting the cart before the horse.
 

Jawed

Legend
ATI still appears to be designed for "8-fragment triangles" (arguably 16-fragment triangles) - I haven't seen anything in GCN that changes this. And a pixel shader thread that contains one of these then runs at 12.5% efficiency. That's dark ages.
 

rpg.314

Veteran
8 pixel triangles is the sweet spot, but there is no sensible reason to believe that ATi will pack one triangle per 64 wide thread and optimize the rasterizer for 8 pixel triangles. Does nvidia also issue one warp per triangle, I am quite doubtful.
 
Last edited by a moderator:

trinibwoy

Meh
Legend
Anyone know what the communication pathway is between GCN's CU's and the primitive pipelines? Dedicated buffers, GDS, L2 cache?

8 pixel triangles is the sweet spot, but there is no sensible reason to believe that ATi will pack one triangle per 64 wide thread and optimize the rasterizer for 8 pixel triangles. Does nvidia also issue one warp per triangle, I am quite doubtful.

Even if they are packing 4 16-pixel tiles per wavefront, the (arguably contrived) worst case scenario is 6.25% utilization. For nVidia the worst case is 12.5% assuming 8-pixel tiles.
 

rpg.314

Veteran
But there should be only only one wasteful thread per draw call, even in the worst case. Why would they pack anything less? A more likely scenario is that threads being populated in batches of 8 or the size of rasterizer stamp. But any sensible solution with 64 wide SIMD would pack multiple batches from multiple triangles being the common case.
 
Last edited by a moderator:

trinibwoy

Meh
Legend
But there should be only only one wasteful thread per draw call, even in the worst case. Why would they pack anything less? A more likely scenario is that threads being populated in batches of 8 or the size of rasterizer stamp. But any sensible solution with 64 wide SIMD would pack multiple batches from multiple triangles being the common case.

Yeah I agree but why isn't it possible to have multiple 1-pixel sized triangles in a draw call?
 

Jawed

Legend
It's not a draw call, it's a pixel shader thread launch.

And, of course, it's possible to have multiple triangles per thread, but I haven't seen any evidence that ATI does this. Please present your evidence rather than "it would be silly not to".
 
Top