Under Catalyst (fglrx) on Ubuntu 14.04, LEDs on Fury X graphics cards would reflect the GPU load. This behaviour matches Windows. ie. Stand-by mode would utilize a single green LED, low power would use one red LED, max power would light up all 8 LEDs, etc. You can see this behaviour here: https://www.youtube.com/watch?v=Evkk4HmjHOw This helps give a nice immediate visual feedback showing what the cards are actually doing, and can improve PC build aesthetics. Since upgrading to AMDGPU + Mesa, all LEDs are permanently on, implying full load (or maximum power draw?) at all times. Hopefully this is not what is actually happening. FWIW, the AMDGPU Pro stack also has this issue.
There was a Phoronix article recently celebrating the addition of an LED driver to the Nouveau driver... guessing that something similar will need to be done for amdgpu eventually.
Ah yep. Found the article you were referring to. http://www.phoronix.com/scan.php?page=news_item&px=Nouveau-LED-Driver
Is it possible the driver code for the LED controller used by fglrx can be released to get the ball rolling on this? Someone I should get in contact with perhaps? Or is this actually being worked on (or at least scheduled to be worked on) internally at AMD? It's been almost six months since this regression was initially reported (I am told the free software stack is the AMD-recommended upgrade path for consumers, so I feel justified in calling it a regression from that perspective). I know the AMD devs are busy people, but it would be great to see some progress on this before the cards I purchased are eventually retired.
Created attachment 129828 [details] [review] possible fix Does this patch work?
Wow Alex - I wasn't expecting anything for months, let alone hours! Thanks! I'll certainly be trying this out tonight and will report back as soon as I know.
Created attachment 129851 [details] [review] possible fix This should apply cleanly to upstream.
AFAIK, Sapphire RX480/470 Nitro boards also have LEDs that change colors depending on GPU Load / temperature (displaying mode can be switched with hardware button). Would it work for them too?
(In reply to network723 from comment #7) > AFAIK, Sapphire RX480/470 Nitro boards also have LEDs that change colors > depending on GPU Load / temperature (displaying mode can be switched with > hardware button). Would it work for them too? No. I don't see any relevant code for polaris. Those may be some OEM specific implementation handled independently of the driver. Do they work?
I'm very excited to say that this patch is working great. Huge thanks! I know it's crazy but there's something very satisfying about having the LEDs show what the cards are doing. :) I noticed attachment 129828 [details] [review] applies cleanly to 4.10 so I ended up using that. I tried to test attachment 129851 [details] [review] but wasn't sure which repo/branch I was supposed to apply it to. I tried git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git (master branch) and git://people.freedesktop.org/~airlied/linux (drm-next branch) but I'm clearly looking in the wrong place. Happy to re-test if you point me in the right direction of the correct kernel source code to use. Many games were tested (including a number under Wine with Gallium on Nine and d3d9 patches). I only tested this against the free software stack so far. I tested the Talos Principle (to test Vulkan), a bunch of Feral ports, etc. At all times the first Fury X LEDs on the primary card would flicker in the same way as they do under Windows, which is terrific. The only difference between this patch and the Windows behaviour is with the second card at idle - Windows will display only a single green LED which I believe indicates the card is in its lowest power mode. I was unable to reproduce that same status with your patch. However I'm guessing this means Windows puts the unused card in to a lower power state than AMDGPU is currently able, and the LEDs are actually doing the right thing. No big deal either way. Thanks again Alex.
I found the repo (git://people.freedesktop.org/~agd5f/linux and the drm-next-4.12-wip branch with the commit already applied), so I built that for testing but didn't have any luck. The primary GPU LEDs were stuck on maximum, the second was a single blue LED (as before), and I lost signal multiple times when trying to log in through my display manager. Probably some unrelated regression is affecting that branch, preventing my testing of your revised patch.
Use whichever patch applies to your tree. They are identical other than some fuzz related to other changes in the same file depending on what kernel version you are using.
Good to know it doesn't matter for testing purposes. In that case, I'm happy for this to be marked as fixed - unless the policy on doing that is to wait until the patch is accepted upstream?
I've queued the patch for upstream. I'll close it once the patch makes it into Linus' tree.
(In reply to Adam Bolte from comment #9) > The only difference between this patch and the Windows behaviour is with the > second card at idle - Windows will display only a single green LED which I > believe indicates the card is in its lowest power mode. I was unable to > reproduce that same status with your patch. However I'm guessing this means > Windows puts the unused card in to a lower power state than AMDGPU is > currently able, and the LEDs are actually doing the right thing. No big deal > either way. Alex, can you comment on this? Is it a known issue?
(In reply to Vedran Miletić from comment #14) > (In reply to Adam Bolte from comment #9) > > The only difference between this patch and the Windows behaviour is with the > > second card at idle - Windows will display only a single green LED which I > > believe indicates the card is in its lowest power mode. I was unable to > > reproduce that same status with your patch. However I'm guessing this means > > Windows puts the unused card in to a lower power state than AMDGPU is > > currently able, and the LEDs are actually doing the right thing. No big deal > > either way. > > Alex, can you comment on this? Is it a known issue? Windows powers down dGPUs when they are not in use. This is not supported yet in Linux outside of PX systems.
Looks like this patch has found its way into 4.12-rc1. Thanks again Alex.
Thanks for the report and testing.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.