Files
MobileGL/docs
swung0x48 0d747da470 [Docs] (Disaggregated): ROADMAP's P5e row had only its status cell updated; the other three were still the pre-phase plan
The previous commit changed the status cell to "twelve packages landed, run-ahead armed" and
left the scope and exit-gate cells saying eight packages, 19 rulings, "the integration commit
flips kMGPipeP5eRunAheadReady", and an exit gate drafted BEFORE the phase started - several of
whose items later proved unexecutable as written. All three cells are rewritten:

- Scope cell: twelve packages in three waves (including fix1 / pa / mv / gl / ra2), rulings
  ID-80..136, both constants flipped. It also names the largest migration (the per-draw
  GetProgramForDraw) as having changed NO wire structure at all - the record already carried
  the per-link ProgramArchive, and what was missing was a reader that still asked the frontend
  object. Links to P5E-RUNAHEAD.md.
- Exit-gate cell: rewritten into what was actually measured (unit 2256, integration-split
  179/179, integration-gpu 1357/1357, three flavours with each arm asserting its EFFECTIVE
  compile define, strict hard green with zero Fatal, the device at VD32 level with monolith and
  +69% p50 against lockstep), plus what has not been executed (the three negative controls, the
  per-package red-once reruns, E1's control failing its own self-check, G1 still asserted by
  CI), plus the criteria that are now VOID (rsp = 0 is empty by construction, rewritten by
  ID-119; VERB_BARRIER=0 may not serve as the paired control, ID-114, because it also disarms
  run-ahead).
- Debt table, rsp row: P5e rewrote what that number means. It now reads as the hard-green lane
  plus eight Admitted rows, and says why the original criterion was empty - CountBarrierPull's
  unbarriered arm sits before ++g_residualPulls and is [[noreturn]].
- Debt table, unmigrated row: client vertex arrays are a named refusal under run-ahead
  (ID-82) and have their own expected-red lane, integration-clientarrays-split (ID-134);
  staging stays P8's.
- Open question 18 added: the two sides of split are unbalanced (at VD32, apply 11-12 ms
  against client 15.7 ms, with the client ~94% saturated). Moving work from client to apply
  lowers the bottleneck directly - meaningless under lockstep, where the two add serially, and
  a lever only because of run-ahead. It needs a fresh profile first: with the wait gone, every
  tail item's denominator has changed.
- The header status line gains the P5E-RUNAHEAD.md link.

Doc citation check: seven files under docs/Disaggregated, 58 citations, 0 problems.
2026-09-18 21:35:38 -04:00
..