a4e7c69d7a
Last iteration I proposed that the two sweeps share one indices=8 draw because ptloop01 links to ptloop02, and said testing it needed a loading-screen capture I lack. Wrong twice: a linked pair was already in every capture, ptbtn00 -> ptbtn00f. Measured: ptbtn00f is drawn ALONE in 899 (f6b) and 1441 (f6) draws and batched in ZERO, while the sweeps pair up in 1092 and 1744. Linkage does not batch. The constraint is blend state -- ptbtn00f is additive and its linked partner alpha-over, which cannot share a draw. The sweeps batch because both are additive on one page. Page+blend is necessary but not sufficient: 8154/alpha-over appears as two separate draws in a single frame, 2108 such draws in f6b. This removes a wrong cause rather than supplying a batching rule. Extends read_draws.py to preserve draw grouping (draw index and quad count per draw); check_labels.py still passes unchanged as a regression control. Refutation attempt on the port's 0x3002/0x3003 menu-item reading: survives. 958 of 970 stems contain "btn"; the 12 exceptions are psselect_slot and psselect_slot_blank, which are menu rows. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Jc4pciRArGHfxGGhEbwp5t
2.4 KiB
🔴 Refuted — the sweeps are batched by blend state, not by being linked
Question: are two linked records drawn in the same GPU draw call?
What the human looks at: nothing — this kills a hypothesis of mine before it reaches anything user-visible.
What this does NOT cover: F5's code route, still open.
Instrument: ⟨capture⟩ ×2, read with read_draws.py (now preserving draw
grouping).
The hypothesis, and it was mine
Last iteration I noticed ptloop01 --focus_link--> ptloop02 and suggested that
the two sweeps share one indices=8 draw because they are linked, rather
than because they share a texture page. I recorded it 🟡 with the experiment
named, and said it needed a loading-screen capture I do not have.
That was wrong twice over. A linked pair was already in every capture:
ptbtn00 --> ptbtn00f.
Measured — the linked pair is NEVER batched
ptbtn00f drawn alone |
batched with anything | |
|---|---|---|
f6b |
899 draws | 0 |
f6 |
1441 draws | 0 |
Against the sweeps, which pair up in 1092 and 1744 draws respectively.
So linkage does not cause batching. The constraint is blend state:
ptbtn00f is drawn additive (0x01010101) while its linked partner is
alpha-over (0x07010701), and two different blend states cannot share one draw.
The sweeps batch because they are both additive on one page.
⚠️ Page + blend is necessary, not sufficient. A single settled frame carries
8154/alpha-over as two separate draws (draws 5 and 7), and the census counts
2108 such draws in f6b. Submission order and intervening state changes still
split them; this finding removes a wrong cause, it does not supply a complete
batching rule.
Refutation attempt — the port's 0x3002/0x3003 menu-item reading
Their rule treats that kind as the class menus are built from. I asked whether the class is uniformly menu-row-shaped, disc-wide:
0x3002/0x3003 elements: 970 across 91 name-stems
stems containing "btn": 958 of 970 (98.8%)
the 12 exceptions: psselect_slot (6), psselect_slot_blank (6)
It survives. The only non-btn members are save-slot rows, which are menu
items. Recorded as an attempt that did not land.
Reach
The batching result is about two captures of one screen. It shows linkage is not sufficient and blend state is a hard constraint; it does not establish what else splits a draw.