Introduction

AMD's new "Fiji" GPU debuted just weeks ago in the AMD Radeon R9 Fury X, a compact card with watercooling that's built exclusively by AMD. Following that, we saw the release of the Radeon R9 Fury, a regular full-sized card that's not built by AMD, but its partners ASUS, Sapphire, and PowerColor. Later this year, we expect the Radeon R9 Nano to come out, an air-cooled mini-ITX variant of the Fury Series.



Overclockers had high hopes for these cards, but were quickly disappointed when word spread that neither memory overclocking nor voltage control would be available on the Radeon Fury series. Normal overclocking without voltage increases yields an increase of around 10% in clocks, which is a little on the low side, but not unexpected for a new GPU chip.

Implementing voltage control on Fiji was more difficult than on most other cards. While the voltage controller on these cards is well-known and supports I2C (a method to talk to the voltage chip from the host PC through software), getting I2C to work on Fiji in the first place posed another set of challenges. Unlike NVIDIA, AMD does not provide good API support to developers, their ADL library outdated and buggy, with updates spaced years apart. So most software utility developers implement hardware access in the hardware itself to write directly to the GPU registers AMD is changing with every new GPU. AMD's developer support is pretty much non-existent these days. All my contact has been worried about for four weeks now is that I make sure I use AMD's "new" GPU codenames in GPU-Z (for the R9 300 Series re-brands).

With recent GPU generations, AMD has transitioned GPU management tasks away from the driver and onto a little micro-controller inside the GPU dubbed SMC, which is tasked to handle jobs like clock control, power control, and voltage control. On Fiji, this controller dynamically adjusts and monitors voltage, which helps with overall power consumption. However, it makes voltage control more difficult than before. When overriding voltage externally, the controller will sense a discrepancy between its target and the real voltage. Assuming a fault has occurred, it puts the GPU into its lowest clock state: 300 MHz. The voltage monitoring process also keeps the I2C bus very busy, which causes interference with other transactions, such as those sent by GPU-Z to do its own monitoring. If two of these transactions overlap, the resulting data will be intermixed or faulty, which will cause the SMC to sense another possible fault that has it set fan speed to 100% to avoid damage to the card after turning off the screen.

Working around this was no easy task, but it looks like I've finally managed to crack it, so voltage monitoring and software voltage control will soon be available in the software I make; other tool developers will soon follow as well.

On the following page, we will investigate what gains can be achieved from voltage adjustments to the Radeon Fury, how these overclocking results translate into real performance, and what this means for power consumption.