GaymerX

Everything that counts as a game

Video Games

Why Your PC Game Compiles Shaders Every Single Launch, and How To Make It Stop

If you’ve clicked on this article, you’re probably tired of watching long loading screens with cryptic messages like “Compiling shaders... 40%.”

GaymerX desk · 4 min read · updated 2026

Why Your PC Game Compiles Shaders Every Single Launch, and How To Make It Stop
ASUS NVIDIA GeForce 210 silent graphics card with HDMI. Photo: Joydeep, CC BY-SA 3.0 — via Wikimedia Commons.

If you’ve clicked on this article, you’re probably tired of watching long loading screens with cryptic messages like “Compiling shaders... 40%.”

As it turns out, the real causes are subtle handshakes out of view that guide cache decisions, not bugs to squish. Although shader compilations fade away with time if nothing changes, updates to your hardware’s driver or the game itself can restart the whole assembly process in titles like Skyrim.

Why The Cache Disappears

Up against the seeming mystery of shader recompilation, this much is true: Driver and game version changes can do it. They can do it without ill intent, too; caching systems attach to specific known code versions, which means they must check changes to the logic at hand. The Unreal Engine’s <https://dev.epicgames.com/documentation/en-us/unreal-engine/fshadercache-in-unreal-engine> documentation clearly states that the shader cache explicitly ignores contents from previous versions, and that there’s no direct carryover. Unreal Engine’s developer community backs this up, noting that cache contents from one game “cannot be reused for another new version.”

CryEngine makes the utility of caching especially clear, stating in its <https://www.cryengine.com/docs/static/engines/cryengine-5/categories/23756813/pages/23306643> shader documentation that the point of the process is to bring pre-compiled shaders into play.

When the game begins, it invalidates the cache. The shader cache is also used by drivers, which can find it useful to invalidate earlier shader entries after the installation of an update. As one DXVK GitHub issue report explains, new code paths and data references in a fresh driver may influence cache size and timing, so the process involves more handshakes than the game or its engine might even witness.

This is laid out in greater detail in an NVIDIA developer forum thread, which describes when shader caches become unreasonably large from the user's perspective, especially in a driver update that both produces very large caches and then churns through them. AMD explicitly includes both DirectX 12 and Vulkan, as well as pre-Vulkan caching, in its explanation for why a shader cache might churn when a new driver arrives.

At least one Steam community discussion notes the confusion that shader caches can cause, and attributes it to more than just the user’s machine. The report highlights changes in shader code and shader pipelines as shader recompilation triggers for games that really do have them, blaming the vendors or game source changes, not just the user.

Engine-Specific Versioning

The layered approach to versioning in an engine can play into its game’s shader cache behavior, with some verification on this point. As laid out in the Unreal Engine documentation, when a new game version is specified the shader cache ignores entries from the previous codebase, and the documentation states you cannot carry them down between versions. Although this detail relates to an update where the same engine is involved, versioning can definitely play into shader cache availability.

Driver Updates As The Usual Trigger

Driver updates turn out to be a big deal, with enough evidence for stronger conclusions. A Steam discussion about The Last of Us Part 1 states that changing the device driver invalidates the shader cache, noting that every GPU driver update does so. As just one more illustration, an AMD community post describes how a brand-new driver invalidates the old shader cache because the driver has new code and references, and new caching begins from scratch.

The details in the NVIDIA developer forums should also be considered here. Some shader caches do become large for no reason that’s obvious for others to observe, and might invalidate because of it. On top of that, the thread describes a case involving shader cache behavior on Linux Overwatch players, showing that the issue can be about the driver rather than any single PC game – or even a consistent issue in the game engine’s versioning.

What The Verified Material Does Not Support Yet

That said, some frequent shader cache fixes are unconfirmed. Cloud sync can break shader caches for Steam, Epic, GOG, and anyone else who attempts it, although this lacks stuff like vendor confirmation. Shader caches being too large, causing recompilation, and the difference between a "cosmetic fix" and a real one are also unverified, although there's enough evidence of the former case to suggest it's a very real trigger whether its directly documented.

Practical Implications

That all said: If you play around with drivers, and/or choose to update your game, you might notice shader recompilation every launch. And after a clean cache? It can run slower the first time. This is all based on justified expectation as informed by the verified points above.

Shader Caching is versioned And Can Be Invalidated

Shader caching is not as simple as just ignoring large loading times when you visit the game once. Shader caches are tied to code versions, not just to the game's name or version in the engine docs you can see. That means a driver or game change can invalidate old shader entries, running shader recompiles until a new shader cache gets built up. After that authority is restored, it'll pick back up. But the initial recompilation, it's to be expected.