A Quick Refresher, Cont

Having established what’s bad about VLIW as a compute architecture, let’s discuss what makes a good compute architecture. The most fundamental aspect of compute is that developers want stable and predictable performance, something that VLIW didn’t lend itself to because it was dependency limited. Architectures that can’t work around dependencies will see their performance vary due to those dependencies. Consequently, if you want an architecture with stable performance that’s going to be good for compute workloads then you want an architecture that isn’t impacted by dependencies.

Ultimately dependencies and ILP go hand-in-hand. If you can extract ILP from a workload, then your architecture is by definition bursty. An architecture that can’t extract ILP may not be able to achieve the same level of peak performance, but it will not burst and hence it will be more consistent. This is the guiding principle behind NVIDIA’s Fermi architecture; GF100/GF110 have no ability to extract ILP, and developers love it for that reason.

So with those design goals in mind, let’s talk GCN.

VLIW is a traditional and well proven design for parallel processing. But it is not the only traditional and well proven design for parallel processing. For GCN AMD will be replacing VLIW with what’s fundamentally a Single Instruction Multiple Data (SIMD) vector architecture (note: technically VLIW is a subset of SIMD, but for the purposes of this refresher we’re considering them to be different).


A Single GCN SIMD

At the most fundamental level AMD is still using simple ALUs, just like Cayman before it. In GCN these ALUs are organized into a single SIMD unit, the smallest unit of work for GCN. A SIMD is composed of 16 of these ALUs, along with a 64KB register file for the SIMDs to keep data in.

Above the individual SIMD we have a Compute Unit, the smallest fully independent functional unit. A CU is composed of 4 SIMD units, a hardware scheduler, a branch unit, L1 cache, a local date share, 4 texture units (each with 4 texture fetch load/store units), and a special scalar unit. The scalar unit is responsible for all of the arithmetic operations the simple ALUs can’t do or won’t do efficiently, such as conditional statements (if/then) and transcendental operations.

Because the smallest unit of work is the SIMD and a CU has 4 SIMDs, a CU works on 4 different wavefronts at once. As wavefronts are still 64 operations wide, each cycle a SIMD will complete ¼ of the operations on their respective wavefront, and after 4 cycles the current instruction for the active wavefront is completed.

Cayman by comparison would attempt to execute multiple instructions from the same wavefront in parallel, rather than executing a single instruction from multiple wavefronts. This is where Cayman got bursty – if the instructions were in any way dependent, Cayman would have to let some of its ALUs go idle. GCN on the other hand does not face this issue, because each SIMD handles single instructions from different wavefronts they are in no way attempting to take advantage of ILP, and their performance will be very consistent.


Wavefront Execution Example: SIMD vs. VLIW. Not To Scale - Wavefront Size 16

There are other aspects of GCN that influence its performance – the scalar unit plays a huge part – but in comparison to Cayman, this is the single biggest difference. By not taking advantage of ILP, but instead taking advantage of Thread Level Parallism (TLP) in the form of executing more wavefronts at once, GCN will be able to deliver high compute performance and to do so consistently.

Bringing this all together, to make a complete GPU a number of these GCN CUs will be combined with the rest of the parts we’re accustomed to seeing on a GPU. A frontend is responsible for feeding the GPU, as it contains both the command processors (ACEs) responsible for feeding the CUs and the geometry engines responsible for geometry setup. Meanwhile coming after the CUs will be the ROPs that handle the actual render operations, the L2 cache, the memory controllers, and the various fixed function controllers such as the display controllers, PCIe bus controllers, Universal Video Decoder, and Video Codec Engine.

At the end of the day if AMD has done their homework GCN should significantly improve compute performance relative to VLIW4 while gaming performance should be just as good. Gaming shader operations will execute across the CUs in a much different manner than they did across VLIW, but they should do so at a similar speed. And for games that use compute shaders, they should directly benefit from the compute improvements. It’s by building out a GPU in this manner that AMD can make an architecture that’s significantly better at compute without sacrificing gaming performance, and this is why the resulting GCN architecture is balanced for both compute and graphics.

A Quick Refresher: Graphics Core Next Building Tahiti & the Southern Islands
Comments Locked

292 Comments

View All Comments

  • RussianSensation - Thursday, December 22, 2011 - link

    I think his comment still stands. In terms of a performance leap, at 925mhz speeds at least, this is the worst improvement from 1 major generation to the next since X1950XTX -->2900XT. Going from 5870 to 6970 is not a full generation, but a refresh. So for someone with an HD5870 who wants 2x the speed increase, this card isn't it yet.
  • jalexoid - Thursday, December 22, 2011 - link

    How's OpenCL on Linux/*BSD? Because I fail to see real high performance use in Windows environments for any GPGPU.

    For GPGPU the biggest target should be still Linux/*BSD because they are the dominating platforms there....
  • R3MF - Thursday, December 22, 2011 - link

    "Among the features added to Graphics Core Next that were explicitly for gaming, the final feature was Partially Resident Textures, which many of you are probably more familiar with in concept as Carmack’s MegaTexture technology."

    Is this feature exclusive to gaming, or is it an extension of a visualised GPU memory feature?

    i.e. if running Blender on the GPU via the cycles renderer will i be able to load scenes larger than local graphics memory?
  • Ryan Smith - Thursday, December 22, 2011 - link

    It's exclusive to graphics. Virtualized GPU memory is a completely different mechanism (even if some of the cache concepts are the same).

    With that said I see no reason it couldn't benefit Blender, but the benefits would be situational. Blender would only benefit in situations where it can't hold the full scene, but can somehow hold the visibly parts of the scene by using tiles.
  • R3MF - Friday, December 23, 2011 - link

    cheers Ryan
  • Finally - Thursday, December 22, 2011 - link

    ...the 2nd generation HD8870 feat. GCN, 3W idle consumption and hopefully less load consumption than my current HD6870. Just let a company like Sapphire add a silent cooler and I'm happy.
  • poohbear - Thursday, December 22, 2011 - link

    Btw why didnt Anandtech overclock this card? it overclocks like a beast according to all the other review sites!
  • Esbornia - Thursday, December 22, 2011 - link

    Cause they want you to think this card sucks come on guys everybody in the internet knows this site sucks for reviews that are not from Intel products.
  • SlyNine - Thursday, December 22, 2011 - link

    lol troll. This site has prefered who ever had the advantage in what ever area. They will do a follow up of its OCing and when they first show a card they show it at stock only.

    I do not OC my videocards, whats the point in adding 5% more gain in games that are running maxed anyways.
  • RussianSensation - Thursday, December 22, 2011 - link

    Is this comment supposed to be taken seriously? Go troll somewhere else.

Log in

Don't have an account? Sign up now