Skip to content

t27f: token_floor renders in 48 shards; frames cached by the seal (Closes #10383) - #10384

Merged
gHashTag merged 1 commit into
masterfrom
claude/tf-render-cache-shards
Oct 18, 2026
Merged

gHashTag merged 1 commit into
masterfrom
claude/tf-render-cache-shards

Conversation

@gHashTag

Copy link
Copy Markdown
Owner

Closes #10383

The token_floor reel took 52 s to render on one of the lab's 48 cores, and every caption, voice or music edit paid that cost again.

What changed

  • specs/t27f/token_floor.t27, frame shards.
    • main renders shard k of N, read from TF_SHARD and TF_SHARDS. Shard k covers the frames [shard_a(k, N), shard_b(k, N)).
    • Frame f's state is the integral from frame 0, so every shard steps the physics from frame 0 and skips only the splats and the raster before its range.
    • With the variables unset, or with an invalid k or N, the whole reel is rendered, never an empty or partial one.
    • The four new tests prove:
      • the shards tile [0, FRAMES) in order, with no gap or overlap, for every N from 1 to 64;
      • 48 shards are 9 or 10 frames each, and 450 shards are 1 frame each;
      • the env parser falls back on bad input;
      • an invalid shard renders the whole reel.
    • getenv is reached only from main, so the test runner never needs libc. The binary is built with -lc.
  • New specs/t27f/frame_cache.t27, the cache key of the rendered frames.
    • Input:
      • the .trinity/seals/t27f_token_floor.json seal;
      • sha256sum lines for the specs;
      • the t27c binary's sha256, zig version and the build flags.
    • Output: a canonical key record. The lab names the cache file /root/tf/cache/<sha256 of the record>.rgb.
    • The spec and every closure spec must still hash to the sealed digest. t27c seal --verify checks only the spec, not its closure.
    • The key is refused, which counts as a miss and stores nothing, if any of these hold:
      • there is no seal;
      • a header line is missing;
      • the seal has no closure;
      • the seal records a failed test;
      • a sealed file is missing;
      • a digest has changed.
    • token_floor_mux.t27 is not in the closure, so caption and mux edits keep the key.
    • It lowers under gen-c, so the lab runs it as a C filter through a one-line main, the same idiom as the lefthook and claw-sarif jobs.
  • The seals. token_floor is resealed at 24/24 tests and frame_cache is new at 8/8.

Measured on the Railway lab

The lab has 48 cores, -O ReleaseSafe -lc and zig 0.16.0. Other jobs kept its load average around 50 during these runs.

run time frames sha256
one process (old path) 54.0 s 7e0c6662ddbf84a0a424c0aa119420eb34f90b0decec6e0c05753b2d37391e07
48 shards, wall time 3.43 s 7e0c6662... (48 files concatenated)
cold run: key 2.4 s + gen and build 19.4 s + 48 shards and concat 5.2 s + mux 16.4 s 43.4 s 7e0c6662...
cache hit: key 2.2 s + mux 23.6 s 25.7 s 7e0c6662... (read from /root/tf/cache)
  • Byte-identical output.
    • Concatenating the shards gives the one-process output byte for byte.
    • The -lc build gives the same frames as the earlier build without it.
    • The reel muxed from cached frames is the v5 file byte for byte (mp4 sha256 a18389ed...).
  • Before this change, a caption edit cost the 52 s render plus the mux; it now costs only the 2.2 s key plus the mux.
  • The refusal path was exercised live. Before resealing, the filter answered refused: the spec changed since the seal and exited 1.

Per-spec test reports on the lab:

  • token_floor: 24 tests, 24 passing, 0 vacuous.
  • frame_cache: 8 tests, 8 passing, 0 vacuous.

Not in this PR

  • The raster loops over all of about 42k splats for each of 1920 rows per frame. Bucketing splats by row would cut the single-core cost itself.
  • The lab plumbing (/root/tf/k/reel.sh) is not committed; it stays on the lab.

🤖 Generated with Claude Code

…oses #10383)

- token_floor main renders shard k of N (TF_SHARD, TF_SHARDS). The physics steps from frame 0,
  and only the splats and the raster before the range are skipped. The partition is tested to
  tile [0, FRAMES) for every N from 1 to 64; bad input renders the whole reel.
- New specs/t27f/frame_cache.t27 derives the frames' cache key from the token_floor seal.
  Each sealed digest (the spec and its closure) is checked against sha256sum now, and the key
  adds the t27c binary, zig and the build flags. A stale seal, failed tests or a missing part
  refuse the key, which means a miss. It lowers under gen-c, so the lab runs it as a C filter.
- Lab: 48 shards in 3.43 s versus 54.0 s in one process. Both give sha256 7e0c6662 byte for
  byte, and the muxed reel is the v5 file (a18389ed). Tests: token_floor 24/24, frame_cache
  8/8, 0 vacuous.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@github-actions

Copy link
Copy Markdown
Contributor

PR Dashboard

Generated at: 2026-10-18 10:39:41 UTC

Summary

Status Count
Total Open PRs 50
PRs with Failing Checks 49
PRs with All Checks Green 1
READY 0
FAILING 49
PENDING 0
NO CHECKS YET 0

These columns do not partition: 0 + 49 + 0 + 0 = 49, and there are 50 open PRs. A PR is being counted twice or not at all.

Seal Status

  • ⚠️ STALE -- sha256(compiler.rs)=fad12492937a != manifest seal=87e5cbd3ad94.
    The committed NMSE numbers were certified against an older compiler.rs.
    Run scripts/reseal-check.sh locally for the two-step reseal command (advisory; not a merge gate).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

t27f: cache token_floor frames by the seal and render them in 48 shards

1 participant