On September 15, 2026, Microsoft made Advanced Shader Delivery (ASD), a feature that shortens the wait for shader preparation, available to all developers building Xbox PC games with DirectX 12. On October 1, it also announced an expansion of supported GPUs. The system, which delivers precompiled shaders alongside the game, is now growing in both supported titles and supported hardware.
However, an "ASD supported" label does not mean shader waits disappear in every situation. Keeping the benefit after a game update depends on how thoroughly developers collect the rendering workloads the game needs, and whether they keep that data updated to match each game version.
Since September, developers can add ASD support themselves
In its September 15 announcement, Microsoft introduced a self-service system that lets developers submit their own ASD data. It is aimed at developers building Xbox PC games with DirectX 12, and it requires the April 2026 update of the Xbox Game Package Manager. This is not an announcement that every game on Windows will automatically support ASD.
Microsoft had been expanding ASD's availability in stages. At GDC in March, it previewed a mechanism for developers to submit data and new APIs. In its June 11 update, ASD reached general availability in the Xbox PC app for all AMD RDNA generations.
What changed in September was not GPU support but the process by which developers enable ASD for their own titles. Dozens of titles had already been offered through the limited preview over several months. Existing participants will be contacted with migration instructions. The program has moved from a trial with a limited set of titles to a stage where studios can build ASD into their own update pipelines.
SODB, which developers submit, and PSDB, which reaches PCs, are different things
Shaders are programs that tell the GPU how to render the screen, including how light falls and what colors appear. To run on a PC, they must be compiled into a form suited to the GPU and driver.
Unlike game consoles, which have fixed hardware, PCs come with many combinations of GPUs and drivers. A game therefore cannot simply ship one set of compiled data. Compiling everything on first launch can mean a long wait, while compiling during play can cause stutter.
ASD does part of this work before it ever reaches the player's PC. According to the implementation guide, what developers submit is a SODB (State Object Database).
A SODB is not a bundle of finished shaders that the GPU can run as is. It is a database that records the Pipeline State Object (PSO) and State Object (SO) information the game uses, along with the DXIL-format shaders needed to rebuild them. The SODB specification describes this structure.
The store side receives the SODB and uses compilers provided by GPU vendors to generate a PSDB (Precompiled Shader Database) for each driver. This is the data precompiled for the actual GPU environment.
If the matching PSDB is delivered when the game is downloaded, the player's PC needs to repeat less of the same compilation work. The division of labor is that developers prepare the base SODB, and the store generates PSDBs for each GPU and driver.
Microsoft's technical overview lists benefits beyond shorter launch waits, including less stutter from in-game shader compilation and lower power consumption.
On the other hand, the time to load game data from storage and the GPU performance needed for rendering itself are separate matters. Shorter shader preparation does not necessarily improve overall load times or average frame rates by the same proportion.
Two ways to collect shaders, each with its own gaps
To precompile shaders, the rendering workloads a game uses must be recorded in the SODB in advance.
Microsoft's implementation guide offers two methods: "manual capture," which records workloads while the game is actually running, and "programmatic generation," in which the game enumerates the workloads it uses to build the SODB. Both produce a SODB, but data can be missing for different reasons.
The table below compares the two methods based on section 1.2 of the implementation guide as of October 3, 2026. It is not a performance measurement; it summarizes differences in implementation approach and collection conditions.
| Comparison | Manual capture | Programmatic generation |
|---|---|---|
| What is collected | Rendering workloads generated during actual play | Rendering workloads the game knows about |
| Engine changes | Not required; recorded with a capture tool | Requires integrating a generation API |
| Coverage limits | Depends on the scenes, settings, and hardware actually tested | Depends on how complete the game's workload list is |
| Work at update time | Run the game and capture again | Can be built into the build process and generated automatically |
| Suitable stage | Released titles or titles late in development | Titles early in development, or engines that can enumerate workloads |
Manual capture records only the workloads generated in the scenes and settings that were actually played. For example, if capture is done only at standard graphics settings, workloads needed only when ray tracing is enabled could be missed.
The guide recommends trying multiple graphics presets and major game segments. Where different GPU vendors use different code paths, it advises merging SODBs captured on each vendor's hardware. Being able to adopt ASD without changing the engine is not the same as being able to capture every needed workload.
With programmatic generation, the game writes the PSOs and SOs it knows about into the SODB through an API. Because it can be built into the build process, the same work can be repeated automatically with every game update.
However, it does not automatically discover workloads the game has not listed. For integration into a proprietary engine, the guide gives a development-time estimate of several weeks to several months. For titles using middleware or game engines that already support SODB generation, the workload can be much smaller, so this estimate cannot be applied to every title.
How much of the workloads actually needed were served by precompiled data can be checked through the cache hit rate. Microsoft's guide treats 90% or higher as a good result.
A 90% cache hit rate does not mean waiting time falls by 90%, however. Settings and play that differ from what was captured, GPU-specific code paths, and the state of support on the GPU vendor's side all have an effect. Even after adopting ASD, the work of finding and adding uncaptured workloads remains.
Waits can return after a game update
Even if enough SODB data was prepared at launch, an update that changes the game's rendering workloads can leave the earlier data insufficient.
In its September announcement, Microsoft explained that if the game and the SODB package versions fall out of sync, shader compilation may occur again in the game. In that case, a new SODB must be submitted to match the update.
That said, not every patch invalidates ASD entirely. Microsoft explains that the impact depends on the content and frequency of changes, and that it is not a binary question of working or not working.
The SODB specification uses version information for individual rendering workloads to match against precompiled data. Some workloads remain unchanged after an update, while only those that were renewed may need to be compiled again.
Information identifying the game is also important for using precompiled data correctly. The application identity specification handles items such as the executable name and game name, as well as the app version and game engine information.
This is used to correctly match per-game driver optimizations with precompiled shaders. The implementation guide also lists an identity mismatch as one cause of a 0% cache hit rate.
In other words, ASD support is not finished by submitting a SODB once before launch. Developers must recollect the rendering workloads they need as the game changes, and keep delivering data with matching versions and identity information alongside the game.
The significance of September's move to self-service is that each developer can now carry out this ongoing update work within its own development and distribution process.
GPU support expands in October, with NVIDIA and Intel due this month
In its October 1 announcement, Microsoft gave a common operating requirement of Windows 11 24H2 or later. GPU support breaks down as follows.
Intel and NVIDIA support is planned for October. This does not mean all eligible GPUs were available as of October 3.
| GPU vendor | Announced targets and conditions | Status as of October 1 announcement |
|---|---|---|
| AMD | RDNA 1/2/3/3.5/4; Adrenalin 26.6.1 or later | Available |
| Qualcomm | Snapdragon X2 series; graphics driver 2026.08.3 or later | Available |
| Intel | Arc B570/B580, Core Ultra Series 2/3 | Planned for October |
| NVIDIA | All RTX GPUs, RTX Spark | Planned for October |
In the same announcement, Microsoft explained that for Gears of War: E-Day, the initial shader compilation time fell from several minutes on a typical PC to a few seconds, a reduction of about 95%.
However, this figure comes from Microsoft's own explanation, and the announcement does not give the detailed configuration of the PC used for comparison or the specific number of seconds. Also, the roughly 95% figure refers to shader compilation time, not to a 95% reduction in the game's overall launch or load time.
There are also caveats about delivery. To use ASD with E-Day, Microsoft advises installing the Xbox PC app before downloading the game.
Meanwhile, developer The Coalition's pre-launch notice says that even for players who get the game from somewhere other than the Xbox PC app, ASD may still help if the Xbox PC app is installed on their Windows 11 PC, because the necessary precompiled shaders can be installed.
This is a condition presented for Gears of War: E-Day, however, and does not mean all third-party stores support ASD delivery.
What users should check is not only whether their GPU supports ASD. Whether ASD is available for that particular game, which delivery method is required, and whether new shader data will keep being provided after updates also matter.
With ASD easier for developers to adopt, how completely each title's required shaders are delivered in advance, and whether that state is maintained after game updates, will determine the actual waiting time.