56ae05a18b
The experiment guest-frame-rate-WITHDRAWN.md named. A triple buffer rotating once per present visits the same three base addresses whether or not anything was decoded into them, so base identity cannot separate "decode per present" (30 fps guest, 60 units/s) from "rotate per present" (60 fps guest, 120 units/s). A content hash can. command_processor.cc now emits h=<FNV-1a over 4096 sampled bytes> beside every sampled texture, omitted rather than faked when the address does not translate, so a missing hash cannot read as a matching one. Incremental build, one translation unit. Predictions committed before the capture: consecutive presents with changed luma content is ~1.00 under decode-per-present and ~0.50 under rotate-per-present, with acceptance bands and "neither" reported rather than rounded. The control is the part I got wrong last time. A STATIC texture must hash constant: the splash sprite page 0x11A50000 is a fixed atlas, and if its hash varies between presents then reading guest memory at draw time races the decoder and nothing in the log may be read. That fails loudly in the direction which would otherwise manufacture the answer I previously reached -- the property my last control lacked. A second control in the other direction requires the movie luma hash NOT to be constant, which would mean hashing the wrong bytes and would manufacture the opposite answer. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Jc4pciRArGHfxGGhEbwp5t
3.3 KiB
Pre-registration — did the guest DECODE a frame, or just ROTATE a buffer?
Written and committed BEFORE the capture. 2026-09-01. This is the experiment
named by guest-frame-rate-WITHDRAWN.md as the
one that settles what that page withdrew.
Why this exists
I measured "one movie luma base address change per present", read it as one decode per present, and concluded 30 fps / 60 units/s. That was withdrawn: a triple buffer rotating once per present visits the same three addresses whether or not anything was decoded into them, so base identity cannot separate:
- D — decode per present. The guest decodes a new movie frame every present.
With
ADV.wmvauthored at 30.000 fps, the guest presents at 30 fps ⇒ 60 units/s ⇒ the plate'st = 236is 3.93 s. - R — rotate per present. The guest presents twice per decoded frame. Then it presents at 60 fps ⇒ 120 units/s ⇒ the plate is at 1.97 s and the port is ~2 s late, which is the size of the play-test complaint.
The instrument
The draw logger now emits a content hash beside every sampled texture —
FNV-1a over 4096 bytes spread across the allocation, h= omitted rather than
faked when the address does not translate, so a missing hash can never read as a
matching one. Built and linked; command_processor.cc only.
🔴 The predictions, stated now
Over consecutive presents during attract-movie playback, the fraction of pairs whose luma content hash differs:
| fraction of consecutive presents with changed luma content | |
|---|---|
| D — decode per present ⇒ 60 units/s | ≈ 1.00 |
| R — rotate per present ⇒ 120 units/s | ≈ 0.50 |
I will accept D within 1.00 −0.10 and R within 0.50 ± 0.10, and report
"neither" otherwise rather than taking the closer. Under R I additionally expect
the repeat pattern to be period-2 — each hash appearing on exactly two adjacent
presents — and I will report the run-length distribution, not just the fraction.
🔴 The control, and this time it tests the thing the last one did not
A static texture must hash constant. The splash sprite page 0x11A50000
(1280×768) is a fixed atlas: it is uploaded once and sampled for both splashes.
If its hash varies between presents, the hash is unstable — reading raw guest
memory at draw time can race the decoder — and nothing else in the log may be
read. This control fails loudly in the direction that would otherwise
manufacture the D result, which is exactly the property my previous control
lacked.
Second control, the other direction: the movie's luma hash must not be constant across the whole movie region either. A hash that never changes would mean I am hashing the wrong bytes, and would manufacture R.
What would still not be settled
Whether Canary's presentation cadence equals a real console's. This measures what the guest does here. The vblank-interval evidence (one vblank 71.7 %, two 24.6 %) is consistent with R and is what motivated re-opening this, but it is host time and cannot stand alone.
⚠️ And a third possibility the two hypotheses do not cover: the guest may decode at a rate unrelated to both, in which case the fraction lands between the bands and the honest answer is "neither", with the movie ruler abandoned rather than stretched to fit.