Last iteration left "is 9.7 fps llvmpipe or something in our draw path" open
after publishing a candidate cause off it. That is not a question to leave open,
so this iteration is the control.
Pre-registered: if the rasteriser is the limit, a near-empty scene in the same
container also runs at 10-25 fps; if our draw path is, it runs far faster, take
>100 fps as the discriminator.
empty 161.6 fps
The engine loop, viewport and present path are not the limit, by 16x over the
menu.
🔴 AND MY FIRST CONTROL WAS NOT A CONTROL. Its fill modes drew UNTEXTURED rects
while every element the port draws is a texture, so it bounded nothing -- and it
showed: the splashes were achieving ~21 Mpx/s against that control's ~50, which
read as the port being mysteriously slow and was the control being mysteriously
fast. With a matched textured mode:
empty 161.6 | fill3 31.5 | tex3 23.9 | fill7 12.7 | tex7 11.2
and every port screen lands inside the bracket, ordered by large-quad count:
publisher (1 quad) 17.3-25.0 ~ tex3; developer (1) 16.7-22.8 ~ tex3; title (6)
12.7-17.2 between; main_menu (5) 9.7 ~ tex7's 11.2. The port draws large
textured alpha quads on a software rasteriser at exactly the rate a software
rasteriser draws them.
⚠️ The control's own spread is 1.75x between runs (fill3 measured 18.0 once and
31.5 once), so the absolute figures are noise-dominated and only the ORDERING and
the BRACKET are load-invariant. That is what the conclusion rests on --
TEMPORAL-VERIFICATION §3, prefer the quantities with no phase.
🔴 SO MY OWN CANDIDATE FOR FINDING 4 IS DOWNGRADED, AND THIS SAYS SO PLAINLY.
Last iteration called the frame rate "the first candidate for finding 4 that is
not already dead". The quantisation argument still holds -- a fade drawn in four
steps is not a fade drawn in fifteen -- but it only bites at these rates, and
these rates are a property of software rasterisation in this container. Five to
seven full-screen quads at 720p is nothing to a GPU. Unless the human ran the
port software-rendered, this is not what they saw, and EVERY candidate for
finding 4 is now dead or near-dead.
Written as a dead end rather than left standing as a lead. Leaving a
plausible-sounding cause up after its own control has undercut it is exactly how
"close but not right" got explained four different wrong ways. The one thing that
would revive it costs the human nothing: the rate line prints on every boot now,
so their next run answers it.
What the port does NOT need, established rather than assumed: no draw-path
optimisation (161.6 fps empty, screens on the fill curve where their quad counts
put them), no texture caching (already at load_screen), no max_fps or vsync
change (would not raise the rate here, and is a presentation decision not a
defect).
Not settled: what rate the human's machine manages -- now the only open half of a
candidate I have otherwise talked myself out of; H6's +0x04 exposure; H1 (with
the Decoder); the four red verify-screen rows.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018AHUQvXGyNcKonSEWsgWcX
4be90c2805