Steam Frame VR Settings Explained

VR performance settings describe several different clocks and image stages. Display refresh rate is not automatically the game's frame rate, panel resolution is not automatically render resolution, and foveated streaming is not the same feature as foveated rendering inside a game.

Valve's developer documentation already defines the main controls, but Frame is still prelaunch. The names and defaults below are current documented behavior, not proof that the retail menus will remain unchanged.

The documented per-application controls

Valve lets a developer suggest four Steam Frame VR preferences: render resolution, refresh rate, frame throttling, and motion smoothing. Users can override those suggestions globally or for an individual application.

Valve documents a default render resolution of 1728 × 1728 per eye, a default refresh rate of 72 Hz, no frame throttling by default, and the user's global motion-smoothing preference. A developer suggestion is a starting point, not a lock.

Render resolution

Valve's product page lists two 2160 × 2160 LCD panels, one per eye. A game does not have to render at the physical panel resolution.

The documented 1728 × 1728 default is the size of each rendered eye image before the runtime transforms and presents it. At that default, the game produces almost six million rendered pixels across both eyes for every complete frame. Raising the value can improve image detail while increasing GPU work; lowering it can recover performance at the cost of clarity.

Valve's standalone compatibility criteria treat a VR render size below 1440 × 1440 per eye as unsupported. That is a review floor, not a claim that every game should use the same ideal value.

Refresh rate

Refresh rate is how often the display updates. Valve lists support from 72 to 144 Hz, while the documented per-app default is 72 Hz.

A higher refresh rate shortens the time available to produce each display update. It can make motion look smoother when the whole pipeline keeps up, but selecting a higher number does not make a game render that many original frames.

This is why a useful report records refresh rate separately from the observed result. “90 Hz” describes a display mode; it does not by itself prove 90 fully rendered game frames each second.

Frame throttling

Frame throttling deliberately runs the application at a fraction of the display refresh rate. Valve's own example uses a 90 Hz display with half-rate throttling, producing a 45 FPS application cadence while the display continues at 90 Hz.

That can trade native frames for consistency and give motion smoothing a predictable input cadence. Whether it looks acceptable depends on the game, the quality of reprojection, and the user. It should not be described as equivalent to native full-rate rendering.

Motion smoothing and reprojection

When the application does not provide a new frame for every display interval, the runtime can adjust or synthesize an image using recent frame data and updated head movement. Steam Frame's documented motion-smoothing preference can be off, on, or always on.

Valve's performance-overlay documentation encourages developers to provide depth and motion-vector information so reprojection has better inputs. The same page explains that Valve assesses timing over a rolling 32-frame average and filters isolated excursions rather than treating one late frame as a complete failure.

Reprojection is therefore not automatically a visible defect. The useful question is whether it creates noticeable judder, warping, ghosting, or instability during normal play.

Foveated rendering

Foveated rendering reduces work away from the user's gaze point. Valve lists OpenXR foveation and eye-gaze extensions for Steam Frame, including eye-tracked foveation support for applications that implement the relevant path.

That last condition matters. Eye tracking in the headset does not guarantee that every game uses eye-tracked foveated rendering. The game, engine, and runtime path all need compatible support.

Foveated streaming is a separate feature

In streamed play, Frame can use gaze information to allocate more encoded detail near the point of focus and less in peripheral regions. That optimizes the video stream. It does not necessarily reduce the host game's rendering work.

The two techniques can coexist:

• Game-side foveated rendering changes what the GPU renders.
• Foveated streaming changes how the rendered image is encoded and transported.

Do not use one term as evidence that the other was active.

What “VR observed result” means on this site

Our optional Steam Frame Run Scores detail records the visible outcome separately from the settings. The current choices are:

• Smooth and stable: no meaningful visible instability during normal play.
• Minor visible judder or artifacts: occasional issues that did not regularly interrupt play.
• Frequent visible judder or artifacts: issues appeared repeatedly during normal play.
• Severely unstable: persistent instability made the experience difficult to use.
• Unplayable: gameplay was reached, but performance made continuing impractical.
• Not sure: the contributor could not classify the result confidently.

These are observations, not inferred frame-rate targets. A load-screen hitch should not be treated as the whole session, and a smooth result does not prove motion smoothing was off.

A controlled tuning order

Change one setting at a time and retest the same demanding scene. Start from the game's or system's suggested values. If frame timing is poor, compare a lower render resolution before changing multiple cadence settings at once. Then test refresh rate, throttling, and motion smoothing as separate decisions.

Record the final combination that was actually used. Without that context, another player cannot tell whether a smooth result came from native full-rate rendering, a lower resolution, throttling, or reprojection.

What still needs retail verification

• Final menu names, allowed values, defaults, and override precedence.
• Which launch titles implement game-side eye-tracked foveation.
• Retail behavior of foveated streaming across gaze loss and eye-tracking calibration.
• Motion-smoothing quality and artifacts across common refresh-rate combinations.
• Whether firmware updates change Valve's compatibility thresholds or suggested defaults.