Announcement

Collapse
No announcement yet.

AMDGPU Gets Some Promising Fixes For Linux 5.4: Clang, Undervolting, Golden Settings

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • #11
    Originally posted by discordian View Post
    Looking at their windows control panel, there is hope we never see one from AMD. Seriously, I can search the switches and type them in a commandline faster than that damn thing opens.
    I turned the file WattmanGTK creates into an on-boot systemd service. Best of both worlds -- GUI to tweak lots of settings with an easy-to-use interface; CLI to implement it and do quick edits.

    Comment


    • #12
      What does golden settings mean?

      Comment


      • #13
        It's a list of "program value X into register Y" register settings provided by the HW block teams whenever the recommended setting does not match the power-on default value for a register.

        Golden settings for most blocks are picked up by VBIOS, but GFX and SDMA golden settings are picked up by the kernel driver because VBIOS does not touch those blocks.

        Comment


        • #14
          So I'm guessing uvd states are still kind of off-limits regarding overclocking/underclocking/undervolting. A while back did a bios flash overclock (GPU:600->680MHz, Mem:400->480MHz) of the uvd state on an old passive ATI/AMD HD 4650 AGP card and got about 10fps boost doing a benchmark with mpv with hardware decoding on. This made it possible to enable some of the higher quality features of mpv.

          Next up would be a HD 7770, which would likely at least benefit from an undervolt on the higher uvd state and memory underclock on a two display setup on the second idle state. Unfortunately there still isn't hardware acceleration for video on GCN 1.0 with AMDGPU so testing uvd state undervolting anyway would still require bios flashing. Vulkan video decoding is coming next year, so fingers crossed.

          Comment


          • #15
            Originally posted by bridgman View Post
            It's a list of "program value X into register Y" register settings provided by the HW block teams whenever the recommended setting does not match the power-on default value for a register.

            Golden settings for most blocks are picked up by VBIOS, but GFX and SDMA golden settings are picked up by the kernel driver because VBIOS does not touch those blocks.
            By the way, do you happen to know, if 30+ W power consumption for Navi is normal for 2560 x 1440 / 144 Hz operation, or it's excessive? Some suggest it's a limitation of GDDR6 vs HBM2 in Vega, that's why later requires less power. But others said they operate fine at lower wattage with Navi somehow.

            See: https://bugs.freedesktop.org/show_bug.cgi?id=111482

            Currently, my Sapphire Pulse RX 5700 XT has that annoying bug, that after resume, it uses lower power / mclk, which causes flickering.

            Comment


            • #16
              Originally posted by jrdoane View Post
              It's really fucky. Whenever I touch voltages, they all just seem to jump to 1.20v. If I undo the voltage change, it goes back to normal. It's insane. I've had this issue ever since I could start fiddling with /sys/class/drm/card0/device/pp_od_clk_voltage.
              I was having the same problem. But I upgraded to Vega just this year and somehow I couldn't imagine that no one had this problem before in all years this architecture already exists. So I didn't report it. But I was measuring with a power meter and saw that things went in the bad direction... In the end, I gave up on this. Great that someone popped up and wrote a patch. It's just a little late AMD.

              Comment


              • #17
                Originally posted by Strunkenbold View Post

                I was having the same problem. But I upgraded to Vega just this year and somehow I couldn't imagine that no one had this problem before in all years this architecture already exists. So I didn't report it. But I was measuring with a power meter and saw that things went in the bad direction... In the end, I gave up on this. Great that someone popped up and wrote a patch. It's just a little late AMD.
                It remains to be seen if it actually fixes it. I'm waiting for a mainline build for the next RC to test it (since I'm on Ubuntu and I'm too lazy to build it myself.) Since they said it was with P7, I decided to try and change the voltage on another level to see if the behavior was any different, and it wasn't. So, it might be a different bug. If it's still there, it might be worth while reporting it. The last time I was browsing the bug tracker for AMDGPU, I didn't see anything, but that was months ago.

                Edit: It looks like there is an RC6 build already. I might actually test this out right now.

                Edit 2: No dice. It still forces 1.20v on all p-states with any voltage change.
                Last edited by jrdoane; 11-04-2019, 07:59 PM.

                Comment


                • #18
                  If I'm willing to sacrifice some performance for lower temps and fan speeds, should I even muck about with undervolting, or just go straight for clock speed (assuming that's even controllable)?

                  Also, where is all of this documented?

                  FWIW, I have a Radeon VII. Thanks.

                  Comment


                  • #19
                    Originally posted by coder View Post
                    Also, where is all of this documented?
                    It's in the kerneldoc for the driver. E.g.,
                    https://dri.freedesktop.org/docs/drm...and-monitoring

                    Comment

                    Working...
                    X