SteamOS FPS, frame pacing, TDP, GPU clock, and CPU tuning

Scope

The goal is not maximum peak FPS. It is the lowest-cost configuration that repeatedly meets a chosen frame-time target without unacceptable visual, thermal, acoustic, or input tradeoffs.

Only use controls exposed by the current device/distribution integration. A raw Gamescope or sysfs capability is not proof that a handheld firmware path is safe or persistent.

Baseline

Reset per-game performance settings, remove launch options, use the recommended runtime, select one repeatable scene, warm the system, and record device, firmware, OS, game build, resolution, preset, refresh rate, FPS cap, TDP, GPU control, battery state, ambient temperature, and test duration.

Change one variable

Frame pacing

Battery or thermals

GPU-bound

Yes

No

Capture a stable baseline

Choose the constraint

Adjust FPS cap or refresh rate

Adjust TDP or power profile

Test resolution or GPU clock

Repeat the same scene

Compare FPS, frame time, power, and temperature

Meets the acceptance threshold?

Record and keep the change

Rollback to the baseline

Use this order and stop when the target is met:

  1. Choose an FPS target that divides or works cleanly with the display mode.
  2. Adjust in-game quality and resolution before forcing clocks.
  3. Change TDP/power limit in one small step.
  4. Test a fixed GPU clock only for a demonstrated CPU/GPU allocation problem.
  5. Change CPU governor or advanced CPU control only with device-specific support and a rollback.

Measurements

MetricMinimum recordInterpretation
FPS
Average and 1% low
Throughput, not smoothness alone
Frame time
Median, 1% tail, and graph
Spikes and pacing stability
Power
Average system power over same scene
Energy cost of the result
Thermal
CPU/GPU temperature and fan/noise context
Sustainability and throttling
Input
Controller path and subjective latency note
Cap/queue tradeoff

Run at least three equal-duration passes and keep the median result. Reject a “win” smaller than run-to-run variance.

Side effects

Lower caps can add latency; mismatched caps can judder; lower TDP can worsen 1% lows; a fixed GPU clock can starve CPU-heavy scenes; aggressive CPU policy can increase power without improving frame times. Shader compilation and background downloads can invalidate a run.

Rollback

Restore the per-game performance profile to defaults/automatic control, remove launch options, restore the original in-game preset and display mode, restart the game, and repeat the baseline scene. Keep the before/after record even when the change is rejected.

Decision examples

ObservationNext testDo not conclude
GPU at limit with stable CPU headroom
Lower GPU-heavy settings or resolution
Raise TDP automatically
Low GPU use and one CPU thread saturated
CPU-heavy setting or frame cap
Fix GPU clock universally
Average good, repeated frame-time spikes
Shader, storage, process, or pacing cause
Average FPS proves smoothness
Battery goal missed but frame target has headroom
Lower cap/quality/TDP one step
One game setting fits all games

Frequently asked questions

Is the highest average FPS always the best setting?
Is the highest average FPS always the best setting?
No. Stable frame times, 1% low behavior, input latency, image quality, thermals, noise, and energy per frame can matter more than a short average-FPS increase.
Should I set a fixed GPU clock and TDP for every game?
Should I set a fixed GPU clock and TDP for every game?
No. A fixed clock or lower power limit can help one bottleneck and hurt another. Test the exact scene and return to automatic/default control when it does not produce a repeatable benefit.

Sources

Version history

  • 2026-07-15: Phase 5 controlled performance-tuning workflow and measurement loop published.