GCN 1.2: Geometry Performance & Color Compression

Instruction sets aside, Radeon R9 285 is first and foremost a graphics and gaming product, so let’s talk about what GCN 1.2 brings to the table for those use cases.

Through successive generations of GPU architectures AMD has been iterating on and improving their geometry hardware, both at the base level and in the case of geometry generated through tessellation. This has alternated between widening the geometry frontends and optimizing the underlying hardware, with the most recent update coming in the GCN 1.1 based Hawaii, which increased AMD’s geometry processor count at the high end to 4 processors and implemented some buffering enhancements.

For Tonga AMD is bringing that 4-wide geometry frontend from Hawaii, which like Hawaii immediately doubles upon Tahiti’s 2-wide geometry frontend. Not stopping there however, AMD is also implementing a new round of optimizations to further improve performance. GCN 1.2’s geometry frontend includes improved vertex reuse (for better performance with small triangles) and improved work distribution between the geometry frontends to better allocate workloads between them.

At the highest level Hawaii and Tonga should be tied for geometry throughput at equivalent clockspeeds, or roughly 2x faster than Tahiti. However in practice due to these optimizations Tonga’s geometry frontend is actually faster than Hawaii’s in at least some cases, as our testing has discovered.

Comparing the R9 290 (Hawaii), R9 285 (Tonga), and R9 280 (Tahiti) in TessMark at various tessellation factors, we have found that while Tonga trails Hawaii at low tessellation factors – and oddly enough even Tahiti – at high tessellation factors the tables are turned. With x32 and x64 tessellation, the Tonga based R9 285 outperforms both cards in this raw tessellation test, and at x64 in particular completely blows away Hawaii, coming close to doubling its tessellation performance.

At the x64 tessellation factor we see the R9 285 spit out 134fps, or equivalent to roughly 1.47B polygons/second. This is as compared to 79fps (869M Polys/sec) for the R9 290, and 68fps (748M Polys/sec) for the R9 280. One of the things we noted when initially reviewing the R9 290 series was that AMD’s tessellation performance didn’t pick up much in our standard tessellation benchmark (Tessmark at x64) despite the doubling of geometry processors, and it looks like AMD has finally resolved that with GCN 1.2’s efficiency improvements. As this is a test with a ton of small triangles, it looks like we’ve hit a great case for the vertex reuse optimizations.

Meanwhile AMD’s other GCN 1.2 graphics-centric optimization comes at the opposite end of the rendering pipeline, where the ROPs and memory controllers lie. As we mentioned towards the start of this article, one of the notable changes between the R9 280 and R9 285 is that the latter utilizes a smaller 256-bit memory bus versus the R9 280’s larger 384-bit memory bus, and as a result has around 27% less memory bandwidth than the R9 280. Under most circumstances such a substantial loss in memory bandwidth would result in a significant performance hit, so for AMD to succeed Tahiti with a smaller memory bus, they needed a way to be able to offset that performance loss.

The end result is that GCN 1.2 introduces a new color compression method for its ROPs, to reduce the amount of memory bandwidth required for frame buffer operations. Color compression itself is relatively old – AMD has had color compression in some form for almost 10 years now – however GCN 1.2 iterates on this idea with a color compression method AMD is calling “lossless delta color compression.”

Since AMD is only meeting us half-way here we don’t know much more about what this does. Though the fact that they’re calling it delta compression implies that AMD has implemented a further layer of compression that works off of the changes (deltas) in frame buffers, on top of the discrete compression of the framebuffer. In this case this would not be unlike modern video compression codecs, which between keyframes will encode just the differences to reduce bandwidth requirements (though in AMD’s case in a lossless manner).

AMD’s own metrics call for a 40% gain in memory bandwidth efficiency, and if that is the average case it would more than make up for the loss of memory bandwidth from working on a narrower memory bus. We’ll see how this plays out over our individual games over the coming pages, but it’s worth noting that even our most memory bandwidth-sensitive games hold up well compared to the R9 280, never losing anywhere near the amount of performance that such a memory bandwidth reduction would imply (if they lose performance at all).

Tonga’s Microarchitecture – What We’re Calling GCN 1.2 GCN 1.2 – Image & Video Processing
Comments Locked


View All Comments

  • MrSpadge - Thursday, September 11, 2014 - link

    The point is that Tonga is NOT a rebrand. It's a brand-new chip, AMD themselves call it the 3rd generation of GCN. Making a new chip costs AMD a sgnificant amount of money, that's why they haven't bothered yet to update Pitcairn to at least 2nd gen GCN (1.1). And I'm totally fine with that. It's also OK for nVidia to use GK104 for GTX760. What's not OK - from my point of view - is AMD investing into this new chip Tonga and hardly getting any real world benefit over the 3 year old Tahiti designs. If nVidia introduces a Maxwell which performs and costs them just the same as the previous Kepler, I'll call them out for this as well. But this is pretty much excluded, from what we've seen so far.

    "And I highly doubt the 285 is 'all amd has'."
    It's their 3rd gen GCN architecture, as they say themselves. There's going to be a bigger chip using this architecture, but apart from that I doubt we'll see anything from AMD in the next year which is not yet in Tonga.
  • just4U - Friday, September 12, 2014 - link

    The one nice thing about the 285 is it will have resale value that has been lost on the 280-290 series thanks in large part to bit mining. There's a good chance that most won't feel that the 285 (and future incarnations) were run into the ground like the earlier ones were.
  • Frenetic Pony - Wednesday, September 10, 2014 - link

    Nah, what's interesting is that Maxwell may not be worth "responding" too. It's an almost totally mobile focused design, one that's not even totally out yet. If these benchmarks hold true then it's very exciting for AMD's upcoming high end. Nvidia may end up with a 512bit bus as well, but AMD's bandwidth optimizations will mean a similarly specced card of their's will still handily beat anything NVIDIA has in terms of resolution scaling.

    Heck it may even be enough to get a single GPU capable of running games at 4k at a reasonable fps. And that would be awesome. Maxwell might be good for Nvidia's mobile business, but I doubt it's going to help them take back the top spot for high end stuff from AMD.
  • mindbomb - Wednesday, September 10, 2014 - link

    UVD always supported vc-1. The first version supported full decode of h264 and vc-1. You are thinking of nvidia, who didn't have full hardware decode on a real desktop part until fermi.
  • mindbomb - Wednesday, September 10, 2014 - link

    Not that it matters really. It stopped being relevant when hd-dvd lost to bluray.
  • Navvie - Thursday, September 11, 2014 - link

    A lot of blu-rays have vc-1 content.
  • nathanddrews - Thursday, September 11, 2014 - link

    Blu-ray.com has a database that you can search by codec. VC-1 is very much alive and thriving.
  • Ryan Smith - Wednesday, September 10, 2014 - link

    According to my DXVA logs, the 280 did not support VC-1/WMV9. That is what I'm basing that on.
  • mindbomb - Wednesday, September 10, 2014 - link

    I think your logs are referring to the nvidia gtx 280, which did not support full vc-1 decode. AMD had it since the radeon 2600xt, which is ancient.
  • NikosD - Saturday, September 13, 2014 - link


    One of the main advantages of first generation UVD (ATI Radeon HD2000 series) over Nvidia, was the full DXVA VLD support of both 1080p H.264 L4.1 (BluRay spec) and VC-1.

Log in

Don't have an account? Sign up now