Overclocking support is extremely sensitive to sleep/wake #87

Closed
opened 2023-03-27 20:55:41 +01:00 by CryoByte33 · 3 comments
CryoByte33 commented 2023-03-27 20:55:41 +01:00 (Migrated from github.com)

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)

### Please confirm - [X] I have searched existing issues - [X] This issue is not a duplicate of an existing one - [X] 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)
NGnius commented 2023-03-27 22:00:12 +01:00 (Migrated from github.com)

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.

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.
CryoByte33 commented 2023-03-27 22:01:46 +01:00 (Migrated from github.com)

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!

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!
NGnius commented 2023-03-27 22:32:46 +01:00 (Migrated from github.com)

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.

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.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: NG-SD-Plugins/PowerTools#87
No description provided.