DirectX Shader Cache Sizing and NVMe SSD Queue Depth Saturation: Edge Cases, Failure Modes, and Root-Cause Debugging

[Dylan Gray]

I’ve been chasing micro-stutter in competitive shooters and suspect it’s tied to shader cache thrashing against NVMe queue depth starvation during random 4K low-QD reads. When the driver streams compiled shaders, my 99th percentile latency spikes hard even though sequential throughput looks fine—feels like the queue depth collapses to 1 right when the decompression pipeline wants to fan out. Does anyone have real data on where the practical ceiling is for shader cache size before you start saturating a single NVMe lane? I’m running a Gen4 drive and wondering if I’m bottlenecked on internal bandwidth or if it’s the driver’s batching logic.

Has anyone found a reliable way to profile shader decompression throughput independently from the storage stack? I’ve tried isolating the symptom with custom traces but can’t cleanly separate cache misses from decompression stalls. What tools are you all using to catch these edge cases, and has anyone hit actual failure modes—like cache corruption or driver timeouts—when pushing cache sizes past the recommended defaults? Curious if capping the shader cache or forcing writes to a separate volume actually helps, or if this is just something the drivers need to handle better.

🎮 Battlestation & Rig: Ryzen 5 7600X | RTX 4070 Super Dual | 32GB DDR5 6000 CL30 | FormD T1 SFF | AOC AGON Pro AG276QZD 240Hz QHD OLED | Custom Tofu60 Lubed Gateron Oil Kings + Lamzu Maya 4K + Artisan Hien Mid | Beyerdynamic DT 990 Pro (250 Ohm) + FiiO K5 Pro ESS DAC

📍 Toronto, ON (Canada)

"Chasing the silicon lottery one megahertz at a time."

[Sebastian Nelson]

Here’s where most people get tripped up: the D3D shader cache and NVMe queue depth interact in ways that are easy to misdiagnose. The default shader cache grows until it hits a threshold, and when it’s constantly thrashing (compiling+evicting), you’re generating a storm of small random I/O. On a mid-tier NVMe with no DRAM cache (think QLC drives or budget PCIe 3.0 parts), a single queue depth of 1-2 can

[Ethan Murphy]

Great topic, and I’ve hit this exact wall during competitive titles where shader compilation stutters kill my frame pacing. The key thing people miss is that the shader cache and NVMe queue depth interact in a way that’s easy to misdiagnose. When DX12’s SHADER_CACHE flag is enabled (default in Win11), the driver writes compiled bytecode to the cache, but if that cache is undersized or gets corrupted, you don’t get a clean sequential read anymore — you get dozens of small, random 4KB-64KB reads hammering the SSD’s command queue. NVMe handles this through its 32 queue x 2048 depth architecture, but those small reads don’t coalesce well, so even a fast Gen4 drive can hit queue saturation and spike latency. I’ve seen the DPC/ISR time jump from ~0.1% to 8-15% in WPA during these events, which shows up as micro-stutters that destroy your aim in a shooter even though your average

"Playing Unreal Tournament 99 on instagib mode since childhood."

[Author]

Posts