Announcement

Collapse
No announcement yet.

AMDGPU's New SMU Code Gets More Additions Ahead Of Navi

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

  • AMDGPU's New SMU Code Gets More Additions Ahead Of Navi

    Phoronix: AMDGPU's New SMU Code Gets More Additions Ahead Of Navi

    Back in January was the surprise of AMD developers publishing a lot of new code to support a new SMU block of "future GPUs". That SMU code continues to be refined and another patch series sent out today fills in more functionality, exporting more system management unit information and controls to Linux user-space...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    I'm a little worried this will be a new fun source of strange bugs, but perhaps it'll work great from start. :-)

    Old cards had their fans etc managed by software, and for a long time that worked a lot worse in Linux than on Windows. Then stuff moved to the GPU firmware and then the defaults just worked out of the box on Linux to afaict. Now we're back to the driver implementing it correctly again... ?

    Comment


    • #3
      The AMDGPU driver has already supported these pieces of functionality for existing Radeon GPUs with its other PowerPlay code paths.
      Not really, theses functionalities aren't supported for Southern Islands GPUs.

      Comment


      • #4
        Debian can't get out of 4.20-rc1 never mind what you're referencing.

        Comment


        • #5
          Originally posted by ernstp View Post
          Old cards had their fans etc managed by software, and for a long time that worked a lot worse in Linux than on Windows. Then stuff moved to the GPU firmware and then the defaults just worked out of the box on Linux to afaict. Now we're back to the driver implementing it correctly again ?
          This is not about moving functionality from firmware back to the driver... it's about replacing the older "powerplay" code that lived alongside amdgpu in the /drivers/gpu/drm/amd folder with new code living in the amdgpu folder and organized along the same lines as the amdgpu code for all the other HW blocks.

          I believe the thinking was "as long as we have to add a bunch of new code let's fix up the framework while we're at it".

          For anyone not familiar with amdgpu internals, most of the code is organized as follows:

          - common code (amdgpu_drv.c, amdgpu_device.c etc...)
          - per-GPU-family code (si.c, cik.c, vi.c, soc15.c etc...)
          - per-IP-block code (amdgpu_gfx, amdgpu_ih.c, amdgpu_uvd.c etc...)
          - per-IP-block-version code (gfx_v6_0.c, gfx_v7_0.c, gfx_v8_0.c, gfx_v9_0.c etc...)

          The powerplay code (which manages the SMU block in the same way that gfx code manages the graphics core) is currently an exception to this, in terms of both location (it lives outside the amdgpu folder) and organization. The new "smu" code is more consistent with the rest of the driver.
          Last edited by bridgman; 25 February 2019, 08:08 PM.
          Test signature

          Comment

          Working...
          X