Announcement

Collapse
No announcement yet.

AMDGPU Kernel Driver Is Working Out Well On Linux 5.0

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

  • #11
    Originally posted by debianxfce View Post
    Flickering means that there is not enough power to drive displays.
    Nope. Flickering can happen for many reasons but in this case it's the amdgpu trying to change mclk at the wrong time. In Alex Deucher words:
    Memory reclocking has to happen during the vblank period to avoid flickering.
    Originally posted by debianxfce View Post
    Pro gamers use single monitor and there is no advantage of dual screens.
    Pro gamers (people who compete and earn money playing games) don't use Linux. Almost every big streamer (people who make money playing games, thus also "pro gamers") uses multiscreen setups.
    Originally posted by debianxfce
    Also Michael uses ubuntu that is more stable and maybe lighter for the GPU than fedora.
    nope, that's just your assumption
    Originally posted by debianxfce View Post

    See, no sense to compile Mesa by yourself. I have been using freesync over a month: https://www.youtube.com/watch?v=lGesNjhUo-w

    You should use Debian packages with Debian. Debian packages are easy to update and remove. They are designed to work together.
    There are a lot of reasons to compile mesa by yourself. Native gcc optimizations, including/removing specific drivers, using out-of-tree patches (I had freesync long before you got it in oibaf) etc. It's not that difficult to build it in to a deb package anyway, but that is one of the reasons me and others use Arch-based distros (PKGBUILDs are perfect for stuff like this). Stop assuming your setup is the best for everyone and only then you might have a chance to stop making yourself a fool for people with a clue of what they're doing.

    Originally posted by debianxfce View Post

    No changes in the idle governor. The CPU frequency governor slows down and is an optional feature of the Linux kernel so remove it. Using the Bios is a better way to control CPU power and fans. Power consumption depends of your other hardware too.
    If you read the code and docs you'll see there is no difference between "performance" governor and removing governor completely. Both let the bios control frequencies directly.
    Last edited by clapbr; 01-22-2019, 02:40 PM.

    Comment


    • #12
      Originally posted by debianxfce View Post
      There is a bug with RX570 and 4K60Hz resolution that the dynamic powerplay feature is disabled and the engine clock is fixed to 1200Mhz. The fix for this is to use the kernel command line parameter amdgpu.ppfeaturemask=0xfffd7fff. You could try that too.
      With a single 4K 60Hz monitor there is no bug.
      With two 4K 60Hz monitors, the fix is to boot with amdgpu.ppfeaturemask=0xffffffff and manually set the shader and memory clocks on the GPU with:

      echo "manual" > /sys/class/drm/card0/device/power_dpm_force_performance_level
      echo "2" > /sys/class/drm/card0/device/pp_dpm_mclk
      echo "5 6 7" > /sys/class/drm/card0/device/pp_dpm_sclk

      Originally posted by debianxfce View Post
      Also Michael uses ubuntu that is more stable and maybe lighter for the GPU than fedora.
      Why? Both of them use Gnome 3.

      Originally posted by debianxfce View Post
      Flickering means that there is not enough power to drive displays.
      No, it means that the GPU clock is set improperly, as explained by clapbr

      Comment


      • #13
        Originally posted by Venemo View Post
        It is something that can be worked around by manually setting the GPU clocks, see the linked bugreport for details.
        I just said that. Btw. it should suffice to enforce maximum VRAM pstate and not touching pstates for the GPU itself.

        Originally posted by Venemo View Post
        And yes it can be fixed: the amdgpu driver should by itself figure out the correct clock.

        I think this isn't a hardware defect, but if it is, the driver should still workaround it by setting the correct clock.
        That's not a real fix. Polaris already has this problem with 75Hz single display, while neither Vega nor other GPU vendors do.

        Comment


        • #14
          That's good to hear, I got kernel shy with Linux 4.19... the amdgpu driver was failing on the ring buffer test while initializing DRM (R9 380/Volcanic Islands Tonga). I've been sticking with 4.18.20 since that and haven't revisited it (though I heard it's been fixed).

          Comment


          • #15
            Originally posted by aufkrawall View Post
            I just said that. Btw. it should suffice to enforce maximum VRAM pstate and not touching pstates for the GPU itself.
            That's not a real fix. Polaris already has this problem with 75Hz single display, while neither Vega nor other GPU vendors do.
            As a user, I don't care what the driver does, just that it shouldn't flicker my displays is all.

            Comment


            • #16
              Originally posted by debianxfce View Post
              vrr_capable=0 means that it is not supported
              Missing the parameter with eDP means that there is no support in the driver or hardware. With RX570:
              Code:
              DisplayPort-0 connected 3840x2160+0+0
              vrr_capable: 1
              HDMI-A-0 disconnected
              vrr_capable: 0
              DVI-D-0 disconnected
              no vrr_capable variable available
              VEGA 8 has support for freesync as people got it working on this exact laptop on windows with little EDID edit which i will do on linux too.
              vrr_capable on HDMI is because there is nothing connected to it.
              Maybe its the initial implementation that doesnt have support for iGPU i guess.
              I hope i will get it working because freesync can help here a looot
              Last edited by Haxk20; 01-22-2019, 06:55 PM. Reason: added info

              Comment


              • #17
                I wish I could agree to the article's statement, but I cannot. It still only takes me minutes to reproduce the crash bug reported in https://bugs.freedesktop.org/show_bug.cgi?id=102322" on the latest git head version, a bug that has haunted amdgpu for about 18 months now.

                And as I already mentioned in another thread, there is a power usage regression in 5.0, again, with weird minimum clocks indicating that dynamic power management is still acting randomly:

                > cd /sys/class/drm/card0/device

                > xrandr --output HDMI-A-0 --mode 3840x2160 --rate 30
                > echo manual >power_dpm_force_performance_level
                > echo 0 >pp_dpm_mclk
                > echo 0 >pp_dpm_sclk
                > grep -H \\* pp_dpm_mclk pp_dpm_sclk
                pp_dpm_mclk:0: 300Mhz *
                pp_dpm_sclk:0: 214Mhz *

                > xrandr --output HDMI-A-0 --mode 3840x2160 --rate 50
                > echo manual >power_dpm_force_performance_level
                > echo 0 >pp_dpm_mclk
                > echo 0 >pp_dpm_sclk
                > grep -H \\* pp_dpm_mclk pp_dpm_sclk
                pp_dpm_mclk:1: 1750Mhz *
                pp_dpm_sclk:1: 481Mhz *

                > xrandr --output HDMI-A-0 --mode 3840x2160 --rate 60
                > echo manual >power_dpm_force_performance_level
                > echo 0 >pp_dpm_mclk
                > echo 0 >pp_dpm_sclk
                > grep -H \\* pp_dpm_mclk pp_dpm_sclk
                pp_dpm_mclk:0: 300Mhz *
                pp_dpm_sclk:6: 1180Mhz *

                Comment


                • #18
                  Originally posted by debianxfce View Post

                  No changes in the idle governor. The CPU frequency governor slows down and is an optional feature of the Linux kernel so remove it. Using the Bios is a better way to control CPU power and fans. Power consumption depends of your other hardware too.
                  Indeed, but what I was talking about is the Power draw for each power profile..
                  In Linux is like crazy, on that mater..

                  On Windows for example, there are better tunned profiles, and the AMD cards consume less power than in Linux, exactly because of the Power profiles..
                  This for me should be one of the next key steps, for AMD,
                  Because it doesn´t mater if your driver is more performant, if it his consuming tons of power, then the "Better Driver", is something difficult to classify..
                  A 2 step way is needed like a loop, on each iteration
                  1. Features
                  2. Optimization

                  Comment


                  • #19
                    Originally posted by debianxfce View Post
                    vrr_capable=0 means that it is not supported
                    Missing the parameter with eDP means that there is no support in the driver or hardware. With RX570:
                    Code:
                    DisplayPort-0 connected 3840x2160+0+0
                    vrr_capable: 1
                    HDMI-A-0 disconnected
                    vrr_capable: 0
                    DVI-D-0 disconnected
                    no vrr_capable variable available
                    issue has been fixed. it was a bug. i know my VEGA 8 in ryzen 5 2500U supports it and rx560x does too so it must be supported on linux too. reported it and its fixed now.

                    Comment


                    • #20
                      Originally posted by Brisse View Post
                      Rebooted. Getting vrr_capable in xrandr, but I though there should be an vrr_enabled entry as well but there's not. Glxinfo is reporting Mesa 19.0-git as expected(
                      The patch series went through quite a few iterations where properties came and went, I think that property was removed in the end and the Xorg.conf setting was added.

                      Comment

                      Working...
                      X