CPU Frequency Limits Stuck After Closing Game #107

Closed
opened 2023-05-29 17:17:33 +01:00 by MarkLockwood · 1 comment
MarkLockwood commented 2023-05-29 17:17:33 +01:00 (Migrated from github.com)

Please confirm

  • I have searched existing issues and found no duplicate
  • I will fill this out to the best of my ability

Extra details

  • I am using a custom pt_oc.json file
  • I am using a custom limits_cache.json file
  • I have submitted a log through the PowerTools UI

Expected Behaviour

Game A (Slay The Spire) has a persistent profile with an aggressive 400/800 MHz limit. These values should not be retained upon closing the game to ensure that it doesn’t impact the performance of Game Mode. Game Mode does not use a persistent profile, and should use the default values that it has when the Deck first boots.

Actual Behaviour

So, in Game A (Slay The Spire, for reference), I’ve set some pretty aggressive limits to reign in power usage to prolong battery life.

These are saved to a PowerTools persistent profile. The easiest value to use in this example is the CPU Frequency. I’ve set a minimum of 400MHz, and a maximum of 800MHz with SMT disabled.

Now, I noted that one of the other reports said that after setting these values, the PowerTools UI will always show the minimum frequency value as 1400MHz. This was chalked up to the Kernal not accepting values less than that, if I remember correctly. According to GameScope, the set value of between 400/800MHz is being respected, and the power draw reflects that this is working. I did rerun this with the Kernel’s minimum value of 1400MHz and noted that my issue will still occur.

So, once I’m finished playing Game A, I’ll close it to return to Game Mode. PowerTools will correctly return to the default non-persistent profile called Main. This profile has no set values, but I can tell it’s being reloaded because SMT was enabled. However, the previous CPU Frequency values have been retained, and the Steam client will cough and splutter until the Deck is rebooted. Going into Desktop Mode and back into Game Mode won’t fix the issue, as the same CPU Frequency values are reloaded upon entering Game Mode.

Steps To Reproduce

  1. Open a game.
  2. Set it to use a persistent profile with a lower than normal CPU Frequency range (tested 400-800MHz, and 1400-1400MHz).
  3. Enable GameScope’s fourth detail level so you can observe the CPU Frequency.
  4. Close the game and note that Game Mode’s CPU Frequency is locked to the upper limit set in the previous game’s profile.
  5. Reboot the Deck and note that the values are now able to clock up and down like normal.

Anything else?

I can get you some screenshots if you’re not able to reproduce the issue. The log file didn’t have any issues noted. I could see that it successfully identified when the game opened and closed, applying the profile as required.

Version

1.3.2

Platform

Steam Deck

OS

SteamOS 3 (Stable)

### Please confirm - [X] I have searched existing issues and found no duplicate - [X] I will fill this out to the best of my ability ### Extra details - [ ] I am using a custom `pt_oc.json` file - [ ] I am using a custom `limits_cache.json` file - [ ] I have submitted a log through the PowerTools UI ### Expected Behaviour Game A (Slay The Spire) has a persistent profile with an aggressive 400/800 MHz limit. These values should not be retained upon closing the game to ensure that it doesn’t impact the performance of Game Mode. Game Mode does not use a persistent profile, and should use the default values that it has when the Deck first boots. ### Actual Behaviour So, in Game A (Slay The Spire, for reference), I’ve set some pretty aggressive limits to reign in power usage to prolong battery life. These are saved to a PowerTools persistent profile. The easiest value to use in this example is the CPU Frequency. I’ve set a minimum of 400MHz, and a maximum of 800MHz with SMT disabled. Now, I noted that one of the other reports said that after setting these values, the PowerTools UI will always show the minimum frequency value as 1400MHz. This was chalked up to the Kernal not accepting values less than that, if I remember correctly. According to GameScope, the set value of between 400/800MHz is being respected, and the power draw reflects that this is working. I did rerun this with the Kernel’s minimum value of 1400MHz and noted that my issue will still occur. So, once I’m finished playing Game A, I’ll close it to return to Game Mode. PowerTools will correctly return to the default non-persistent profile called Main. This profile has no set values, but I can tell it’s being reloaded because SMT was enabled. However, the previous CPU Frequency values have been retained, and the Steam client will cough and splutter until the Deck is rebooted. Going into Desktop Mode and back into Game Mode won’t fix the issue, as the same CPU Frequency values are reloaded upon entering Game Mode. ### Steps To Reproduce 1. Open a game. 2. Set it to use a persistent profile with a lower than normal CPU Frequency range (tested 400-800MHz, and 1400-1400MHz). 3. Enable GameScope’s fourth detail level so you can observe the CPU Frequency. 4. Close the game and note that Game Mode’s CPU Frequency is locked to the upper limit set in the previous game’s profile. 5. Reboot the Deck and note that the values are now able to clock up and down like normal. ### Anything else? I can get you some screenshots if you’re not able to reproduce the issue. The log file didn’t have any issues noted. I could see that it successfully identified when the game opened and closed, applying the profile as required. ### Version 1.3.2 ### Platform Steam Deck ### OS SteamOS 3 (Stable)
NGnius commented 2023-05-29 21:48:37 +01:00 (Migrated from github.com)

Confirmed, will throw it into changes for v1.4.0

Confirmed, will throw it into changes for v1.4.0
NGnius added reference dev 2023-08-25 02:24:06 +01:00
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#107
No description provided.