Fiji’s Architecture: The Grandest of GCN 1.2

We’ll start off our in-depth look at the R9 Fury X with a look at the Fiji GPU underneath.

Like the Hawaii GPU before it, from a release standpoint Fiji is not really the pathfinder chip for its architecture, but rather it’s the largest version of it. Fiji itself is based on what we unofficially call Graphics Core Next 1.2 (aka GEN3), and ignoring HBM for the moment, Fiji incorporates a few smaller changes but otherwise remaining nearly identical to the previous GCN 1.2 chips. The pathfinder for GCN 1.2 in turn was Tonga, which was released back in September of 2014 as the Radeon R9 285.

So what does GCN 1.2 bring to the table over Hawaii and the other GCN 1.1 chips? Certainly the most well-known and marquee GCN 1.2 feature is AMD’s latest generation delta color compression technology. Tied in to Fiji’s ROPs, delta color compression augments AMD’s existing color compression capabilities with additional compression modes that are based around the patterns of pixels within a tile and the differences between them (i.e. the delta), increasing how frequently and by how much frame buffers (and RTs) can be compressed.

Frame buffer operations are among the most bandwidth intensive in a GPU – it’s a lot of pixels that need to be resolved and written to a buffer – so reducing the amount of memory bandwidth these operations draw on can significantly increase the effective memory bandwidth of a GPU. In AMD’s case, GCN 1.2’s delta color compression improvements are designed to deliver up to a 40% increase in memory bandwidth efficiency, with individual tiles being compressible at up to an 8:1 ratio. Overall, while the lossless nature of this compression means that the exact amount of compression taking place changes frame by frame, tile by tile, it is at the end of the day one of the most significant improvements to GCN 1.2. For Radeon R9 285 it allowed AMD to deliver similar memory performance on a 256-bit memory bus (33% smaller than R9 280’s), and for Fiji it goes hand-in-hand with HBM to give Fiji an immense amount of effective memory bandwidth to play with.

Moving on, AMD has also made some changes under the hood at the ALU/shader level for GCN 1.2. Many of these changes are primarily for AMD’s Carrizo APU, where task scheduling improvements go hand-in-hand with the AMD’s Heterogeneous System Architecture initiative and deliver improvements to allow the CPU and GPU to more easily deliver work to each other. Similarly, 16-bit instructions are intended to save on power consumption in mobile devices that use lower precision math for basic rendering.

More applicable to Fiji and its derivatives are the improvements to data-parallel processing. GCN 1.2 now has the ability for data to be shared between SIMD lanes in a limited fashion, beyond existing swizzling and other data organizations methods. This is one of those low-level tweaks I’m actually a bit surprised AMD even mentioned (though I’m glad they did) as it’s a little tweak that’s going to be very algorithm specific. For non-programmers there’s not much to see, but for programmers – particularly OpenCL programmers – this will enable newer, more efficient algorithms where when the nature of the work requires working with data in adjacent lanes.

But for gamers, perhaps the most significant architectural improvement to GCN 1.2 and thereby Fiji are the changes made to tessellation and geometry processing. There is no single silver bullet here – after going with a 4-wide geometry front-end in Hawaii, AMD hasn’t changed it for Tonga or Fiji – but AMD has put in quite a bit of effort in to improving how geometry data moves around within the chip and how it’s used, on the basis that at this point the limitations aren’t in raw geometry performance, but rather the difficulties in achieving that performance.

Much of this effort has been invested in better handling small geometry, whether it’s large quantities of small batches, or even small quantities of small batches. The inclusion of small instance caching, for example, allows the GPU to better keep small batches of draw calls in cache, allowing them to be referenced and/or reused in the future without having to go to off-cache memory. Similarly, AMD can now store certain cases of vertex inputs for the geometry shader in shared memory, which like small instance caching allows for processing to take place more frequently on-chip, improving performance and cutting down on DRAM traffic.

More specific to Fiji’s incarnation of GCN is how distribution is handled. Load balancing and distribution among the geometry frontends is improved overall, including some low-level optimizations to how primitives generated from tessellation are distributed. Generally speaking distribution is a means to improve performance by removing bottlenecks, however AMD is now catching a specific edge case where small amplification factors don’t generate a lot of primitives, and in those cases they’re now skipping distribution since the gains are minimal, and more likely than not the cost from the bus traffic is greater than the benefits of distribution.

