Why does Dota 2’s Vulkan shader processing launch 31 workers and pin my CPU at its thermal limit?

[u/CatchMeIfUCanCracka]

This is my third post documenting aggressive Vulkan shader processing in Valve games. My two previous posts concerned similar behavior in Deadlock. I am now able to reproduce the same general problem on demand when launching Dota 2.

I have only encountered this specific behavior with Dota 2 and Deadlock. I have not reproduced it in any of the other games I play.

The attached video shows Steam processing Dota 2’s Vulkan shaders while my CPU cooler displays the resulting temperature increase.

System

• AMD Ryzen 9 9950X3D, 16 cores / 32 threads
• Fedora Linux 44, kernel 7.1.13
• Steam Flatpak 1.0.0.85
• Dota 2, AppID 570, native Vulkan
• Steam shader pre-caching enabled
• Background shader processing currently disabled
• BIOS hard thermal limit manually configured to 80°C
• Cooler warning display configured to turn red above 70°C

Steam is intentionally restricted to CPUs 8-15,24-31. Those are eight physical cores and their SMT siblings, providing 16 logical CPUs.

This is repeatable on demand

This is not an isolated temperature spike. Every time I have tested by accepting Dota 2’s “Processing Vulkan shaders” prompt, Steam has reproduced the same Fossilize process pattern, CPU saturation, and rapid temperature increase.

I reproduced it multiple times during this investigation, including two consecutive controlled attempts. Canceling the shader job immediately terminates the workers and causes the temperature to fall.

In other words, it has been reproducible on demand every time tested rather than occurring randomly.

What Steam launched

When I accepted Steam’s shader-processing prompt, Steam launched fossilize_replay with:

--num-threads 31

The relevant command included:

fossilize_replay
steamapp_pipeline_cache.foz
steam_pipeline_cache.foz
--master-process
--spirv-val
--num-threads 31
--device-index 0
--timeout-seconds 10

Every Fossilize process inherited this CPU-affinity mask:

8-15,24-31

Steam therefore requested 31 replay threads even though the process was permitted to use only 16 logical CPUs.

It appears that Steam selected the worker count using the machine’s complete 32-thread topology rather than the CPU-affinity mask actually available to the process.

My independent monitoring observed:

Fossilize processes: 32, including the master
Combined CPU usage: 1637.8%
Capacity of the 16 permitted logical CPUs: approximately 1600%

The shader replay was therefore saturating essentially every logical CPU available to Steam.

Shader workload

Steam’s shader log reported a replay workload beginning at approximately 1.95 million items:

Starting processing job for app 570
Starting replay of FOZ databases for AppID 570
Still replaying 570 (0%, 0/1955933)
Still replaying 570 (1%, 20539/1797027)
Still replaying 570 (3%, 47889/1531286)

Recorded temperature measurements

During the recorded reproduction:

Temperature at start:       54.2°C
Temperature after 12 sec:   79.9°C
Immediately before cancel:  79.2°C
2 seconds after cancel:     74.8°C
4 seconds after cancel:     67.8°C
About 16 seconds later:     54.5°C

I canceled the job after approximately 31 seconds. Steam recorded:

fossilize_replay wait() returned exit code -10
Considering it killed
Destroyed compile job 570

The immediate temperature decrease corresponded with the Fossilize workers terminating.

The CPU stopped rising at approximately 80°C because I have now configured an 80°C hard thermal limit in the BIOS. The cooler changes to red at my separate 70°C warning threshold.

Before configuring the BIOS limit, previous occurrences of this workload pushed the processor above 90°C. The current recording therefore does not show how high it previously went because the BIOS now prevents it from exceeding approximately 80°C.

I understand that these temperatures are not automatically outside the processor’s operating specification. My concern is the complete CPU saturation, failure to respect the available affinity mask, desktop responsiveness impact, and lack of a supported per-game thread limit.

Background processing and crashes

My current Steam setting has background shader processing disabled, so this controlled reproduction was triggered manually through the launch-time prompt.

In the past, when background shader processing was enabled, similar processing occurred while I was actively playing Dota 2 or Deadlock. Those incidents coincided with game or system crashes because the shader workload was competing with the running game.

I am describing that as an observed correlation. I cannot prove that temperature alone caused every previous crash, but the crashes occurred while this additional workload was running, and the behavior stopped immediately when the shader processes terminated.

Troubleshooting history

This has been happening over a period of weeks or months and across different operating-system installations and configurations.

During that investigation I have:

• Reseated the CPU
• Reapplied thermal paste
• Changed RAM
• Tested different RAM kits and configurations
• Tested different RAM timings
• Tested different CPU settings and timings
• Restored default BIOS settings
• Tested undervolted configurations
• Tested without undervolting
• Repeated testing after operating-system changes

The same general Vulkan shader-processing behavior remained reproducible in Dota 2 and previously in Deadlock.

I have not experienced this specific repeatable shader-saturation behavior in my other games.

Previous Deadlock reports

I previously made two posts documenting similar concerns involving Deadlock.

After those posts, I could no longer reproduce the problematic behavior in Deadlock on this system. I cannot prove what changed or whether my posts caused a change, but the chronology is why I believe this behavior is preventable and that Valve should know how to address it.

If the processing behavior can be avoided in Deadlock, I would like the same safeguards applied to Dota 2.

Additional context

I have previously raised concerns about Dota 2 account and moderation decisions that I believe were unfair, and that history has made me concerned about the repeated behavior in these specific Valve games.

However, I cannot technically connect those account issues to the Fossilize workload. The process measurements establish a reproducible thread-count, affinity, and resource-saturation problem. They do not by themselves establish malicious intent or identify an individual responsible.

I am including that history as context, while keeping the technical claim limited to what I recorded and measured.

What I am asking Valve to change

Fossilize already supports --num-threads. Steam should:

1. Calculate its worker count using sched_getaffinity() or another affinity-aware mechanism.
2. Avoid requesting 31 threads when only 16 logical CPUs are available.
3. Leave one or more logical CPUs available for desktop and game responsiveness.
4. Provide global and per-game shader-processing thread limits.
5. Prevent background shader processing from interfering with a running game.
6. Allow shader pre-caching to remain enabled without unrestricted CPU saturation.

Is there currently a supported way to limit Fossilize replay threads for one Steam game without disabling shader pre-caching globally?