AMD Delivers OverDrive Overclocking Support For AMDGPU DRM Driver

[phoronix]

Phoronix: AMD Delivers OverDrive Overclocking Support For AMDGPU DRM Driver

AMD has published patches today for the AMDGPU Linux kernel DRM driver that finally make it possible to overclock the GPU when using the open-source driver...

http://www.phoronix.com/scan.php?page=news_item&px=AMDGPU-OverDrive-Support

[FireBurn]

Just trying it now

[nranger]

To be fair, a simple sysfs file is actually pretty nice. By comparison, my Nvidia card requires the "CoolBits" parameter in xorg.conf then a .desktop autostart file pointing to a shell script that contains a number of commands including "nvidia-settings -a '[gpu:0]/GPUGraphicsClockOffset[3]=59'" and "nvidia-settings -a '[gpu:0]/GPUMemoryTransferRateOffset[3]=1050'"

Not exactly "user friendly". Here's hoping AMD adds memory clock and voltage controls as well.

[schmidtbag]

nice, I wasn't expecting this. Any chance of Hawaii eventually being supported?

[gsedej]

Just trying it now

he never came back... buying new nvidia #sarcasm

How did it go?

[Soul_keeper]

This is nice.
I enjoyed working with the adl sdk and the closed drivers, but since switching fulltime to the open drivers i've missed using the program I had.
This will make me even more excited about the upcoming video cards from amd.
Michael could you check for underclocking/undervolting functionality when testing this ?
thanks

[Osmodivs]

When are we going to get nice cool looking GUIs like other SOs? I hate to write scripts, heck, I don't even know how to write scripts! Only geeks get to try cool features...

[agd5f]

If testing on Tonga, please apply this patch as well:

https://lists.freedesktop.org/archives/dri-devel/2016-May/107520.html

[bridgman]

The idea is that DE's would implement standard GUIs that work across all HW vendors, using sysfs controls to interact with the drivers. It never seems to quite get to the top of the DE priority list though. The obvious alternative is vendor-specific GUIs, but that really does seem like throwaway work if we're going to end up with DE-level GUIs.

I'm wondering if it would make sense to implement a simple command-line utility for now, since as soon as we release a GUI for something the next question is usually "how do I script it ?". On the other hand all the CLU would do is remember the details of how the sysfs interface works...

Is the real need for an actual GUI (because sliders are cooler than text), persistence of settings across reboots, or the ever-popular "forcing settings that the OSS driver developers all agree should be handled in the app not the driver" ?

Other than putting a civilized face on dual-GPU setups, my impression is that two top priorities are (a) persistence of settings and (b) ability to force settings that the driver devs don't thing are a good idea and haven't actually implemented as driver over-rides in the first place

[eydee]

Simple script/CLI for OSS, people can make a GUI if they want to. But put fully featured Overdrive UI into the pro drivers. That one is supposed to be on par with the windows counterpart and feature complete.