Announcement

Collapse
No announcement yet.

Radeon Linux Driver Adds Option To Limit Number Of Enabled CUs

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

  • #11
    Can this be used to save battery life?

    Comment


    • #12
      Originally posted by sarmad View Post
      Can this be used to save battery life?
      It depends on whether or not the CUs are power-gated with this. If this command just prevents the CUs from getting fed instructions, but they're still powered up and "idling", then I doubt it would save power. It might actually make power consumption worse if the remaining CUs have to run at a higher clock speed to complete the workload.

      Comment


      • #13
        Originally posted by sarmad View Post
        Can this be used to save battery life?
        I suspect that is why AMD developed this feature. During their presentation at CES yesterday, they announced a feature for their new laptop GPUs that automatically disables CUs. They say their software detects how many CUs are needed for the task at hand, and only enable that many. They claim this saves power and allows the CPU to boost higher.

        Comment


        • #14
          Originally posted by foobaz View Post

          I suspect that is why AMD developed this feature. During their presentation at CES yesterday, they announced a feature for their new laptop GPUs that automatically disables CUs. They say their software detects how many CUs are needed for the task at hand, and only enable that many. They claim this saves power and allows the CPU to boost higher.
          Love it. I hope this can eventually be a replacement for hybrid graphics in gaming laptops.

          Comment


          • #15
            Originally posted by sarmad View Post
            Can this be used to save battery life?
            in general it's better to lower voltage and frequency

            Comment


            • #16
              Originally posted by kiffmet View Post
              Rabiator there is a sysfs interface for OC and UV, once you've set amdgpu.ppfeaturemask=0xfffd7fff
              I configured my system to automatically execute a bash script that loads my OC/UV when logging in. You may also use CoreCtrl, radeon-profile or TuxClocker (all three of them are Qt based), WattmanGTK or rocm_smi (CLI, comes directly from AMD).
              Refer to the ArchLinux Wiki for further information on how to set it up and which files to edit.
              That d7 thing is a mistake that somehow got Incorporated in a bunch of guides. Default + the overdrive flag gives you 0xffffffff.

              Edit: retracted.
              Last edited by yump; 13 January 2022, 12:38 AM.

              Comment


              • #17
                yump It's fine. 0xfffd7fff means all features active, except GFXOFF and stutter mode. The corresponding bits are defined here.

                Default is 0xfff7bfff - activating only overdrive on top of that yields 0xfff7ffff.
                RDNA2 uses DCS (Duty Cycle Scaling) by default since Kernel 5.13, other cards don't (or can't). To force enable, use 0xffffffff, above does force disable it.

                Brave overclockers can
                • Activate overdrive and disable clock stretching: 0xfff7fbff
                • Use overdrive without ACG: 0xfff6bfff
                • Disable ACG and clock stretching while leaving overdrive enabled: 0xfff6fbff
                …to modify the card's behaviour.

                There is also /sys/class/drm/card0/device/pp_features to play around with if you want to try out stuff during runtime. It exposes options that are hardware specific, some of which cannot be set through the ppfeaturemask module parameter.
                Last edited by kiffmet; 09 January 2022, 10:41 PM.

                Comment


                • #18
                  Originally posted by kiffmet View Post
                  yump It's fine. 0xfffd7fff means all features active, except GFXOFF and stutter mode. The corresponding bits are defined here.

                  Default is 0xfff7bfff - activating only overdrive on top of that yields 0xfff7ffff.
                  RDNA2 uses DCS (Duty Cycle Scaling) by default since Kernel 5.13, other cards don't (or can't). To force enable, use 0xffffffff, above does force disable it.

                  Brave overclockers can
                  • Activate overdrive and disable clock stretching: 0xfff7fbff
                  • Use overdrive without ACG: 0xfff6bfff
                  • Disable ACG and clock stretching while leaving overdrive enabled: 0xfff6fbff
                  …to modify the card's behaviour.

                  There is also /sys/class/drm/card0/device/pp_features to play around with if you want to try out stuff during runtime. It exposes options that are hardware specific, some of which cannot be set through the ppfeaturemask module parameter.
                  You're right, I was mistaken. Sorry it took so long to respond -- I waited until the next reboot to check the default in /sys/module/amdgpu/parameters/. I'm pretty sure that's where I got the idea that the default was all-set except overdrive, a few kernels ago. Probably back before DCS was added. I have snoozed and losed.

                  I know what clock stretching is, and I can kind of guess about ACG (adapting to temperature or chip aging maybe?) but can you tell me which chips have those features?

                  Comment


                  • #19
                    yump No worries. These features are relevant for Vega and onwards. GFXOFF and stutter mode can be interesting for APU users. ACG changes how the chip adapts its clockspeeds to the current workload. In Vega 56/64 it kicks in at P5, P6 and P7 and is involved in clockspeeds varying between different games/workloads, even when other factors like powerlimit and temperature are excluded.

                    It might save energy, but some chips react a bit funky towards it, as in the clock fluctuates between 1500 and 1700Mhz or even 1400 and 1800Mhz to average 1600Mhz (i.e. when 1630Mhz is set). When pushing the chip to its limits, this behavior might cause it to briefly ramp clocks into unstable territory, limiting max. sustainable avg. clockspeed.

                    Disabling ACG doesn't fully get rid of this behavior, but it certainly alters it. I suspect that there is something very wrong with the SMU, as Polaris and earlier didn't do this due not changing/interpreting the set clocks and voltages in any way. I think, originally a boost algo similar to the VII or RDNA was planned, since there are some entries in the pptable hinting towards it. Due to the troubled development it just resulted in another quirk lol.

                    Comment

                    Working...
                    X