Shader Compilation Stutter: Test a Cold Run Against a Warm One

A compilation hitch appears as one unusually long frame when rendering asks for a GPU program or pipeline that is still being prepared. Average frame rate can look healthy because one badly delayed frame disappears inside a long average.

A hitch on the first appearance of an effect, material, or scene, followed by a cleaner repeat, makes compilation or cache warm-up a credible hypothesis. Asset streaming, object creation, simulation, and other traversal work can produce the same pattern, so repetition supplies a clue while engine or driver instrumentation identifies the cause.

The evidence here comes from Epic Games, Microsoft, and Khronos documentation. No particular game, driver, GPU, or cache was tested. The practical method is a controlled comparison of a cold pass, an immediate repeat, and a pass after restarting the game.

The missed frame is the symptom

A game can average 60 frames per second while delivering most frames close to schedule and one frame far too late. The player feels that late frame as a hitch. Average FPS records work completed across an interval. A frame-time graph shows the spacing between individual deliveries.

That makes shader compilation a frame-pacing problem at the point of experience. The mechanism behind the long frame is specialized rendering work, but the visible result is an uneven interval.

Keep three measurements separate:

Signal	What it describes	Limit
Average FPS	Throughput across many frames	Whether one frame arrived much later than its neighbors
Frame-time trace	The duration and spacing of individual frames	Which subsystem caused a spike without further instrumentation
Repeat pattern	Whether the hitch changes on a second encounter or run	That compilation was definitely the cause

A one-second counter can flatten a 100-millisecond interruption into an acceptable-looking average. A graph exposes the spike, while a trace or developer instrumentation can name the work inside it.

Build a cold, warm, and restart record

A player-level check begins with observation before configuration. Here, cold labels the first observed pass under recorded startup conditions. Existing caches stay intact, so only instrumentation can reveal their actual state. Use a short route that introduces a few distinct effects or areas and can be repeated without changing save state.

Pass	Conditions	What to record
Cold	First observed visit after normal startup, with existing caches untouched	Exact hitch locations and frame-time spikes
Warm	Immediate repeat in the same session	Which spikes weaken, disappear, or recur
Restart	Same route after closing and reopening the game	Whether improvement survives the loss of session-only state

Record the game version, graphics API selected in the supported menu, driver version, graphics preset, resolution, and route. Let any official shader-processing or pipeline-preparation step finish. During each pass, note where the hitch occurs and keep the route and settings fixed.

Once the three passes establish a baseline, change one supported variable at a time. A different API or preset may be informative when the game exposes that choice normally. Changing the API, driver, settings, cache contents, and route together obscures which variable produced the result.

The record should contain the cold pass, warm pass, restart pass, exact locations, frame-time evidence, and the conditions held constant. The report stays within player-observable evidence; the work inside each frame still requires instrumentation.

A shader must become work the installed GPU understands

Shaders are small programs used during rendering. They transform vertices, calculate pixels, process lighting, run compute work, and support many other stages. A game can ship shader code in an intermediate form, but the final instructions depend on the GPU and driver that will execute them.

Epic’s engineering explanation notes that GPU binaries are specific to the vendor architecture that executes them. The driver therefore has work to do on the player’s machine. Modern rendering also combines shaders with fixed choices such as blend mode, depth behavior, rasterization, and target formats.

Direct3D 12 groups much of that configuration into a pipeline state object, usually shortened to PSO. Microsoft’s documentation describes the PSO as an immutable package that connects the active shaders with other graphics-pipeline state. Vulkan uses its own pipeline objects, but the scheduling problem is comparable: creating a required pipeline can be expensive if the work happens when a frame already needs it.

“Shader compilation stutter” is useful player shorthand. The event may involve a full pipeline, including shaders and fixed graphics state, before the draw can proceed.

Why the first encounter can be the roughest

When a new effect enters the camera, the game requests the pipeline needed to draw it. An already prepared pipeline lets rendering continue. A missing one may force the engine or driver to create it during the current frame.

Epic describes first-use compilation taking tens of milliseconds or more in some cases. A frame budget is much smaller than that at common refresh targets: about 16.7 milliseconds at 60 frames per second and 8.3 milliseconds at 120. One late pipeline can therefore consume several intended frame intervals.

