Bug 97590 - Fury X (Fiji) LEDs do not reflect GPU load
Summary: Fury X (Fiji) LEDs do not reflect GPU load
Status: RESOLVED FIXED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/Gallium/radeonsi (show other bugs)
Version: git
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Default DRI bug account
QA Contact: Default DRI bug account
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-09-04 08:55 UTC by Adam Bolte
Modified: 2017-05-22 01:19 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:


Attachments
possible fix (2.69 KB, patch)
2017-02-22 16:23 UTC, Alex Deucher
Details | Splinter Review
possible fix (2.64 KB, patch)
2017-02-22 23:36 UTC, Alex Deucher
Details | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Adam Bolte 2016-09-04 08:55:20 UTC
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.
Comment 1 John Bridgman 2016-09-04 19:23:44 UTC
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.
Comment 2 Adam Bolte 2016-09-05 09:44:40 UTC
Ah yep. Found the article you were referring to.

http://www.phoronix.com/scan.php?page=news_item&px=Nouveau-LED-Driver
Comment 3 Adam Bolte 2017-02-22 13:03:14 UTC
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.
Comment 4 Alex Deucher 2017-02-22 16:23:52 UTC
Created attachment 129828 [details] [review]
possible fix

Does this patch work?
Comment 5 Adam Bolte 2017-02-22 22:25:58 UTC
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.
Comment 6 Alex Deucher 2017-02-22 23:36:22 UTC
Created attachment 129851 [details] [review]
possible fix

This should apply cleanly to upstream.
Comment 7 network723 2017-02-23 13:16:43 UTC
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?
Comment 8 Alex Deucher 2017-02-23 13:46:19 UTC
(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?
Comment 9 Adam Bolte 2017-02-23 14:18:57 UTC
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.
Comment 10 Adam Bolte 2017-02-23 15:32:38 UTC
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.
Comment 11 Alex Deucher 2017-02-23 15:41:28 UTC
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.
Comment 12 Adam Bolte 2017-02-23 21:12:43 UTC
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?
Comment 13 Alex Deucher 2017-02-23 21:21:19 UTC
I've queued the patch for upstream.  I'll close it once the patch makes it into Linus' tree.
Comment 14 Vedran Miletić 2017-02-25 11:56:14 UTC
(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?
Comment 15 Alex Deucher 2017-02-28 15:12:58 UTC
(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.
Comment 16 Adam Bolte 2017-05-21 03:33:48 UTC
Looks like this patch has found its way into 4.12-rc1. Thanks again Alex.
Comment 17 Michel Dänzer 2017-05-22 01:19:18 UTC
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.