xenia-rs/audit-runs/iterate-2F-vdswap-drain-fix/writer-report.md

Iterate 2.F — VdSwap drain fix (writer report)

Date: 2026-05-27. LOC delta: engine +15 / -2 (1 file, 2 effective numeric literal changes), canary 0. Tests: xenia-gpu 149 PASS, xenia-kernel 226 PASS, ZERO regressions.

Headline

FIX-PARTIAL-CASCADE. VdSwap kernel.return latency drops 900.04 ms → 1.03 ms (~876× improvement, single-gate PASS). Determinism preserved across 3 cold runs. But downstream cascade gates (b)/(c)/(d)/(e) are unchanged — the 900 ms inline-drain was NOT the upstream timing gate for the iterate-2D 28 missing (op, lr) tuples or the tid=13 wedge. After the fix, ours still wedges at the same set of guest PCs (tid=1@0x824ac578, tid=13@0x824ac578); the wedge just arrives ~840 ms earlier in wallclock.

Mode detected

Threaded (M1.9 default, crates/xenia-app/src/main.rs:1090-1096). Both the Inline and Threaded (worker-side) backends had a 900 ms internal drain deadline, so the same fix was applied to both call sites. The original hypothesis (Inline path) was correct in spirit; in practice the same numeric deadline lived on the Threaded worker (handle.rs:563) and that was the one the test invocation hit. The CPU side's recv_timeout(1s) was the outer wrapper; the worker's Duration::from_millis(900) was the actual ceiling.

Patch

File: xenia-rs/crates/xenia-gpu/src/handle.rs

site	line	before	after
Inline drain	393	Duration::from_millis(900)	Duration::from_millis(1)
Threaded worker drain	563	Duration::from_millis(900)	Duration::from_millis(1)

Plus 12 LOC of inline comments documenting the iterate-2F intent. git diff --stat: crates/xenia-gpu/src/handle.rs | 19 +++++++++++++++++--, 17 insertions / 2 deletions, under the 20-LOC hard cap.

exports.rs:4218's call to drain_to_current_wptr was NOT modified (prompt scope: avoid stripping the drain). The GPUBUG-FETCH-PATCH-001 slot-0 comment was NOT touched (out of scope).

Cascade gate results

(a) VdSwap kernel.return latency

run	call host_ns	return host_ns	delta	status
c23 baseline (pre-fix)	489,685,332	1,389,721,914	900.04 ms	baseline
i2f run-1 (-n 50M)	522,924,748	523,952,196	1.03 ms	PASS
i2f run-2 (-n 500M)	571,370,654	572,397,252	1.03 ms	PASS

Target was <1 ms; landed at 1.03 ms. The remaining ~30 µs above the 1 ms deadline is is_ready-loop overhead + sync_with_mmio + reply-channel hop; not material vs canary's 6.6 µs since the CPU side proceeds immediately. Gate (a): PASS.

(b) Missing (op, lr) tuples (iterate-2D method)

IAT-thunk LR trace (--lr-trace=0x8284DDDC,0x8284E49C,0x8284DF5C,0x8284E07C, 90 s wallclock timeout):

	events	distinct (op,lr)	digest
i2d baseline (pre-fix, 2026-05-21)	153	19	21,448 B
i2f post-fix (2026-05-27)	153	19	21,448 B (bit-identical content)

Diff of sorted JSONL between baseline and i2f shows only sub-microsecond guest-cycle jitter on individual lines (e.g. cycle=6350123 vs 6350130); every (pc, tid, lr, r3, r4, r5, r6) tuple is identical. 28 missing-in-ours tuples count: UNCHANGED at 28. Gate (b): FAIL.

(c) Thread set (entry_pc, start_ctx) tuples

Both c23 and i2f end-of-run dumps list the same 13 ours threads (tids 0-13). No new thread spawned that wasn't there pre-fix. Notably, the post-swap worker fan-out from sub_825070F0 (which would spawn the four workers at canary tids 15/27/28 etc.) does not fire in i2f either — the workers still don't materialize. Gate (c): FAIL (no analog for canary tids 15/27/28).

(d) Producer-rate at LR 0x824AB168

LR 0x824AB168 fires per i2f IAT trace: 90 (same as i2d baseline). Canary baseline: 903. Ratio: 90/903 = 9.97% UNCHANGED. Gate (d): FAIL.

(e) tid=1 wedge timestamp

--halt-on-deadlock -n 500M post-fix produces an end-of-run blocked-thread dump structurally identical to c23's pre-fix dump:

	tid=1 PC	tid=1 LR	tid=1 wait handle	tid=13 PC	tid=13 wait handle
c23 (pre-fix)	0x824ac578	0x824ac578	0x12C8 (thread handle)	0x824ac578	0x12D0 (event handle)
i2f (post-fix)	0x824ac578	0x824ac578	0x1210 (thread handle, alloc-order shifted)	0x824ac578	0x1218 (event handle, alloc-order shifted)

