A Quick Refresher: Graphics Core Next

One of the things we’ve seen as a result of the shift from pure graphics GPUs to mixed graphics and compute GPUs is how NVIDIA and AMD go about making their announcements and courting developers. With graphics GPUs there was no great need to discuss products or architectures ahead of time; a few choice developers would get engineering sample hardware a few months early, and everyone else would wait for the actual product launch. With the inclusion of compute capabilities however comes the need to approach launches in a different manner, a more CPU-like manner.

As a result both NVIDIA and AMD have begun revealing their architectures to developers roughly six months before the first products launch. This is very similar to how CPU launches are handled, where the basic principles of an architecture are publically disclosed months in advance. All of this is necessary as the compute (and specifically, HPC) development pipeline is far more focused on optimizing code around a specific architecture in order to maximize performance; whereas graphics development is still fairly abstracted by APIs, compute developers want to get down and dirty, and to do that they need to know as much about new architectures as possible as soon as possible.

It’s for these reasons that AMD announced Graphics Core Next, the fundamental architecture behind AMD’s new GPUs, back in June of this year at the AMD Fusion Developers Summit. There are some implementation and product specific details that we haven’t known until now, and of course very little was revealed about GCN’s graphics capabilities, but otherwise on the compute side AMD is delivering on exactly what they promised 6 months ago.

Since we’ve already covered the fundamentals of GCN in our GCN preview and the Radeon HD 7970 is primarily a gaming product we’re not going to go over GCN in depth here, but I’d encourage you to read our preview to fully understand the intricacies of GCN. But if you’re not interested in that, here’s a quick refresher on GCN with details pertinent to the 7970.

As we’ve already seen in some depth with the Radeon HD 6970, VLIW architectures are very good for graphics work, but they’re poor for compute work. VLIW designs excel in high instruction level parallelism (ILP) use cases, which graphics falls under quite nicely thanks to the fact that with most operations pixels and the color component channels of pixels are independently addressable datum. In fact at the time of the Cayman launch AMD found that the average slot utilization factor for shader programs on their VLIW5 architecture was 3.4 out of 5, reflecting the fact that most shader operations were operating on pixels or other data types that could be scheduled together

Meanwhile, at a hardware level VLIW is a unique design in that it’s the epitome of the “more is better” philosophy. AMD’s high steam processor counts with VLIW4 and VLIW5 are a result of VLIW being a very thin type of architecture that purposely uses many simple ALUs, as opposed to fewer complex units (e.g. Fermi). Furthermore all of the scheduling for VLIW is done in advance by the compiler, so VLIW designs are in effect very dense collections of simple ALUs and cache.

The hardware traits of VLIW mean that for a VLIW architecture to work, the workloads need to map well to the architecture. Complex operations that the simple ALUs can’t handle are bad for VLIW, as are instructions that aren’t trivial to schedule together due to dependencies or other conflicts. As we’ve seen graphics operations do map well to VLIW, which is why VLIW has been in use since the earliest pixel shader equipped GPUs. Yet even then graphics operations don’t achieve perfect utilization under VLIW, but that’s okay because VLIW designs are so dense that it’s not a big problem if they’re operating at under full efficiency.

When it comes to compute workloads however, the idiosyncrasies of VLIW start to become a problem. “Compute” covers a wide range of workloads and algorithms; graphics algorithms may be rigidly defined, but compute workloads can be virtually anything. On the one hand there are compute workloads such as password hashing that are every bit as embarrassingly parallel as graphics workloads are, meaning these map well to existing VLIW architectures. On the other hand there are tasks like texture decompression which are parallel but not embarrassingly so, which means they map poorly to VLIW architectures. At one extreme you have a highly parallel workload, and at the other you have an almost serial workload.


Cayman, A VLIW4 Design

So long as you only want to handle the highly parallel workloads VLIW is fine. But using VLIW as the basis of a compute architecture is going is limit what tasks your processor is sufficiently good at. If you want to handle a wider spectrum of compute workloads you need a more general purpose architecture, and this is the situation AMD faced.

But why does AMD want to chase compute in the first place when they already have a successful graphics GPU business? In the long term GCN plays a big part in AMD’s Fusion plans, but in the short term there’s a much simpler answer: because they have to.

