On October 21, 2026, Microsoft announced that developers can now build Advanced Shader Delivery (ASD), a shader precompilation technology, into their production pipelines with Unreal Engine (UE) 5.8.4. Epic Games' UE 5.8.4 release notes also state that the version adds a feature for generating ASD data from a game build, along with tools for testing compilation and registration in a local environment. ASD delivers precompiled, GPU-specific shader-related data together with the game, reducing the compilation workload on players' PCs. With this support, developers can generate delivery data without running the game, but it cannot cover every necessary rendering workload. To see real benefits, developers need to check both how much data is captured and how ready the game is at runtime.
ASDTool generates delivery data from a game build
The newly added "ASDTool" is a standalone command-line tool that generates ASD data from a game build. It works from a build that has been converted and optimized for the target platform, so there is no need to launch Unreal Editor or run the game. Microsoft's October 21 announcement states explicitly that ASD data can now be integrated into the production pipeline with UE 5.8.4. Epic Games' release notes likewise confirm the data generation feature, plus a tool for verifying local compilation and registration.
Shaders are programs executed by the GPU, and a PSO (Pipeline State Object) bundles a shader with the settings needed for rendering and compute work. The "SODB (State Object Database)" produced by ASDTool stores the information needed to rebuild shaders, PSOs and related objects in a GPU-independent format. The game's distribution store compiles this SODB for each GPU type and driver to create a "PSDB (Precompiled Shader Database)." By delivering the PSDB that suits each player's PC, part of the compilation work previously done on each machine can be completed in advance. Developers prepare common data, and the store handles per-GPU compilation and delivery.
However, adopting ASD does not eliminate PSO creation at runtime. When the game creates a PSO and the corresponding data is in the PSDB, the driver loads the precompiled data. PSOs that are not in the PSDB still need to be compiled as before. In other words, even if an SODB is generated successfully, stutter caused by compilation may remain if the PSOs the game needs are not sufficiently captured.
There are also several prerequisites. According to the ASDTool usage instructions published by Epic Games, ASDTool is not distributed as a compiled executable, so developers must build it from the Unreal Engine source code. The target is a Windows build using Direct3D 12 (D3D12) with Shader Model 6 (PCD3D_SM6). Shader code sharing must also be enabled to generate the shader archive. This is on by default, but it must be changed if the project settings have disabled it.
Microsoft describes two ways to generate an SODB: an automated approach built into the development pipeline, and a manual approach that captures data by actually running the game. Automated generation is recommended for new or early-stage games where it can be used continuously. Manual capture suits games that have already shipped or are late in development, where heavy engine changes are hard to justify. The UE 5.8.4 ASDTool makes it easier to adopt a process that repeatedly generates data to match game builds, but no concrete measurements have been provided on how much development effort it actually saves.
Compute shaders are captured in bulk; graphics PSOs depend on existing caches
What ASDTool can capture differs between compute shaders and graphics PSOs. Compute shaders for Shader Model 6 can be captured in bulk from the game's shader archive. Graphics PSOs, by contrast, must be imported from an existing PSO cache prepared during development. Even though the same tool generates both, the conditions that determine coverage are different.
According to Epic Games' official documentation, the main capture methods available in ASDTool are as follows.
| Target | Capture method | Coverage and limitations |
|---|---|---|
| SM6 compute shaders | -AllCompute |
Captures everything in the shader archive in bulk |
| Graphics and compute PSOs | -BundleDir |
Captures from an existing PSO cache. Graphics PSOs can only be imported this way |
| Ray tracing PSOs | Not supported | Currently outside ASDTool's capture scope |
-AllCompute and -BundleDir can be used together, in which case duplicate compute shaders found in both sources are removed. This lets you pull in all compute shaders in the archive while also capturing the graphics PSOs recorded in an existing cache in a single SODB. However, the coverage of graphics PSOs is determined by the contents of the source PSO cache, so rendering workloads not recorded in the cache are not added automatically.
Being able to capture compute shaders in bulk is therefore a separate matter from covering all the graphics PSOs the game needs. For graphics PSOs, as before, developers need to check whether the cache includes the PSOs required across various scenes and graphics settings. Even though an SODB can now be generated without running the game, collecting PSOs and verifying coverage are still necessary. And even if the required PSOs are in the delivery data, stutter can still occur if they are not ready by the time the game uses them.
ASD alone can't prevent stutter; use it with PSO precaching
Epic Games recommends keeping the conventional PSO precache enabled even in games that adopt ASD. PSO precaching is an Unreal Engine mechanism that collects the PSOs a game will need and prepares them asynchronously before they are actually used. ASD does not replace the precache or the PSO cache bundled with the game; it complements them by delivering precompiled data. PSOs not in the PSDB still have to be compiled as before, so keeping the precache running helps address stutter from PSOs that fell outside ASD's coverage.
Even when the PSDB contains the required data, load-related delays do not necessarily disappear entirely. Precompiled shaders still have to be read from disk, and depending on timing, small stutters can occur. PSO precaching also serves to handle such loading and preparation before the data is needed for actual rendering. The division of labor is that ASD completes GPU compilation in advance, while PSO precaching prepares for the timing of use at runtime.
For this reason, when evaluating ASD's effect, the PSDB hit rate and the PSO precache readiness need to be checked separately. Even with a high PSDB hit rate, stutter during play can remain if the required PSOs are not ready at the moment of rendering. Conversely, a low hit rate means you should investigate whether the necessary PSOs were not captured in the SODB, or whether the PSDB is not being registered and matched correctly. It is important to isolate whether the problem lies in data capture, delivery and matching, or runtime preparation.
Based on Epic Games' ASD generation instructions, Microsoft's implementation guide and the official Unreal Engine documentation on PSO precaching, the main items to check can be summarized as follows.
| Observed condition | Area to check | Main items to check |
|---|---|---|
| Low PSDB hit rate | ASD capture and delivery | Coverage of required PSOs, especially the cache that graphics PSOs are imported from |
| PSDB hit rate of zero | ASD matching and registration | Whether executable name, game name and engine information match, and whether the executable path is registered |
| "Missed" in UE validation stats | PSO precaching | PSOs that were not subject to precaching at the time of use |
| "Too late" in UE validation stats | PSO preparation timing | Whether compilation of PSOs registered for advance preparation finished before use |
| Small stutters when loading from the PSDB | Preparation before PSO use | Whether the precache that prepares for disk reads is working properly |
The ASD-side hit rate can be checked from Event Tracing for Windows (ETW) records using tools such as "D3D12CacheListener." "Missed" and "Too late," on the other hand, are validation statistics for Unreal Engine's PSO precaching. "Missed" indicates that a required PSO had not been precached at the time of use, while "Too late" indicates that the PSO was queued for advance preparation but compilation did not finish by the time it was needed. Combining the ASD-side capture and matching status with the UE-side PSO readiness helps narrow down the cause of stutter.
That said, a low or zero hit rate alone does not pinpoint a single cause. The PSDB hit rate and UE's precache statistics also measure different things and are tallied differently, so comparing their numbers directly is not appropriate. These are check items based on specifications in the official documentation, not benchmark results showing how much stutter ASD reduces. Nor is the same effect guaranteed on unsupported GPUs and drivers, or for PSOs outside ASD's scope.
Regenerating data after shader changes, and store-side support
To use ASD continuously, SODBs need to be managed appropriately as the game is updated. Because an SODB stores the shader code contained in a game build, it must be regenerated whenever shaders change. For builds with no shader changes, the existing SODB can be reused. The expected workflow is therefore to run generation in response to shader changes rather than rebuilding the data unconditionally for every patch. It is important to confirm that the updated game still contains the necessary data, including coverage of graphics PSOs.
For pre-release verification, ASDTool also includes a feature that reproduces store-side processing locally. Using a GPU vendor's D3D12 compiler plugin, you can generate PSDBs from an SODB with the compilepsdbs command, then register them in the local environment with the registerpsdbs command. By launching the game after registration and checking whether the PSDB is actually loaded, you can verify not just that the SODB was generated, but that it is used correctly in the runtime environment. With these features, developers can check the whole chain from data generation through compilation and registration to runtime use before submitting to a store.
This verification also requires attention to the consistency of the information that identifies the game. The game name, executable name and engine information recorded in the SODB must match those of the game actually being launched. When registering a PSDB locally, the path of the target executable must also be specified correctly. For example, the argument that specifies the engine name uses a major.minor version such as UnrealEngine5.8, per the specification, rather than the UE 5.8.4 version number that added ASD support. Even if the data is generated correctly, the PSDB may not be used when the game runs if this identifying information does not match.
Meanwhile, developer support for ASD alone does not mean every player benefits. Microsoft's October 21 announcement said ASD is available in the Microsoft Store and the Xbox PC app, with support planned for Steam and the Epic Games Store. Epic Games plans to support the Epic Games Store in early 2027, while no specific start date has been given for Steam. Fortnite is also planned to support ASD in a future update. Even when UE's development tools support it, getting the data to players requires support from both individual games and distribution stores.
There are conditions on the player's side as well. Using ASD requires Windows 11 version 24H2 or later, plus a compatible GPU and driver. Microsoft has announced rollout to supported hardware from AMD, Intel, NVIDIA and Qualcomm, but not every GPU or driver can use it. In unsupported environments, shaders still need to be compiled while the game runs as before, so developers must keep their existing PSO caches and precaching. UE 5.8.4 support therefore does not mean existing Unreal Engine games can suddenly all use ASD.
At this point, no independent benchmark results are available showing how much UE 5.8.4's ASD support improves frame times or stutter during real gameplay. A high PSDB hit rate also does not resolve stutter with causes other than shaders. What matters about this update is that developers can more easily build SODB generation and local verification into their production pipelines, moving part of the compilation work done on players' PCs into advance processing and delivery. Going forward, the key questions are whether real games can capture enough of the PSOs they need, whether the data is matched and used correctly after updates, and how much player experience improves as store support expands.