Announcement

Collapse
No announcement yet.

AMD Sends In Their Initial AMDGPU Driver Updates For Linux 5.2

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

  • AMD Sends In Their Initial AMDGPU Driver Updates For Linux 5.2

    Phoronix: AMD Sends In Their Initial AMDGPU Driver Updates For Linux 5.2

    Joining the DRM-Next party with the Intel driver feature work is now the initial batch of the AMDGPU Radeon driver changes for Linux 5.2...

    http://www.phoronix.com/scan.php?pag...tial-Linux-5.2

  • #2
    The "DRM-next party" as of today sees still the shader and memory clocks being set to seemingly arbitrary values depending on the refresh rate (without any GPU load): second-highest sclk but lowest mclk at 4k 60Hz, lowest sclk but highest mclk at 4k 50Hz and so on.
    Unlike a month back, now X doesn't immediately crash when started with amdgpu.vm_update_mode=3, but the instabilities aren't gone, also with vm_update_mode=0. So no light at the end of the instability tunnel. Still hoping that Intel gets those Xe units out, to finally have some alternative.

    Comment


    • #3
      Originally posted by dwagner View Post
      The "DRM-next party" as of today sees still the shader and memory clocks being set to seemingly arbitrary values depending on the refresh rate (without any GPU load): second-highest sclk but lowest mclk at 4k 60Hz, lowest sclk but highest mclk at 4k 50Hz and so on.
      Unlike a month back, now X doesn't immediately crash when started with amdgpu.vm_update_mode=3, but the instabilities aren't gone, also with vm_update_mode=0. So no light at the end of the instability tunnel. Still hoping that Intel gets those Xe units out, to finally have some alternative.
      I've given AMD a lot of slack but honestly I could see myself going Intel also. I'd much rather that they went after stability than the rush to new features.

      Comment


      • #4
        Originally posted by dwagner View Post
        The "DRM-next party" as of today sees still the shader and memory clocks being set to seemingly arbitrary values depending on the refresh rate (without any GPU load): second-highest sclk but lowest mclk at 4k 60Hz, lowest sclk but highest mclk at 4k 50Hz and so on.
        My card uses lowest mclk when a single monitor is plugged in, but switches to a higher mclk (for no rational reason) when two monitors are plugged in which adds about 40 watts to power consumption at the outlet and prevents GPU fans from stopping. Watching a video can lead to unnecessary increases in power consumption as well. I prefer to set mclk and sclk ranges manually, enabling higher clocks only when they are needed.

        Comment


        • #5
          Originally posted by ihatemichael
          Can someone explain why amdgpu is so buggy with glamor? I migrated from a intel machine and I'm regretting it.
          It is your desktop and OS that is buggy. No unfixed problems with Debian testing Xfce, the AMD wip kernel and Mesa git since 2015 when I switched from the nvidia GPU.

          Comment


          • #6
            Originally posted by dwagner View Post
            The "DRM-next party" as of today sees still the shader and memory clocks being set to seemingly arbitrary values depending on the refresh rate (without any GPU load): second-highest sclk but lowest mclk at 4k 60Hz, lowest sclk but highest mclk at 4k 50Hz and so on.
            Put amdgpu.ppfeaturemask=0xfffd7fff to the kernel command line to make the powerplay work at 4k60Hz with RX570 and maybe others.

            Originally posted by dwagner View Post
            Unlike a month back, now X doesn't immediately crash when started with amdgpu.vm_update_mode=3, but the instabilities aren't gone, also with vm_update_mode=0. So no light at the end of the instability tunnel. Still hoping that Intel gets those Xe units out, to finally have some alternative.

            What you do with amdgpu.vm_update_mode, "The default is -1 (Only in large BAR(LB) systems Compute VM tables will be updated by CPU, otherwise 0, never)."

            The intel dgpu will be buggy as hell, nobody has resources to test everything and it is the first fast intel dgpu.

            Comment


            • #7
              Originally posted by ihatemichael

              Huh? I'm on Arch Linux and I have the latest packages of the kernel, mesa and LLVM, I even tried mesa-git and AMD wip kernel. I still get frequent corruption/quirks with glamor, I'm not sure how you can claim that.
              Your desktop is buggy gnome3 or kde propably. Arch Linux is unstable and your kernel and mesa configuration can be wrong. Test with my distribution to see it. https://www.youtube.com/watch?v=fKJ-IatUfis
              Last edited by debianxfce; 03-29-2019, 01:02 AM.

              Comment


              • #8
                Originally posted by ihatemichael

                Huh? I'm on Arch Linux and I have the latest packages of the kernel, mesa and LLVM, I even tried mesa-git and AMD wip kernel. I still get frequent corruption/quirks with glamor, I'm not sure how you can claim that.
                I've seen the same on my new Ryzen / Vega 10 laptop. New gtk3 windows briefly render a window full of garbage before behaving properly. I'm also seeing rendering glitches in gtktextview and gtksourceview widgets, which is fixed when I drag-select the content. I'm also on a recent kernel ( 5.0.1 ) and mesa ( git, various builds, updated weekly ). Hopefully will get fixed soon. Not sure if it's been reported, but it's hard to see how they wouldn't be aware of it ...

                Comment


                • #9
                  Is the corruption on under X or wayland?
                  Cant see any corruption in X using modestteting DDX.

                  Comment


                  • #10
                    Originally posted by atomsymbol View Post

                    My card uses lowest mclk when a single monitor is plugged in, but switches to a higher mclk (for no rational reason) when two monitors are plugged in which adds about 40 watts to power consumption at the outlet and prevents GPU fans from stopping. Watching a video can lead to unnecessary increases in power consumption as well. I prefer to set mclk and sclk ranges manually, enabling higher clocks only when they are needed.
                    The issue is that switching power modes needs some time and is normally done during vblank, when no data has to be send to the screen. With higher frequency the vblank time is shorter (My 290 stays in full memory clocks when I set over 120 Hz on my monitor). And with multiple monitors I guess the vblank is not synced?! In that case the monitor could start to flicker when the power switching is still ongoing and no data send to the monitor in time. So the drivers go in permanent higher clock speed mode to prevent this flickering.

                    Comment

                    Working...
                    X