Announcement

Collapse
No announcement yet.

AMD Revives Linux Work On DRM CGroup Controller For Limiting GPU Resources

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

  • AMD Revives Linux Work On DRM CGroup Controller For Limiting GPU Resources

    Phoronix: AMD Revives Linux Work On DRM CGroup Controller For Limiting GPU Resources

    At the start of 2018 there was early work on Cgroups support for DRM drivers. That early work was done by Intel developers on using cgroups to allow restricting the GPU priority. AMD is now looking to build a more extensive DRM cgroup controller support for monitoring and restricting GPU resources...

    http://www.phoronix.com/scan.php?pag...Controller-RFC

  • #2
    Interesting, maybe this can be used to reserve some GPU resources for desktop programs (e.g window manager/compositor) to make sure it's still responsive during times of heavy GPU usage.

    Comment


    • #3
      So will this help exposing more GPU info to libsensors?

      Comment


      • #4
        Originally posted by shmerl View Post
        So will this help exposing more GPU info to libsensors?
        No. This is for enforcing resource limits. E.g., if you want to set a hard limit on how much vram or GPU time a particular app can use.

        Comment


        • #5
          Originally posted by agd5f View Post
          No. This is for enforcing resource limits. E.g., if you want to set a hard limit on how much vram or GPU time a particular app can use.
          What about querying the amount of VRAM itself as well as its usage? What is the standard way to do it?

          Comment


          • #6
            Originally posted by shmerl View Post

            What about querying the amount of VRAM itself as well as its usage? What is the standard way to do it?
            Depends on what you are looking for. There are OpenGL extensions for applications. At the driver level there is an ioctl interface that the user mode drivers use to implement support for things like the OpenGL extensions and for driver debugging there are debugfs interfaces.

            Comment


            • #7
              Originally posted by agd5f View Post

              Depends on what you are looking for. There are OpenGL extensions for applications. At the driver level there is an ioctl interface that the user mode drivers use to implement support for things like the OpenGL extensions and for driver debugging there are debugfs interfaces.
              I mean for something like system utilization measuring tools and UIs. For instance I can see RAM / CPU utilization graphs in Ksysguard in KDE. Would be nice to also see VRAM and GPU utilization there as well. Should it use OpenGL for that?
              Last edited by shmerl; 11-21-2018, 11:54 PM.

              Comment


              • #8
                Originally posted by shmerl View Post
                I mean for something like system utilization measuring tools and UIs. For instance I can see RAM / CPU utilization graphs in Ksysguard in KDE. Would be nice to also see VRAM and GPU utilization there as well. Should it use OpenGL for that?
                Absolutely agree, see Windows task manager for example:


                Comment


                • #9
                  This is great for container workloads where you would rather run one container per 20% gpu or similar rather than one container with 5 copies of process running.

                  Comment

                  Working...
                  X