Physics Thread Affinity and Main‑Thread Render Synchronization in SourceEngine

Answer

In the stock SourceEngine build, there is no exposed console variable or configuration file that can change the affinity of the physics worker thread or enable multiple physics workers. The physics simulation runs on a single worker that is created during engine initialization. To move it to another core set or split it across cores you must modify the source code that creates the thread and optionally the synchronization primitives that enforce the render‑after‑physics ordering.

Key confirmed facts

• The physics worker is instantiated once per process; its thread ID can be found by inspecting the process’s thread list or by adding a log statement in the thread‑creation routine.
• All rendering commands are issued only after the physics tick for the current frame has completed; this is enforced by a frame‑barrier that the main thread waits on before submitting draw calls.
• SourceEngine does not expose any cvar or console command to set thread affinity for the physics worker, nor does it provide a public API to add additional physics workers.
• Changing the affinity of the physics thread (e.g., via SetThreadAffinityMask on Windows or pthread_setaffinity_np on Linux) does not alter the logical ordering, but it can affect cache locality and cross‑core wake‑ups, potentially introducing jitter.
• Adding a second physics worker would require a deterministic partitioning of physics objects and a new frame‑barrier that guarantees the same ordering of entity updates, which is not supported out of the box.

Practical steps for your branch

1. Identify the physics thread. Run a profiler (e.g., top -H on Linux, Process Explorer on Windows) while a physics‑heavy map is running. Note the thread name or ID that shows the highest CPU usage during the physics tick.
2. Locate thread creation code. Search the engine source for calls to std::thread, CreateThread, or pthread_create that correspond to the physics worker. Add a log line or breakpoint at that point to confirm the thread’s entry point.
3. Test OS‑level affinity. If you only need to experiment, use taskset -p on Linux or start /affinity on Windows to force the physics thread onto a desired core set. Verify that the main thread still waits on the same completion event before rendering.
4. Patch for multiple workers (optional). If you decide to split physics across cores, you must:
   • Determine a deterministic partition of physics objects (e.g., spatial hashing) so that each worker processes a disjoint set.
   • Insert a new barrier that waits for all physics workers to finish before the main thread submits render commands.
   • Ensure that any shared state (e.g., entity transformation lists) is protected by the same barrier to preserve the existing deterministic ordering.
5. Measure impact. Run the same map at identical tickrate with and without the affinity change or added workers. Compare frame‑time percentiles, server tick variance, and any prediction or demo playback artifacts.
6. Validate determinism. On listen servers or demo playback, confirm that the order of entity updates remains unchanged. A change in order can break demo playback or introduce subtle prediction errors.

What we still need to know

To give a more precise recommendation, could you tell us which SourceEngine branch you are working with (e.g., 2013 SDK, 2016 SDK, 2020 SDK, or a custom fork) and whether the engine uses Havok, the legacy VPhysics implementation, or a third‑party physics library? The exact physics backend can influence how the worker is created and synchronized.

Diagram

Main Thread	Physics Worker	Render Submission
Runs game logic, waits on PhysicsSync	Executes physics tick, signals PhysicsSync	Submits draw calls after PhysicsSync