Trying The Experimental Radeon RX 480 Overclocking With AMDGPU OverDrive Isn't Going So Well

Written by Michael Larabel in Display Drivers on 10 July 2016. Page 1 of 2. 18 Comments

With the Linux 4.8 kernel coming later this year one of the main end-user additions to the AMDGPU kernel driver is GPU overclocking support via OverDrive. This is the first time AMD GPU overclocking is being offered via their open-source Linux driver and so I decided to try it out with the AMD Radeon RX 480 using this experimental DRM-Next code.

A few months back I tried out the initial AMD open-source OverDrive support and it worked okay: it allowed manipulating the GPU core clock speed as a percent via the sysfs interface. I was able to overclock the R9 Fury by 8%. With that initial code there wasn't memory overclocking support, but that was since added and will be featured in Linux 4.8 too.

If you missed the earlier articles, this AMDGPU OverDrive support is provided via writing a value between 0 and 20 to the pp_mclk_od or pp_sclk_od sysfs interfaces depending whether you want to overclock the memory or GPU core, respectively. The 0-20 value represents the percentage to overclock the system by. It's all command-line based right now with no GUI nor not nearly as advanced as AMD's new WattMan offered by Radeon Software on Windows. But at least this basic GPU overclocking is now available for the latest GCN GPUs supported by the AMDGPU kernel driver: AMD hasn't said whether they intend to implement GPU overclocking for any of the pre-GCN GPUs on the open-source driver.

Unfortunately, my AMDGPU OverDrive experience with the Radeon RX 480 on the latest drm-fixes-4.7 + drm-next-4.8 merged branch didn't go so well. While the RX 480 stock is running fine on the new AMDGPU code for Linux 4.8, the overclocking experience didn't turn out that good. When trying to overclock this Polaris graphics card by 4% or higher, I'd ultimately hit stability issues. 3% was the highest overclock I was able to achieve while running stable. This 3% overclock isn't anything special and rather dismal compared to the various RX 480 Windows overclocking results with WattMan.

Making matters worse, when overclocking the video memory on the RX 480 the performance was much worse... There's something clearly wrong right now with the pp_mclk_od handling for at least the RX 480 with this experimental code coming to Linux 4.4... The performance was significantly worse.

When looking at the dmesg for the bugged video memory reclocking, there were many "VDDCI is larger than max VDDCI in VDDCI voltage table" messages. Based upon the results, I'd bet that the GPU was then forced down into the lowest performance state.

If you are curious about these numbers, see the next page.

Related Articles