AMD Linux P-State Per-Core Boost Proposal Targets Steam Deck Frame-Time Lows

This is an upstream proposal, not a released Steam Deck performance setting. Vernet’s presentation describes requested architectural changes and says supporting follow-up data had not yet been posted.

Why a busy gaming thread can lose momentum​

In his July 28 RFC, Vernet described a problem with AMD P-State’s active mode: short sleeps can reduce the hardware’s performance-demand estimate. A game thread briefly waiting for synchronization or GPU work may consequently resume at a lower operating point, hurting frame-time consistency despite being busy whenever work is available. EPP—Energy Performance Preference—biases the hardware’s choice rather than commanding a fixed frequency.

The practical distinction is between delivering more frames overall and delivering the difficult frames more promptly. An average-FPS headline can conceal the very interruptions players notice.

What the original patches actually do​

The July implementation proposed an opt-in epp_boost mechanism:

• Sample each core’s busy residency no more frequently than every 10 milliseconds.
• Set EPP to performance when a sample reaches 50% busy time.
• Restore the previous policy request after 300 milliseconds without another qualifying sample.

It leaves minimum, maximum and desired performance fields unchanged. The implementation was restricted to active mode on systems supporting the required CPPC model-specific-register interface—not every AMD machine running Linux.

Promising lows, not a universal FPS boost​

Vernet’s July Steam Deck LCD tests used Civilization VI’s graphics benchmark, six interleaved A/B iterations per configuration and Welch’s t-test. He reported 31.8% higher 1%-low FPS and 4.1% better p99 frame time, while average FPS and p999 frame time remained unchanged. Those results support a targeted improvement, not a blanket claim of 31% faster gaming.

The October slides report Steam Deck OLED results of 29%–38% higher Civilization VI 1%-low FPS, but also roughly 1 W more package power and 10% lower FPS per watt. A GPU-bound vkmark test showed no statistically significant FPS improvement. Battery operation and steady idle were not measured.

Smoothness and efficiency are different scoreboards. These measurements cannot establish longer battery life.

The bigger change: move policy into a governor​

According to Vernet’s slides, maintainers requested a governor-level mechanism, no module parameter and no overriding of user-selected EPP. The proposed division is straightforward: a dynamic governor decides when to boost, the driver writes the EPP hint, and firmware chooses the clock.

The presentation also identifies a hardware-specific complication: on Van Gogh, reliable boosting required writing the hint for both SMT siblings, whereas the original RFC wrote one thread’s register.

Wine thread hints are another discussion avenue. The slides suggest using UCLAMP_MIN to convey important-thread needs and potentially translate that into EPP; they do not announce shipping Wine or Proton integration.

What PC gamers should take away​

The useful development is a shift toward workload-aware power policy, not a ready-made tuning recipe. The evidence covers experimental Linux changes; it establishes neither an available SteamOS toggle nor a Windows performance improvement.

The right question is therefore not simply “How much faster?” It is whether the eventual design can improve troublesome frames while respecting user preferences and the handheld’s power budget. That is a more demanding—and more useful—goal than making every core sprint.