Finally, AMD has also expanded the vertex reuse window on GCN 1.2. As in the general case of reuse windows, the vertex reuse window is a cache of sorts for vertex data, allowing old results to be held in waiting in case they are needed again (as is often the cases in graphics). Though they aren’t telling us just how large the window now is, GCN 1.2 now features a larger window, which increases the hit rate for vertex data and as a result further edges geometry performance up since that data no longer needs to be regenerated.

As with our R9 285 review, I took the time to quickly run TessMark across the x8/x16/x32/x64 tessellation factors just to see how tessellation and geometry performance scales on AMD’s cards as the tessellation factor increases. Keeping in mind that all of the parts here have a 4-wide geometry front-end, the R9 285, R9 290X, and R9 Fury X all have the same geometry throughput on paper, give or take 10% for clockspeeds. What we find is that Fury X shows significant performance improvements at all levels, beating not only the Hawaii based R9 290X, but even the Tonga based R9 285. Tessellation performance is consistently 33% ahead of the R9 290X, while against Tonga it’s anywhere between a 33% lead at high factors to a 130% lead at low tessellation factors, showing the influence of AMD’s changes to how tessellation is handled with low factors.

The AMD Radeon R9 Fury X Review The Fiji GPU: Go Big or Go Home
Comments Locked

458 Comments

View All Comments

  • Ryan Smith - Friday, July 3, 2015 - link

    Crossfire will likely exacerbate the problem a bit. You need a few extra buffers for AFR, so that further eats into the memory pool.
  • chizow - Sunday, July 5, 2015 - link

    Yep, also more likely to use up GPU overhead to enable any sliders that were disabled to run adequately with just 1xGPU, crank up AA modes etc. Quite easy to surpass 4GB and even 6GB under these conditions, even at 1440p.
  • wiak - Thursday, July 2, 2015 - link

    just to trow this here
    i believe the current cooler might be used on the Fury X2 (MAXX?)
    why? both the power and cooling is over engineered, so that might point to it being used on another card in the future, why? economy of scale, if amd gets alot of 500W coolers from cooler master then they get them cheaper..
  • meacupla - Friday, July 3, 2015 - link

    I think the cooler is over-engineered because AMD didn't want a repeat of hot and loud 290/290X stock coolers, because they imagined someone with a crap case would buy one and because even the weakest CLLC coolermaster had was capable of handling a Fury X.

    These 120mm CLLC are far superior to heatpipe heatsinks on GPUs. It's the equivalent of slapping a 120mm CPU tower cooler onto your GPU. Standard GPU heatsinks, on the other hand, are on a similar performance level to low profile CPU coolers.

    You can probably imagine the issue with putting on a 120mm tower cooler onto a GPU.
  • rs2 - Thursday, July 2, 2015 - link

    Even at 1440p with all of the settings maxed (8xMSAA, post-processing on, Map set 4, x64 tessellation) I can get the 980 Ti to score below 300fps in TessMark. The Fury X numbers are underwhelming by comparison.
  • rs2 - Thursday, July 2, 2015 - link

    can't*
  • Nagorak - Sunday, July 5, 2015 - link

    TessMark...sounds like a really exciting game.
  • mac2j - Thursday, July 2, 2015 - link

    I've always rooted for AMD in the CPU and GPU arenas so I'm sad to see the writing so clearly etched on the wall now. They've all but surrendered in the CPU arena and now a sub-par flagship GPU marketed at 4K gaming BUT without HDMI 2.0 support - really? I just hope whoever buys them can keep them in tact and we don't end up with a sell off resulting in an Intel CPU monopoly and an Nvidia GPU monopoly.
  • althaz - Thursday, July 2, 2015 - link

    Seems like a decent card - but not one that (as somebody who is brand-agnostic) I could justifiably buy. Hopefully it comes in with a price-drop or we see a factory OC versions which bumps performance up another 10%.

    I would rather buy an AMD card right now, purely because Freesync monitors are totally happening and they aren't overly expensive compared to regular monitors.

    On the other hand, if this matched the GTX 980 Ti precisely in performance, the fact that it has only 4Gb of VRAM is certainly an issue.

    So whilst this product is impressive compared to its predecessors, overall, it's (IMO) mostly a disappointment.

    Hopefully next year (I'm gunna need a new GFX card pretty badly by then) brings some more impressive cards.
  • mapesdhs - Friday, July 3, 2015 - link

    People were saying 'hopefully' last year, and look where we are now.

Log in

Don't have an account? Sign up now