Variable Rate Shading Explained: How VRS Changes GPU Shading Work

Variable Rate Shading, or VRS, lets a renderer vary how often pixel shading is evaluated across rendered work. In ordinary 1x1 shading, a pixel-shader invocation corresponds to one fine pixel. With a coarse rate such as 2x2, one shader invocation can supply a result across a 2-by-2 group of fine pixels. That can reduce pixel-shader work in regions where full-rate shading would provide little visible benefit.

This is not the same operation as lowering the resolution of the entire frame. Microsoft specifies that depth, stencil and coverage remain evaluated at full sample resolution when coarse pixel shading is used in Direct3D 12. NVIDIA likewise describes VRS as decoupling shading rate from visibility rate. Geometry can therefore retain fine rasterized coverage while selected regions use fewer pixel-shader evaluations.

The useful saving comes from work that is actually performed by pixel shading. A 2x2 coarse rate can reuse one shading result across four fine pixels instead of invoking the pixel shader separately for each one. Direct3D 12 requires 1x1, 1x2, 2x1 and 2x2 support for VRS-capable tiers, while larger coarse rates such as 2x4, 4x2 and 4x4 depend on an additional device capability.

That does not mean a 2x2 rate makes the whole frame four times faster. Vertex processing, geometry work, rasterization, depth and stencil, memory traffic, compute passes, ray tracing, CPU submission and other costs do not disappear just because fewer pixel-shader invocations are requested. The performance effect therefore depends on how much frame time the affected pixel shading consumed in the first place.

Microsoft divides Direct3D 12 VRS into two feature tiers. Tier 1 exposes per-draw shading-rate control, so the chosen rate applies uniformly to that draw. Tier 2 retains per-draw control and adds finer sources: a per-primitive shading-rate semantic and a screen-space shading-rate image. Applications can combine those sources to decide the final rate.

The screen-space image is lower resolution than the render target and describes rates over tiles rather than individual output pixels. Microsoft documents supported Tier 2 tile sizes as device-queryable values. This lets an engine keep sensitive areas at full rate while using coarser shading elsewhere, but the engine still has to decide which regions tolerate that reduction.

A screen-space shading-rate image can encode different rates across the frame. Microsoft gives examples such as regions associated with motion blur, depth-of-field blur, transparent objects or HUD elements. NVIDIA describes a similar spatial approach in which detailed subjects can stay at full rate while less sensitive areas use coarse shading.

The important part is selection. VRS does not know on its own which pixels are visually important. A game or engine must build a policy from scene information, motion, content classification, gaze data or another signal. A conservative policy may save less work but preserve more detail; an aggressive policy can reduce more shading work while making artifacts easier to notice.

Coarse shading deliberately evaluates a shader less frequently across fine pixels, so nearby pixels can share a result that would otherwise have been calculated separately. That can be hard to notice in suitable low-detail, blurred, rapidly moving or peripheral regions, but it can damage fine material detail, small features or other high-frequency content when applied poorly.

There are also technical consequences beyond obvious blockiness. Microsoft notes that screen-space derivatives change under coarse shading, which can affect calculations such as mip selection. Engines therefore need to account for how their shaders behave under coarse rates rather than treating VRS as a universal switch that can be enabled without rendering-side decisions.

A GPU exposing a VRS feature tier means the API can report that capability to software. It does not cause games to adopt a particular shading policy automatically. The renderer has to use the relevant API mechanisms, choose rates and decide where those rates apply. Different games can therefore make different use of the same hardware capability, or not use it at all.

Vendor-specific VRS paths also exist outside the Direct3D 12 tier model. NVIDIA introduced hardware VRS with its Turing architecture and documents VRS interfaces across multiple graphics APIs. That history is useful context, but a PC gamer should evaluate support at the game, API and GPU combination actually being used rather than assuming that the acronym alone describes one identical implementation everywhere.

VRS is most directly useful when pixel shading is a meaningful bottleneck. NVIDIA notes that potential gains depend on factors including pixel-shader complexity and scene content. If a game is limited mainly by the CPU, geometry processing, memory behavior, compute work or another stage that VRS does not reduce, lowering the shading rate may move little or no overall frame time.

Resolution and rendering workload matter for the same reason. More fine pixels can create more potential pixel-shading work, but the actual benefit still depends on the shaders, the regions assigned coarse rates and the rest of the frame. A benchmark result from one game, resolution or quality preset should not be converted into a promised percentage for another workload.

The clean mental model is that VRS gives a renderer another place to spend image quality selectively. Full-rate shading can remain where detail matters, while coarser rates reduce pixel-shader evaluations where the engine expects the difference to be less visible. Tier 2 makes that decision substantially more spatially flexible than Tier 1.

For players, the presence of VRS support is therefore only the first layer. The GPU must expose the needed capability, the game must implement and enable an appropriate path, its shading-rate policy must suit the scene, and pixel shading must account for enough frame time for the saved work to matter. Image quality and measured performance remain implementation- and workload-dependent.