NGnius / PowerTools

Moved to

Home Page:https://git.ngni.us/NG-SD-Plugins/PowerTools

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Overclocking support is extremely sensitive to sleep/wake

CryoByte33 opened this issue · comments

Please confirm

  • I have searched existing issues
  • This issue is not a duplicate of an existing one
  • I will fill this out to the best of my ability

Expected Behaviour

After sleep/wake the Deck should be able to clock up to the settings defined in BIOS/Smokeless UMAF.

Actual Behaviour

Sometimes the APU will be locked to very low clocks, and other times it'll "cap out" at stock speeds.

Steps To Reproduce

  1. Create and use pt_oc.json with a max CPU frequency above 3500 MHz
    
  2. Enable performance overlay to observe frequencies
    
  3. Enable CPU Frequency limits in PowerTools
    
  4. Set the max CPU frequency above 3500 MHz
    
  5. Play a CPU intensive game
    

OR

  1. Create and use pt_oc.json with a max CPU frequency above 3500 MHz
    
  2. Enable performance overlay to observe frequencies
    
  3. Sleep the Steam Deck
    
  4. Wake the Steam Deck
    
  5. Play a CPU intensive game and observe that frequencies no longer climb above default.
    

Anything else?

This is very similar to #80 , but I found additional information.

Uninstalling PT completely fixes this issue, and allows for the Deck to fully clock up as it did before sleep. However, we don't have the ability to disable SMT or tune TDP.

I believe that it may be enough to prevent setting frequencies when non-stock clocks are present in pt_oc.json, but still allowing SMT/Governor/TDP changes, as those are still fully functional. I'm not sure if this is something you're interested in, but it would reduce the "bug surface" of PowerTools since you wouldn't need to deal with amdgpu disallowing higher-than-stock frequencies.

Please let me know if you have any questions!

Version

1.2.0 (Latest stable)

Platform

Steam Deck

OS

SteamOS 3 (Stable)

This is due to a kernel/hardware bug (when kernel stuff is in "manual" mode, clocks get locked to minimum on wake) that I only sort of half-assed a fix for. Its been bothering me for a while so I as actually planning on working on a proper fix tonight.

Interesting, I'd have expected it to have the same behavior when PT was uninstalled in that case. Is that because PT is setting the kernel to manual mode regardless of settings?

Thank you for looking into it!

PT always sets it to manual mode because it was easier that having the CPU and GPU driver parts negotiate whether they can turn it off or not without affecting the other. I've gotten away with it so far because there's no difference between auto mode and manual mode with the clocks min/maxed. But the sysfs interface for clocks doesn't allow me to apply most OC values, so the current solution of re-applying settings upon wakeup fails and leaves the clocks locked to minimums.