In Q3’2011 NVIDIA’s Professional Solutions Business (Quadro + Tesla) had an operating income of 95M on 230M in revenue. Their (consumer) GPU business had an operating income of 146M, but on a much larger 644M in revenue. Professional products have much higher profit margins and it’s a growing business, particularly the GPU computing side. As it stands NVIDIA and AMD may have relatively equal shares of the discrete GPU market, but it’s NVIDIA that makes all the money. For AMD’s GPU business it’s no longer enough to focus only on graphics, they need a larger piece of the professional product market to survive and thrive in the future. And thus we have GCN.

Index A Quick Refresher, Cont
POST A COMMENT

291 Comments

View All Comments

  • CeriseCogburn - Thursday, March 08, 2012 - link

    That happened at the end of 2006 with the G80 Roald. That means AMD and their ATI Radeon aquisition crew are five years plus late to the party.
    FIVE YEARS LATE.
    It's nice to know that what Nvidia did years ago and recently as well is now supported by more people as amd copycats the true leader.
    Good deal.
    Reply
  • Hauk - Thursday, December 22, 2011 - link

    A stunningly comprehensive analysis of this new architecture. This is what sets Anandtech apart from its competition. Kudos Ryan, this is one of your best.. Reply
  • eastyy - Thursday, December 22, 2011 - link

    its funny though when it comes to new hardware you read these complicated technical jargon and lots of detailed specs about how cards do things different how much more technically complicated and in the end for me all it means is...+15fps and thats about it

    as soon as a card comes out for say 150 and the games i play become slow and jerky on my 460 then i will upgrade
    Reply
  • Mockingbird - Thursday, December 22, 2011 - link

    I'd like to see some benchmarks on FX-8150 based system (990fx) Reply
  • piroroadkill - Friday, December 23, 2011 - link

    Haha, the irony is that AMD is putting out graphics cards that would be bottlenecked HARDCORE by ANY of their CPUs, overclocked as much as you like.

    It's kind of tragic...
    Reply
  • Pantsu - Friday, December 23, 2011 - link

    The performance increase was as expected, at least for me, certainly not for all those who thought this would double performance. Considering AMD had a 389mm^2 chip with Cayman, they weren't going to double the transistor count again. That would've meant the next gen after this would be Nvidia class huge ass chip. So 64% more transistors on a 365mm^2 chip. Looks like transistor density increase took a bit of a hit on 28nm, perhaps because of 384-bit bus? Still I think AMD is doing better than Nvidia when it comes to density.

    As far as the chip size is concerned, the performance is OK, but I really question whether 32 ROPs is enough on this design. Fermi has 48 ROPs and about a billion transistors less. I think AMD is losing AA performance due to such a skimpy ROP count.

    Overall the card is good regardless, but the pricing is indeed steep. I'm sure people will buy it nonetheless, but as a 365mm^2 chip with 3GB GDDR5 I feel like it should be 100$ cheaper than what it is now. I blame lack of competition. It's Nvidia's time to drop the prices. GTX 580 is simply not worth that much compared to what 6950/560Ti are going for these days. And in turn that should drop 7970/50 price.
    Reply
  • nadavvadan - Friday, December 23, 2011 - link

    Am I really tired, or is:
    " 3.79TFLOPs, while its FP64 performance is ¼ that at 947MFLOPs"
    supposed to be:
    " 3.79TFLOPs, while its FP64 performance is ¼ that at 947-G-FLOPs"?

    Enjoyed the review as always.
    Reply
  • Death666Angel - Friday, December 23, 2011 - link

    Now that you have changed the benchmark, would it be possible to publish a .pdf with the relevant settings of each game? I would be very interested to replicate some of the tests with my home system to better compare some results. If it is not too much work that is (and others are interested in this as well). :D Reply
  • marc1000 - Friday, December 23, 2011 - link

    What about juniper? Could it make it's way to the 7000 series as a 7670 card? Of course, upgraded to GCN, but with same specs as current cards. I guess that at 28nm it would be possible to abandon the pci-e power requirement, making it the go-to card for oem's and low power/noise systems.

    I would not buy it because I own one now, but I'm looking forward to 7770 or 7870 and their nvidia equivalent. It looks like next year will be a great time to upgrade for who is in the middle cards market.
    Reply
  • Scali - Saturday, December 24, 2011 - link

    I have never heard Jen-Hsun call the mock-up a working board.
    They DID however have working boards on which they demonstrated the tech-demos.
    Stop trying to make something out of nothing.
    Reply

Log in

Don't have an account? Sign up now