Guide: Running the NVIDIA Offline Shader Compiler

Gaming and Visualization Technologies Announcements
1

Guide: Running ASD for NVIDIA GPUs

Getting the required files

  1. Get the NVIDIA Display Driver installer.

  2. The offline compiler files are currently shipped inside the NVIDIA Display Driver installer. You can extract them directly from the driver .exe using 7-Zip; navigate to the display.driver subfolder to find all the required DLLs and .bin file:

  • nvd3d12scx.dll

  • nvwgf2umx.dll

  • nvgpucomp64.dll

  • nvmemmapstoragex.dll

  • nvdrsdb.bin

  1. Place the extracted files in the same folder as D3D12StateObjectCompiler.exe

Requirements

  • 7-zip is required to extract files form Display Driver Package.

  • NVIDIA compiler can be used with D3D12StateObjectCompiler.exe on any x64 Windows® PC or server.

  • NVIDIA GPU is not required to run the compiler.

  • ASD is supported on Driver version 621.01+

How to compile SODBs to PSDBs

  1. Capture SODB using one of the methods described by MSFT here

  2. Compile SODB to PSDB using the following

D3D12StateObjectCompiler.exe compile --plugin .\\nvd3d12scx.dll --adapter-family NVIDIA_ --abi <in.sodb> <out.psdb>

  1. Register the PSDB as described by MSFT here and test the cache hit rates using D3D12CacheListener

  2. All generated PSDBs will only be compatible with the NVIDIA Display Driver used to generate the PSDBs.

More ways to use D3D12StateObjectCompiler.exe can be found here

Known Issues

  1. Multiple Processes and PSDB Reuse

The NVIDIA compiler does not support multiple instances of `D3D12StateObjectCompiler.exe` writing to the same PSDB, either concurrently or sequentially. Multiple instances can run concurrently if each writes to a different PSDB file. An existing PSDB cannot be reopened for incremental compilation.

  • Workaround: Generate each PSDB using a single compiler instance. To regenerate a PSDB, delete the existing file and compile to a new one.
  1. The --processes Flag

The --processes command-line option in D3D12StateObjectCompiler.exe is unsupported and unsafe on NVIDIA compilers if your application uses any static samplers.

Best Practices for Game Developers

SODB coverage across GPU vendors

Engine-level differences between GPU vendors can cause a SODB captured on one hardware platform to miss shader variations required by another.

  • Recommendation: Avoid capturing SODBs on a single IHV GPU. Either generate a dedicated SODB per vendor or build a merged SODB containing data across all target IHVs.

Aftermath Shader Debugging

If your application uses NVIDIA Aftermath, enabling `GFSDK_Aftermath_FeatureFlags_GenerateShaderDebugInfo` changes the compiled shader binaries. NVIDIA compiler currently cannot detect this setting and assumes the flag is disabled.

  • Impact: A PSDB generated from a SODB (State Object Database) recorded with this flag enabled will not produce cache hits at runtime.

  • Recommendation: Keep this flag disabled and contact your NVIDIA contact for further support.

NvAPI Usage

NvAPI calls communicate directly with the NVIDIA display driver, while SODB capture records interactions between your application and the DirectX 12 runtime. As a result, SODB files do not capture NvAPI calls, and any shader compilation settings applied through NvAPI are not reflected in the generated PSDB binaries.

  • Impact: Shaders that are modified by NvAPIs will not produce a cache hit at runtime.

  • Recommendation: Contact your NVIDIA contact for further support.

Set Application Identity

All D3D12 applications should call SetApplicationIdentity().

  • Impact: NVIDIA compiler relies on this value to apply application-specific driver profile and optimizations used for shader compilation.

  • Consistent application identity: Call `SetApplicationIdentity()` with the same values across all builds, including SODB capture and release builds. Calling it only during capture prevents the driver from matching runtime sessions to the SODB/PSDB data.

  • Consistent pExeFilename & pName: Do not change these fields over time. The DX runtime does not validate pExeFilename against your actual binary executable name, so you can safely lock it to an early project codename as long as it remains unique across titles.