The core issue is a synchronous Fork-Join barrier inside the engine: the Main Thread splits jobs across worker threads and has to wait for all of them to finish before proceeding with the render pipeline. While it waits, the GPU simply runs out of commands to draw.
Look at the Blocking stack in the bottom left:
- engine2.dll: Source 2’s core loop coordinating the current frame
- scenesystem.dll: The scene renderer trying to process visibility, objects, and draw lists
- tier0.dll!0xA4CF5: (The bottleneck) Valve’s low-level threading library. This function is an explicit job barrier that forces the thread to stop and wait for worker tasks to complete
- KernelBase.dll & ntdll.dll (ZwWaitForMultipleObjects): CS2 explicitly asks the Windows kernel to put the thread to sleep until all handles are signaled
- ntoskrnl.exe: Windows suspends the thread into the Synchronization state.
Because this happens synchronously inside scenesystem.dll, render submission completely stops. The GPU finishes rasterizing in ~1.2ms, runs out of draw calls, and goes into starvation (MsGPUWait).
This confirms it’s an internal synchronous design flaw inside Source 2, not driver overhead or system latency.
Archaic engine design from a multi-billion dollar company... insane.
Any ideas on how to push this publicly to force Valve to decouple the render queue from the main thread?
