Files
xenia-rs/crates/xenia-app/tests/golden
MechaCat02 acb29db444 [iterate-3AL] Superblock dispatch: chain basic blocks per slot-visit (~1.6x boot-to-splash)
Replace the one-basic-block-per-slot-per-round lockstep dispatch with a
SUPERBLOCK runner: each slot-visit chains straight-line blocks through
their terminating branches up to a deterministic instruction budget,
amortizing the per-round (timebase/coord/round_schedule) and per-slot
(worker_prologue) dispatch tax over ~128 instructions instead of ~6.

Yield-points (end the chain, return to the round) are pure functions of
guest state, preserving the lockstep cross-thread interleaving correctness:
  - non-Continue step result (Yield/SystemCall/Trap/Unimpl/Halted);
    db16cyc Yield is the spin-wait producer hand-off.
  - sync-sensitive block: lwarx/ldarx/stwcx./stdcx. or sync/eieio/isync
    (new PpcOpcode::is_sync_sensitive, flagged on DecodedBlock at build).
  - MMIO touch: new GuestMemory::mmio_access_count() watermark, sampled
    per block, keeps GPU/register ordering at one-block granularity.
  - next PC leaves ordinary guest code (import thunk / halt sentinel /
    unmapped) -> hand to the full worker_prologue next round.
  - instruction budget reached.

Instruction-count/clock accounting stays exact: per-block cycle_count
deltas are summed and handed to worker_epilogue once (instruction_count +
decrement_quantum advance by the precise retired count). XENIA_SUPERBLOCK_BUDGET=1
reproduces the old one-block schedule byte-for-byte.

Budget tuned to 128 (env-overridable): boot progression stays healthy up
to 256, sharp cliff at ~384 (a boot producer/consumer handoff starves);
128 is 3x below the cliff. Also scale the inline-GPU per-round fairness
cap with the budget (flat 64 throttled GPU command processing 17x under
superblocks and collapsed the present loop).

PERF (check -n 100M --gpu-inline): 25.3 -> 42.7 MIPS (1.69x); 1B: 26.0 ->
41.4 MIPS (1.59x). Callgrind n=5M: host instructions 2.178B -> 1.507B
(-31%); worker_prologue -90%, coord_pre_round -91%, begin_slot_visit /
round_schedule_into / coord_post_round / update_timestamp_bundle each
~-90%; interpreter execute byte-identical (real work unchanged).

GATES: C1 boot progression 150M draws 7391/swaps 2164 (baseline 7415/2172),
1B draws 88547/swaps 29228 linear no stall, K8888 decode + RTs=2 intact.
C2 determinism: n50m stable digest byte-identical across fresh runs;
golden re-baselined intentionally (pacing-only deltas: imports 333453->243387,
draws 1274->1279). C3 milestone-1 render: texture_decodes/draws/swaps/
present cadence track baseline (3AJ fade-in pacing preserved). C4: 690
tests green (+2 sync_sensitive).

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-06-19 22:31:54 +02:00
..

Sylpheed regression goldens

These JSON files anchor xenia-rs check digest output for Project Sylpheed.

Files

File -n Mode Captures
sylpheed_n2m.json 2_000_000 full digest early boot (swaps=0, no rendering)
sylpheed_n50m.json 50_000_000 stable-digest first VdSwap pair (swaps=2 post-Phase-A)

Stable-digest mode

sylpheed_n50m.json is captured with --stable-digest, which omits timing-sensitive counters: packets (±28% lockstep noise from a GPU thread race), resolves, interrupts_delivered, interrupts_dropped, texture_decodes. The remaining fields are byte-identical across repeated lockstep runs at a fixed -n.

sylpheed_n2m.json predates the stable-digest flag and uses full-digest compare. It still works because at -n 2M the GPU pipeline has not produced any packets yet — packets=0 is trivially deterministic.

Circularity hazard

Per ORACBUG-001/002/003, these goldens were captured by running the same code they validate. They detect regression from a known-good snapshot, not correctness. When a planned fix intentionally moves the digest (e.g. a shader fix landing draws > 0 for the first time), re-baseline the golden as a separate commit and reference the audit ID in the message.

Re-baselining

cargo build --release -p xenia-app
target/release/xenia-rs check \
    "$SYLPHEED_ISO" \
    -n 50000000 \
    --stable-digest \
    --out crates/xenia-app/tests/golden/sylpheed_n50m.json

Running the goldens

cargo test --release -p xenia-app --test sylpheed_oracles -- --ignored --nocapture

The tests are #[ignore]-gated because each run takes a few seconds, which is unacceptable in the default cargo test cycle. The ISO path defaults to the contributor's local ~/RE Project Sylpheed/Project Sylpheed*.iso and can be overridden via SYLPHEED_ISO=/path/to/sylpheed.iso.

n4b canonical-invocation regression anchor (deferred)

The audit's recommended next sprint also called for a sylpheed_n4b.json golden capturing the canonical reference invocation xenia-rs check sylpheed.iso -n 4_000_000_000 --parallel --reservations-table. This is deferred because:

  1. The --parallel --reservations-table combination is empirically pathologically slow at -n 100M (>32 min per run per the audit memory). At -n 4B the run cost is many hours, not the single-session-friendly 515 min the original plan estimated.
  2. Each phase that intentionally moves rendering counters (C, D, E, F) would need a re-baseline of n4b — a significant time cost compounding over the sprint.

Once the renderer-unblock phases (C+D+E) land and draws > 0 is confirmed at -n 100M lockstep, an n4b artifact may be captured one-shot and stored under audit-runs/post-fix/ (not as a test golden) as a manual regression anchor for the canonical invocation.