The player sees a pause at the moment the effect first appears. On the next visit, some of the work may already exist in memory or on disk, so the same draw is cheaper. This produces the recognizable cold-versus-warm pattern:

1. a pipeline is requested for the first time;
2. required preparation finishes too late for the current frame;
3. the completed result enters a cache or remains available;
4. a later request reuses more of that work.

Khronos demonstrates the same principle in its Vulkan pipeline-cache sample. Saving pipeline data between runs can avoid repeating costly creation work. The sample also warns against creating a pipeline at draw time without a useful cache because the resulting work can increase frame time sharply.

There is more than one cache

“The shader cache” sounds like a single folder, but the reusable work may exist at several layers.

Layer	What it can hold	Why it may miss
Game or engine records	Descriptions of pipelines known to be needed	Coverage may be incomplete, late, or changed by new content and settings
Precache work during loading	Pipelines requested before the relevant draw	Loading may end before all work finishes, or the needed combination may not have been predicted
Driver cache	GPU-specific compiled results stored for reuse	A driver change, hardware difference, invalidation, or manual deletion can make the run cold again
Live memory	Pipelines already created for the current session	A restart removes session-only state

Unreal Engine’s PSO-cache documentation describes collecting states that an application actually draws, then including their descriptions so the engine can create them earlier in a later build or run. Its engineering article also describes the driver saving compiled PSOs to disk.

These layers explain two observations that otherwise look contradictory. A game may display a compilation or preparation screen and still hitch later because the predicted set was incomplete or unfinished. It may also hitch again after a graphics-driver update because cached results tied to the previous driver are no longer present.

Early preparation shifts the cost into loading time, background CPU use, storage, or memory. An engine has to choose where that cost belongs and how much state to prepare.

Read the repeat pattern as a clue

A repeatable route can reveal the shape of a problem even when the player lacks developer tools. Compare the observed pattern with several plausible causes:

Observation	More consistent with	Important limitation
A hitch appears the first time a specific effect or material is shown, then weakens on an immediate repeat	First-use compilation or cache warm-up	Asset decompression or one-time object creation can behave similarly
Many first encounters hitch after a driver update, then improve over the session	A cold or invalidated driver cache	The update may also change performance or game-driver behavior
The same crossing hitches on every pass	Streaming, spawning, simulation, or another traversal task	A repeatedly missed pipeline is still possible
Frame time stays high throughout the scene	Sustained CPU or GPU load	A compilation event may coexist with the steady bottleneck
Position jumps while rendering remains visually smooth	Network or simulation correction	Check latency, jitter, and packet loss separately
Aim begins late around the center of a stick	Input filtering or hardware behavior	Check controller dead zones as a separate input problem

Epic explicitly cautions developers to look for other traversal-time work, including synchronous loading, spawning, streaming, and scene captures. A visual pattern remains a hypothesis until instrumentation identifies the work.

Deleting a healthy cache recreates a cold state

Cache deletion belongs in support procedures that address corrupted stored data or repeated compilation. Starting there for every hitch throws away reusable work before the player has recorded a baseline.

A cache exists to avoid repeating work. Removing a healthy cache deliberately recreates a cold state. Khronos’s sample expects the first run without reusable pipeline data to cost more, while Epic notes that an empty driver cache can lengthen loading and expose first-use behavior again.

Follow current instructions from the title, platform, engine, or GPU vendor when they specifically call for clearing data. In other cases, preserve the evidence, update the game through supported channels, allow preparation to finish, and compare like with like.

Copied configuration edits deserve the same caution. A switch may change compilation timing, memory use, or API behavior for one title and version while creating instability, visual differences, longer loads, or a new cache path elsewhere.

Give support a route they can reproduce

The central problem is timing. The pipeline must exist before the draw that needs it. A developer can pay the cost during installation, startup, a loading screen, background preparation, or the frame of first use. Each choice has limits because the full set of materials, states, hardware targets, and runtime content can be large.

For a player, a cold-cache pattern explains why the first encounter may be rough, why the repeat may improve, and why a driver update can make familiar scenes behave like new work. Repeated hitches at the same crossing or steady high frame times point the investigation toward other causes.

A useful report includes individual frame time from repeated passes through the same route, the fixed settings, and every variable that changed. A support team can attempt that route under comparable conditions, and instrumentation can confirm whether pipeline creation occupied the late frame.