[Shtal]

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-ne...nds/14391.html

[PatrickL]

It was not South Islands ?

[fellix]

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.

[rpg.314]

About time, for these rumours, I say. With not a single 7xxx gpu in wild.

[denev2004]

Does this thread come out because the Maxwell thread had?

BTW, I wonder know how much improvement can be made this time.

[fellix]

Originally Posted by denev2004

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.

[Jawed]

Originally Posted by rpg.314

About time, for these rumours, I say. With not a single 7xxx gpu in wild.

http://forums.overclockers.co.uk/sho...php?t=18357324

I've no idea why some retailers are holding sales until some date in the future, particularly when those retailers have shown pix of their stock.

[CarstenS]

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

[fellix]

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.

[UniversalTruth]

At least the new thread has this nice ATi logo.

BTW: it's so early for this thread... we can't be sure even that the codename is correct.

[Jawed]

Originally Posted by fellix

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.p...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

[fellix]

Originally Posted by Jawed

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

I ran that program back on my HD5870 last year, but strangely I cant remember whether it worked or not.

[CarstenS]

Originally Posted by fellix

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]

Originally Posted by Jawed

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.p...postcount=4483

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

Originally Posted by fellix

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]

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]

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.

[trinibwoy]

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

Originally Posted by rpg.314

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]

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.

[trinibwoy]

Originally Posted by rpg.314

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]

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".

[rpg.314]

Originally Posted by trinibwoy

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

For the pre dx11 days, batching with the stamp granularity is fine. In the era of single pixel triangles, not packing every lane with fragments is a huge waste.

[fellix]

Originally Posted by Jawed

And, of course, it's possible to have multiple triangles per thread, but I haven't seen any evidence that ATI does this.

I think G70 did this to compensate for it's rather large batch size. Not sure for NV40.

[trinibwoy]

Originally Posted by rpg.314

For the pre dx11 days, batching with the stamp granularity is fine. In the era of single pixel triangles, not packing every lane with fragments is a huge waste.

Right but, like Jawed said, we don't have any evidence of batching at higher than rasterization granularity from either AMD or nVidia.

[Psycho]

I think I remember we already figured it out to be the case when discussing evergreen.
Otherwise it should be detectable by benchmarking fillrate on a *very* heavy pixel shader while decreasing triangle size.

[rpg.314]

I guess what need to be done is to render 64 single pixel triangles, with a *very* long pixel shader. And then measure the variation in rendering time as the triangle size is increased. If there is batching at stamp size, then there would be step function jumps in render times.