Impact of GPU Shader Cache on Initial Hardware Benchmarks

This article explains how the size and storage location of a GPU driver's shader cache directly impact the performance and accuracy of initial hardware benchmark runs. When benchmarking a computer, the very first pass often suffers from stuttering and artificially low frame rates due to real-time shader compilation. By understanding how shader cache size limits and storage drive speeds influence this process, hardware testers can eliminate storage bottlenecks, understand initial-run anomalies, and achieve consistent benchmarking data.

The Mechanics of the Initial Benchmark Run

Modern graphics APIs like DirectX 12 and Vulkan require games and benchmarking tools to compile shaders—small programs that tell the GPU how to render lighting, effects, and textures—specifically for the installed graphics card.

During an initial benchmark run, the GPU driver's shader cache is empty. As the benchmark progresses, the system must compile these shaders on the fly using the CPU, and then write the compiled data to the shader cache on the storage drive. This simultaneous compiling and writing causes several issues during the first run:

  • Severe Stuttering: Frame times spike as the GPU waits for the CPU to finish compiling shaders.
  • Skewed 1% and 0.1% Lows: While average frame rates might only drop slightly, minimum frame rate metrics will be drastically lower than normal.
  • Artificial CPU Bottlenecks: The CPU usage spikes to 100% due to compilation workloads, misrepresenting how the hardware actually handles the benchmark's standard rendering load.

How Shader Cache Size Affects Benchmarking

GPU manufacturers set a default maximum size for the shader cache in their driver software. If this size limit is too small, it directly compromises both long initial runs and subsequent testing passes.

Cache Eviction During Large Benchmarks

If a benchmark or a suite of benchmarks generates more shader data than the driver's cache size limit allows, the driver will overwrite the oldest compiled shaders with the newest ones. If a benchmark loops or revisits an earlier scene during the initial run, the system is forced to recompile the overwritten shaders, reintroducing stutters.

Invalidating "Warm-Up" Runs

Hardware testers typically perform a "warm-up" run to populate the shader cache, discarding the first result and recording the second. However, if the shader cache size limit is too restrictive, the shaders from the beginning of the benchmark are purged by the time the warm-up run finishes. Consequently, the second run will behave just like an initial run, ruining the consistency of the test. Increasing the shader cache size limit to "Unlimited" or the maximum allowable gigabytes in the GPU control panel prevents this issue.

How Shader Cache Location Affects Benchmarking

By default, GPU drivers store the shader cache on the primary operating system drive (typically the C: drive). The physical speed of the storage drive hosting this cache dictates how fast compiled shaders can be written during the initial run and read during subsequent runs.

Storage I/O Bottlenecks

During the initial run, the system is constantly writing newly compiled shader files to the disk.

  • Hard Disk Drives (HDD): If the shader cache is located on a mechanical hard drive, the slow write speeds will create an Input/Output (I/O) bottleneck. The CPU and GPU will stall while waiting for the drive to finish writing data, amplifying initial-run stuttering.
  • SATA SSDs: While much faster than HDDs, budget SATA SSDs (especially those without DRAM cache) can still experience write-speed drops during heavy, continuous shader compilation.
  • NVMe SSDs: Storing the shader cache on a fast PCIe NVMe SSD ensures that writing compiled shaders during the initial run happens almost instantaneously, minimizing storage-related frame time spikes.

Drive Contention

If the benchmark software is installed on the same drive as the shader cache, the storage device must simultaneously read massive benchmark texture files and write small shader cache files. Separating the benchmark installation and the shader cache onto different high-speed NVMe drives eliminates drive contention during the initial run.

Best Practices for Accurate Benchmarking

To control the variables introduced by the GPU shader cache during hardware testing, apply the following configurations:

  1. Maximize Cache Size: Open the NVIDIA Control Panel or AMD Software and set the Shader Cache Size to its maximum limit to prevent shader eviction between runs.
  2. Use Fast Storage: Ensure the primary OS drive (where the cache lives by default) is a high-speed NVMe SSD.
  3. Perform a Warm-Up Pass: Never use the initial run to judge pure rendering performance. Run the benchmark once to fully compile and write the shaders to the cache, then record the results of the second and third runs.
  4. Clear the Cache When Swapping Hardware: Always manually delete the shader cache folders when changing GPUs or updating drivers to prevent corrupted or incompatible cached data from crashing the initial run.