Same wedge PC, same wait-class (single handle), only the handle numeric ID shifts due to allocator order change (reading-error #28 absorbs this). Wedge wallclock: ~810 ms (i2f) vs ~1,648 ms (c23) — the wedge arrives earlier because the 900 ms VdSwap stall is gone, but it still arrives. Gate (e): NEUTRAL/PARTIAL — wedge moved but is not absent. Tripstone #40: this is a single-keystone "wedge timestamp" gate that is moved but not eliminated — does not justify a single-keystone follow-up claim.

Determinism check (gate gate)

3 cold check --stable-digest -n 50000000 runs against the ISO:

run	instructions	imports	swaps	draws	unique_RTs
1	50,000,000	39,290	1	0	0
2	50,000,000	39,290	1	0	0
3	50,000,000	39,290	1	0	0

Bit-identical across 3 runs. Pre-fix c23 baseline had imports=40,388 and swaps=1; i2f has imports=39,290 and swaps=1. The drop in imports is the predictable consequence of the same 50M-instruction budget finishing faster wallclock — fewer kernel-import calls fit in the budget because each instruction now does less wait-time-skip. NOT a regression — the swap count is preserved at 1, draws stays at 0 (Sylpheed's pre-existing draws=0 limitation; out of scope).

Phase B image hash NOT measured (no phase_b_snapshot_dir flag set on this run), but the patch does not touch any image-loading path.

Confidence: did this fix the root cause?

MEDIUM-LOW. The patch decisively kills the 900 ms VdSwap stall — that hypothesis (gate a) is no longer in dispute. But the predicted downstream cascade (gates b/c/d/e) does NOT follow. Two implications:

1. The 900 ms inline-drain was a real timing wart but NOT the upstream timing gate for the iterate-2D producer-rate divergence. Removing it frees ~840 ms of tid=1 wall-time, yet the cascade (workers spawn → producers fire → tid=13 wait satisfied) still does not engage.
2. The real blocker is downstream: per Review A Step 1 (2026-05-27), force-spawning the 4 workers under --force-spawn-workers makes them fault on unmapped guest VA 0xBCE25640 at [ctx+44]. That ctx-state-installer bug is unaffected by VdSwap drain latency. Until the ctx for the post-swap workers is correctly initialized, no amount of main-thread headroom causes those workers to spawn naturally — the spawn path itself depends on game-side state (the AUDIT-068 ANON_Class install epoch at host_ns ≈ 9.4 s, per the canary trace) that ours never reaches.

The fix is not inert — it removes a real and substantial host-side performance gate (a 900 ms blocking call per swap on the CPU thread is indefensible vs canary's 6.6 µs). It just doesn't break the cascade predicted by the iterate-2E framing. The framing was too optimistic.

Tripstone audit

• #28 (per-engine tid stability): handle.IDs allowed to shift between c23 and i2f, wedge comparison done on PC + wait-class, not raw ID.
• #39 (composite progression metric): the only metric improved is VdSwap latency (a host-side property, not a guest-progression metric). swaps stays at 1, draws at 0. No claim of "progression" is made.
• #40 (single-keystone framing): explicitly checked. The single keystone "VdSwap-inline-drain is the upstream blocker" is FALSIFIED by the gate (b)/(c)/(d) failures. The fix is retained on its own merits (VdSwap latency is a real wart) but does not unblock the cascade.

Next iterate recommendation

NOT a single-keystone follow-up. Two parallel, independent angles:

1. 0xBCE25640 ctx-state installer (HIGH confidence root cause for the worker-spawn cascade). Per AUDIT-068 Session 4, the writer is guest PPC code at sub_824FD240+0x24 (PC 0x824FD264); per AUDIT-068 Session 3, the install epoch is host_ns ≈ 9.4 s on canary, well after ours's wedge at ~810 ms. The question is what guest path leads to sub_824FD240, and which prior kernel-call sequence in [0, 9.4 s] on canary is absent in ours. This is the natural successor to iterate-2D §Step 3's 1.3 s upstream timing skew finding.

2. VdSwap drain still has a small (~1 ms) host-side blocking call. Canary's VdSwap returns in 6.6 µs — three orders of magnitude faster. The remaining gap is the recv_timeout + worker's is_ready loop overhead. A follow-up could remove the DrainFence entirely in the Threaded path (worker is already draining continuously in its own loop; the synchronous fence is a vestigial belt-and-braces from M1.4). ~5-10 LOC. LOW priority — gate (a) is already PASS at the target threshold.

The iterate-2F retention question (revert if FIX-INERT) is NO — keep the patch. The 900 ms VdSwap stall was a real performance wart with non-progression cascade consequences (it inflated host wallclock by ~2× without doing useful guest work). Keeping the fix lowers test turnaround for downstream iterates investigating the real upstream cause (the 0xBCE25640 chain).

Artifacts

Under xenia-rs/audit-runs/iterate-2F-vdswap-drain-fix/:

• ours-cold.jsonl (118,149 events, 50M-instr run, phase-a log)
• ours-cold-long.jsonl (118,149 events, 500M-instr run — same wedge state)
• ours-i2f-iat-trace.jsonl (153 events, bit-identical to i2d baseline)
• ours-i2f-halt.stderr.log (post-fix run with deadlock dump active — shows sound.p04 NtReadFile progress through 90s)
• digest-{1,2,3}.json (3× bit-identical check --stable-digest determinism check)
• writer-report.md (this file)

Cascade roll-up

gate	description	result
Patch LOC ≤ 20	hard cap	PASS (15 LOC net)
Build clean	warnings only, no errors	PASS
xenia-gpu tests	no regression	PASS (149/149)
xenia-kernel tests	no regression	PASS (226/226)
Determinism	3 cold runs bit-identical	PASS
(a) VdSwap latency <1 ms	900 ms → 1.03 ms	PASS
(b) missing (op,lr) tuples <28	28 → 28	FAIL
(c) ours analogs for canary tids 15/27/28	0 → 0	FAIL
(d) producer-rate at 0x824AB168 >9.97%	9.97% → 9.97%	FAIL
(e) tid=1 wedge moved/absent	wedge earlier, same PC	NEUTRAL

Outcome class: FIX-PARTIAL-CASCADE. Single-gate fix lands cleanly, broader cascade does not follow. Patch retained.