Announcement

Collapse
No announcement yet.

AMD Delivers OverDrive Overclocking Support For AMDGPU DRM Driver

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

  • #21
    Originally posted by bridgman View Post
    The idea is that DE's would implement standard GUIs that work across all HW vendors, using sysfs controls to interact with the drivers. It never seems to quite get to the top of the DE priority list though. The obvious alternative is vendor-specific GUIs, but that really does seem like throwaway work if we're going to end up with DE-level GUIs.

    I'm wondering if it would make sense to implement a simple command-line utility for now, since as soon as we release a GUI for something the next question is usually "how do I script it ?". On the other hand all the CLU would do is remember the details of how the sysfs interface works...

    Is the real need for an actual GUI (because sliders are cooler than text), persistence of settings across reboots, or the ever-popular "forcing settings that the OSS driver developers all agree should be handled in the app not the driver" ?
    You're never going to make people happy with a GUI. There will always be the request for the right control panel, in the right desktop, using the right toolkit. You'll either split your effort 10 ways or force another corporate styled market app on people (most vendor panels are ugly apps)

    The sysfs is great; a cli would be immensely useful as a target for DE widgets and control panels, if it is a safe wrapper (can you protect the hardware from a zealous widget?)

    Comment


    • #22
      Is this also about fan control?
      When reading gfx card comparisons, I always check the idle noise. Some vendors make their cards too loud.
      I really like to override their fan speed curve.

      Comment


      • #23
        An integrated desktop solution would be better, for now maybe a gnome plugin extension would be nice.

        Comment


        • #24
          (integer) percentage between 0 and 20 to the new pp_sclk_od sysfs entry
          Hmm, what about ability to DOWNCLOCK as well? Say, make it 0 to 120 instead, to scale from lowest freqs to 120% . Somethimes one may want to lower clocks on powerful GPUs to ensure thermals, power consumption and noise stays sane even if running in warm environments, etc. IIRC Catalyst was able to do both overclocking and underclocking and some advanced programs actually used it to e.g. keep GPU themperature in desired range, without spinning up coolers to 100%, where it tends to be noisy and/or kills GPU fan really quickly.

          Comment


          • #25
            Aw c'mon, if we do that then we'll have people asking us to accept negative numbers and make the GPU run backwards

            Seriously, it seems like that should be fairly straightforward but I don't know how big the effort would be.
            Test signature

            Comment


            • #26
              You can already downclock today by limiting the number of DPM states via sysfs.

              Comment


              • #27
                Originally posted by atomsymbol

                On R9 390, sysfs exposes just "low", "auto" and "high" - but "auto" isn't working so effectively it exposes just two options. I would prefer sysfs to expose performance states directly corresponding to the performance states actually supported by the hardware.

                The "high" profile is an overkill from performance viewpoint, from power consumption viewpoint and from fan noise viewpoint.

                It should be possible to set the engine clock independently from the memory clock.

                I believe that directly exposing the actual hardware performance states through sysfs in radeon.ko and amdgpu.ko would satisfy most advanced Linux users who aren't content with excessive power consumption of their AMD GPUs.

                In other words: Just enable us to set the engine/shader clock and the memory clock directly through sysfs. The values can come from a sysfs file listing the available clocks.
                That is already supported on amdgpu.

                Comment


                • #28
                  Originally posted by atomsymbol
                  ...
                  I would recommend to first check the content of "radeon_pm_info" when the GPU is idle:

                  Code:
                  $ cat /sys/kernel/debug/dri/0/radeon_pm_info
                  uvd disabled
                  vce disabled
                  power level avg sclk: 30000 mclk: 15000
                  ...
                  Thanks.
                  But, I'm just interested if setting the fan speed works with the current AMD DRM drivers.
                  A while back I tried AMDOverdriveCtrl which worked fine with Catalyst and my HD7950. But, for the coming Polaris - I want to know if I have to buy a card that has low idle noise, or if I can manually set it.

                  Comment


                  • #29
                    Originally posted by FireBurn View Post
                    Didn't work on my Tonga at first, there's a new patch that fixes it now, I got a stable overclock of 15% when I tried 20% the game froze up
                    15% is better than nothing.

                    Comment


                    • #30
                      Originally posted by agd5f View Post
                      That is already supported on amdgpu.
                      Originally posted by atomsymbol
                      Please be more specific.
                      [...]
                      What is the absolute path of those sysfs files through which I can set the engine/shader clock and memory clock?
                      Yes, is there any documentation for that?
                      Can only the max clock be altered or all entries from the dpm/clock table?
                      Last edited by juno; 17 May 2016, 07:37 AM.

                      Comment

                      Working...
                      X