From a7013a8fe1a05efbc7d9651d556278dfd0940f70 Mon Sep 17 00:00:00 2001 From: sylph-decoder Date: Tue, 1 Sep 2026 20:09:34 +0000 Subject: [PATCH] re: the long capture ran and fell 32% short -- sized the next one from measurement Attempted the capture this page named: FRAMES=8000, MAXDRAWS=400000, 700 s. Reached frame 5954, still in the movie, zero UI quads after it. Neither cap fired -- 24 213 draws of a 400 000 cap, 5954 frames of 8000 -- so it ended on the script's wall-clock timeout and nothing about the method is wrong. It needs a longer window, not a different approach. Sized from what this run measured rather than guessed: ~460 presents for the splashes, a 137.714 s movie at 30.000 fps from the disc = 4131 decoded frames, 2 presents per decoded frame measured, so ~8700 presents to clear the movie. This reached 5954, about 68%, at ~22 presents/s armed. So FRAMES=9000 and a timeout of at least 1200 s. Also noting a saving I did not take: the h= content hash reads guest memory for every sampled texture and the movie binds three planes per draw, but the clock-origin measurement needs vertex alpha and not hashes. That field is unconditional in canary-patches/0004; putting it behind its own cvar would make this run materially faster. Co-Authored-By: Claude Opus 5 Claude-Session: https://claude.ai/code/session_01Jc4pciRArGHfxGGhEbwp5t --- .../clock-origin-blocked-boot-has-no-title.md | 37 +++++++++++++++++++ 1 file changed, 37 insertions(+) diff --git a/docs/re/clock-origin-blocked-boot-has-no-title.md b/docs/re/clock-origin-blocked-boot-has-no-title.md index c5328e65..73223d3d 100644 --- a/docs/re/clock-origin-blocked-boot-has-no-title.md +++ b/docs/re/clock-origin-blocked-boot-has-no-title.md @@ -73,6 +73,43 @@ it, which these untapped runs do not. Whether the boot title and the post-movie title are the same screen with the same clock is **not established**, and the origin may differ between them. +## The long capture was RUN, and it is still short — with the numbers to size the next one + +Option 2 above was attempted this iteration: `FRAMES=8000 MAXDRAWS=400000`, 700 s. + +``` +frames captured 0 .. 5954 +last movie luma frame 5954 <- still in the movie at the end +UI quads after it 0 +draws logged 24 213 of a 400 000 cap +``` + +**Neither cap fired.** The run ended on the script's **wall-clock timeout**, not on +frames or draws, so the fix is simply a longer window — nothing about the method +is wrong. + +Sizing it from what this run measured rather than from a guess: + +| | | +|---|---| +| presents consumed by the two splashes | ~460 | +| movie length ⟨disc⟩ | 137.714 s at 30.000 fps = **4 131 decoded frames** | +| presents per decoded frame ⟨capture⟩ | **2** | +| ⇒ presents to the end of the movie | ~**8 260** + 460 ≈ **8 700** | +| reached here | 5 954 (~**68 %**) | +| achieved rate | ~22 presents/s armed | +| ⇒ armed seconds needed | ~**400 s**, plus boot | + +**So: `FRAMES=9000`, timeout ≥ **1200 s**.** 700 s was not enough and 8000 frames +would have been. + +📌 One saving available: the `h=` texture content hash reads guest memory on every +sampled texture and the movie binds three planes per draw. **The clock-origin +measurement needs vertex alpha, not texture hashes**, so a build without that field +would run materially faster. The field is currently unconditional in +`tools/canary-patches/0004`; putting it behind its own cvar is the obvious +improvement and is not done. + ## Reach ⟨capture⟩ ×3, one machine, English locale, `NOTAP=1`, 600 presents. The negative