Improved CPU timing with async thread

[breno-assis]

Summary

Improve stability of the per-draw motion-vector path in VR-heavy city scenes by reducing render-thread disruption in the draw-id pipeline.

This change:

• moves the CPU-only prepare grouping/sorting work off the render thread onto a persistent worker
• adds timing breakdowns for prepare wait / scan / sort / upload to make render-thread stalls visible in logs
• replaces getter-heavy DrawIdRecord::Record capture with shadowed D3D11 state for IA / VS / RS paths
• extends the shadow path to cover VS constant-buffer binds, including D3D11.1 offsetted binds
• adds runtime verification logs to confirm whether record capture is using the shadow path or falling back

The goal is improved timing stability and less noticeable CPU hitching in dense VR scenes, even where average CPU cost does not drop dramatically.

Observed Issue

In VR, especially in dense city scenes with lots of traffic and geometry, the per-draw motion-vector path could introduce noticeable CPU timing instability. The issue was less about one large average cost and more about where the work landed on the render thread and how uneven that cost felt during play.

What Changed

• Off-threaded DrawIdMv::Prepare grouping/sorting work via a persistent worker thread
• Added render-thread-visible wait timing and prepare subphase instrumentation
• Added shadow-state capture for DrawIdRecord::Record
• Added VS constant-buffer shadowing, including D3D11.1 VSSetConstantBuffers1
• Added runtime shadow-hit logging to verify whether the capture path is using shadowed state

Validation Notes

Runtime logs confirm that the shadowed record path is active:

• MV draw-ids shadow @blit reports 100% shadow-hit rate for all tracked fields, including cb

Measured results suggest:

• no large reduction in average draw-id CPU cost in the tested scenes
• improved timing structure and better visibility into render-thread stalls
• subjective VR smoothness appears improved even when headline CPU timings remain similar

Testing

Tested on:

• Meta Quest 3
• Virtual Desktop
• NVIDIA RTX 5080
• AMD Ryzen 7 9800X3D

Scenario:

• consistent daytime driving around San Francisco
• debug = 1 enabled to collect runtime timing and draw-id diagnostics

[JRDevo]

Hi @breno-assis, thank you for this PR!!!!
The core idea is right and it is in the mod now: remembering the game’s input state as the game sets it, instead of asking the driver for ~10 things at every draw. It is did_shadow = 1 by default in the test build, and I measured it: ~130 → ~105 ns per draw in ETS2 VR.

You are credited as co-author on the commit (e5db8ff) and in the README’s thanks line. The test build with it is here, if you want to try it:
https://github.com/JRDevo/ETS2-ATS-DLAA-DLSS-Injection-Mod/releases/tag/v0.11.0-rc1

PR did not merge as it stands.

What I found when reviewing and running it:

• The remembered state is never re-checked. Nothing drops it on ClearState, ExecuteCommandList or SwapDeviceContextState, and the D3D11 runtime also unbinds resources by itself (read / write hazards). The record could then copy a state the game no longer has.
• The copied pointers are not owned (no AddRef). A resource the game releases between its Set and our record can dangle.
• The prepare worker thread was slower on average in my runs, with 31 ms stalls under CPU load, and the exit path could hang.
• motion_vectors.cpp: StaticGated() became m_didN != 0, which changes when the static gate opens.
• The draw-id test harness drops to 50,349 / 136,840 checks with the shadow on. Part of that is a harness artefact (it drives the getters directly), but it hid the points above.

The version in the mod adds owned references, hooks on ClearState / ExecuteCommandList / SwapDeviceContextState, a check that the hooked entries still point at our detours, a drop on another thread’s Set, and a verify mode (did_shadow_verify) that compares every Nth record with the getters: 6490 compares, 0 mismatches in a VR drive. The harness passes 136,840 / 136,840 with it on.

Check the latest version.... If you spot something I got wrong in the rewrite, please let me know.

Many thanks for spending your time helping here :)