handoff(forge): windows A/B of parallel draw-list replay, engine 06ecc5df

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018hSLRwirUk2NF4j1v2kH4Z
This commit is contained in:
ozanandClaude Opus 5.5 committed 2026-10-19 00:10:45 +01:00
1 parent ddb10953c6
commit bde94a1bca
1 file changed
+53
@@ -0,0 +1,53 @@
# Forge: Windows A/B of parallel draw-list replay (engine 06ecc5df)
Why: Windows sits at 45–50 fps with the RTX 5080 idle. The render thread is the limiter (10–13 ms wall, `end_frame`
replay + submit 3.8–4.8 ms). The NVIDIA/WDDM driver path is paid serially on that thread for every `vkCmd*`.
Engine `06ecc5df` can cut large draw lists into chunks and record them into secondary command buffers on worker
threads (Vulkan only, **default off**). Design + Mac results: engine `.agents/wiki/parallel-draw-replay.md`.
Nothing is published or pinned for this yet. This is a test build on Forge only.
## 1. Build + oracle (Vulkan, Khronos layer)
1. `git checkout 06ecc5df` in the engine, build the Windows editor with the `windows-x64` manifest flags.
GodotSharp regen is not needed for the test: the game reaches the new API through `Call`.
2. With the Vulkan SDK's validation layer available (`--gpu-validation` turns it on):
`bash tests/gpu_oracle/parallel_draw_replay/run.sh <tinqs.windows.editor.x86_64.mono.exe> vulkan`
Expect `ORACLE: 6 passed, 0 failed`, exit 0, **zero `VUID` / validation lines** in the output. Paste the
output back.
## 2. In-game A/B (box otherwise idle, one engine, nothing else running)
The game pins `4.7.2@e64890fd3`; skip the pin for this test build:
```bash
TINQS_ENGINE_SKIP_CHECK=1 GAME_ARGS=--gpu-profile GAME_RES=1600x900 bash tools/game.sh run
READY_TIMEOUT=400 bash tools/game.sh ready
curl -s -X POST 127.0.0.1:4328/command -d '{"command":"host_game"}' # if it stops at the menu
# wait until in the world with fps settled (~50 s+), then:
curl -s -X POST 127.0.0.1:4328/command -d '{"command":"gpucull","value":"replay status"}' # supported True
LOG="$APPDATA/Tinqs/app_userdata/Ariki/logs/godot.log"
OUT=.game-cli/replay-windows-$(date +%Y%m%d-%H%M)
ARIKI_API=http://127.0.0.1:4328 python tools/render_thread_profile.py --log "$LOG" \
--poses tools/render_thread_poses.json --out "$OUT" --blocks 8 \
--states "replay off=gpucull:replay off" "replay on=gpucull:replay on" "replay on 32x8=gpucull:replay on 32 8" \
--restore "gpucull:replay off"
```
Also take three `curl -s 127.0.0.1:4328/mainthread` reads with replay off and with replay on (from `e3582841a`).
They show which thread paces the frame.
Report per pose and state: frame ms, `_draw` wall, `end_frame`, render-CPU labels, fps p25, `/perf
gpucullCounters.parallelReplay` (lists / chunks), pixel diff vs the A/A floor, and the full `results.json`.
## 3. Soak + eye check
`gpucull replay on`, walk 10 minutes (shore, inland, village, a tree felling), with `--gpu-validation` on a second run:
no device lost, no `PARALLEL-REPLAY-BUG`, no validation errors. Eye check where tree/rock shadows fall on open sand.
A stepped shadow edge was seen in one Mac capture and is probably a static-tile boundary; compare replay off vs on
at the same spot.
## Decision rule
Default flips on (`rendering/rendering_device/parallel_draw_replay/enabled=true` in the game's `project.godot`,
then publish + pin) only if: oracle clean, soak clean, and frame time / `end_frame` drop at all 3 poses.