Render scale is cheap until something is thin

Everything in a field renderer is per-pixel, so cost is exactly linear in pixel count and halving the render scale is an exact four times saving. It is the single largest performance lever available and it is one slider. The question is only what it costs.

Left: 50 percent render scale, bilinearly upscaled. Right: native. Same scene.

The figure survives almost intact, because its features are large and its edges are soft. That is not luck: it is a deliberately chunky character with no feature narrower than about a fifth of its head, and a figure built that way is close to free to downscale. The thin lines do not survive: they break up, change width along their length, and in places disappear. That is the whole trade, and which side of it you are on depends entirely on the content rather than on the setting.

What survives and what does not

Large soft shapes: essentially free. Halve them and nobody can tell.
Glow, bloom, fog, gradients: free, and often better, since they were being blurred anyway. Rendering glow at quarter resolution is standard practice for exactly this reason.
High-contrast edges: visibly softer. Recoverable with sharpening.
Features near one pixel wide: destroyed. A one pixel line at 50% scale is half a pixel, which the sampler either misses or renders at half intensity depending on where it lands, and the result crawls as the camera moves.
Text: destroyed, and unrecoverable. This is the one that decides the architecture.

The architectural answer

Do not pick one scale for the frame. Split the frame by content:

scene       -> 50 to 70%, upscaled
glow/bloom  -> 25%, it was blurred anyway
UI and text -> always 100%, composited last

Rendering UI at native and the world at half is the standard shape and it is worth building in from the start, because retrofitting a separate UI pass into a pipeline that assumed one resolution is genuinely awkward.

The other half of the same idea: thin things should be authored in screen space, not world space. A line whose width is defined in pixels stays one pixel at any render scale, because it is drawn in the pass that knows what a pixel is. A line whose width is a world-space constant gets whatever the render scale gives it.

What temporal upscaling changes

Unity 6 ships Spatial-Temporal Post-processing, its own temporal upscaler, and the important word is temporal. A spatial upscaler such as FSR1 has only the current frame, so it can sharpen an edge but it cannot invent the sample that was never taken. A temporal one jitters the sample position each frame and accumulates, so over several frames it genuinely has more samples than one frame at native resolution.

That recovers thin features, which is exactly what the demo above cannot do and what the note is otherwise about. The costs are the usual temporal ones and they are worth naming:

It needs motion vectors, which a pure fragment-shader field renderer does not naturally have. Producing them is real work and is the main reason a stylized 2D renderer might not adopt it.
Disocclusion ghosting where a moving object uncovers background the history does not contain.
It needs several frames to converge, so the first frame after a cut is the unresolved one. Cuts are exactly where a viewer is looking hardest.
Jitter must go into the projection, and anything computing positions outside that projection will disagree with it.

On WebGPU specifically

Two things worth knowing before planning around it:

Compute shaders exist, which is the actual headline. WebGL2 has none, so every technique on this site that wants a prefix sum, a reduction or a scatter has been doing it with fragment passes. That constraint lifts.
Browser support is the gate, not the API. Check what fraction of your actual audience can run it before designing a pipeline that requires it, and keep the WebGL2 path working. A renderer that needs compute is a renderer some players cannot start.

Rules of thumb

Cost is exactly linear in pixels, so render scale is the largest and most predictable lever there is.
What it costs is thin features, not overall quality. Judge it on the thinnest thing in the frame.
Split the frame: world at 50 to 70%, glow at 25%, UI and text always at 100%.
Author thin things in screen space so their width does not depend on the render scale.
Temporal upscaling recovers thin detail because it has more samples. Spatial upscaling only sharpens what is already there.
Temporal needs motion vectors, and a fragment-only field renderer does not have them for free.

All 61 notes How to use them Credits

New notes as they land

One email when something new goes up. No newsletter, no schedule, nothing else.

Double opt-in, so watch for a confirmation email. Unsubscribe any time.