Files
MobileGL/docs/Disaggregated/notes/p5e/TASK-vi.md
T
swung0x48 aba329cc53 [Docs] (Disaggregated): P6's plan and contract draft; the working notes move from a local directory into the repository
Two things land together: the plan and contract draft P6 needs before it starts, and the
working notes that until now existed on exactly one machine.

1. P6's plan and contract draft (neither started; not one line of code)

     docs/Disaggregated/P6-SPAWN-PLAN.md      the package plan
     docs/Disaggregated/P6-CONTRACT-DRAFT.md  the contract draft (moves to
                                              MG_Remote/CONTRACT-P6.md when c6 lands)

   The three findings that mattered, all written into the documents:

   a. P6 is SMALLER than its roadmap cell suggests. The transport primitives are already in
      the tree and already tested: SocketDoorbell including hangup detection and the two
      lost-wakeup fences (Doorbell.cpp:211-360, four cases in FdPassingTest), SCM_RIGHTS fd
      passing, ShmSegment::Adopt, and the SurfaceOp / WindowKind schema already defined in
      protocol.fbs. inproc uses a real second shm mapping rather than an alias, and
      SessionRings.h:22-28 says that was done so today is not the first time it runs. P6 is
      assembly plus a control plane plus a process, not "write a socket transport".

   b. The evidence for "P6 is only a transport swap" has EXPIRED. It was bought by P5c, whose
      audit found 59 direct memory accesses in a tree that already looked clean. P5e changed
      the tree again. So the first package, a6, is a read-only audit that writes no code, and
      every contract row that depends on it is marked PENDING a6 rather than decided in
      advance.

   c. P6 does not get a game running on the phone. ANativeWindow* is meaningless in the child,
      and protocol.fbs:186-196's own comment says Android transfers the window out of band -
      that band is P12. P6 lands pbuffer / surfaceless / offscreen, which is what HeadlessGL,
      the split-equivalent lane and trace replay need, and which is exactly what P6's own exit
      gate measures. A real window reaching the server is a named refusal. This gets its own
      section because "P6 is done" would otherwise read as "the game runs now".

   The contract adds rule G: a role may not name a process-local handle. It extends P5c's
   rule E (a role may not name the other role's memory) from memory to identity - EGLDisplay /
   EGLSurface / EGLContext / ANativeWindow* / fd number / pid / mapped address either cross as
   a token this contract defines or they do not cross, and a descriptor crosses only through
   SCM_RIGHTS, where the kernel renumbers it.

   What P5e left for P6 gets its own section. The latch semantics are already designed
   (ARCHITECTURE.md:504) and are copied unchanged. What is new is that after run-ahead the
   client no longer waits while the peer process can DIE: the client holds records that were
   published and will never be applied, and Android's freezer suspends the child without
   closing anything. So slow and dead must be distinguishable WITHOUT a timeout threshold.
   That is P6's only new design; everything else is carriage. It shares a predicate with E1's
   outstanding re-specification (ID-122), and the two should be designed together.

   Two gates carried over from P5e's lessons: G2 requires integration-spawn's test-name set to
   match integration-split's name for name, because a differing set means the lane is quietly
   running less; and the arm-proof gate requires every entry to record the child pid and
   transport=spawn in its OWN private log - ID-124 established that this kind of false green
   really happens, and a spawn lane that actually ran monolith would pass every other gate.
   S2's shape must be settled before it is written, and the document says why: E1 is the
   cautionary case.

2. The working notes move into the repository (docs/Disaggregated/notes/, 415 .md files)

   ROADMAP / CURRENT_STAGE_PROGRESS / MEASUREMENTS cite ruling numbers, audit line numbers and
   the provenance of gate figures from ~/w7/notes/, a directory that exists on one machine and
   is under no version control. A record cited hundreds of times that lives only locally is not
   a record, so it moves in whole, with its directory structure intact.

   Only .md moves. Scripts, run logs, census and gate result JSON, patches, APKs and nm dumps
   stay where they are: they are evidence DATA rather than documents - large, regenerated per
   run, and mostly carrying absolute paths and device serials that mean something only on the
   machine that produced them. The mapping and this split are written in
   docs/Disaggregated/notes/README.md.

   Two exceptions are recorded there too: P6's BRIEF has been promoted to a first-class
   document and keeps no copy under notes/, so the two cannot drift apart; and recovered/ holds
   material salvaged from failed workflow runs, which may duplicate the like-named phase
   directories and is kept because a few of those were the only complete version at the time.

   CI's citation lint takes docs/Disaggregated/*.md only (non-recursive), and notes/ is
   deliberately outside it: those notes' file:line citations were written against their own
   code heads, and resolving them against today's HEAD would fail wholesale - which is not an
   error, it is their correct state as a historical record. To check one, use the revision it
   declares (--rev).

3. Inconsistencies fixed in passing

   - README.md's status line still said P5e was in progress while the stage table already said
     closed.
   - CURRENT_STAGE_PROGRESS's next-step item 1 still listed the exit gate as pending, though
     (a) and (b) were run in the previous commit; rewritten to closed plus the one item that
     actually remains (E1).
   - ROADMAP's P6 row still had the pre-phase plan in three of its cells; it now carries the
     package order, the scope boundary and the two new gates.

Checked with check_doc_citations.py: 125 citations across docs/Disaggregated/*.md, 0 problems.
2026-09-18 23:31:39 -04:00

70 lines
4.7 KiB
Markdown

# Package vi — VAO / vertex input / index from records (P5e wave 2)
Read in this order, all of it: `PACKAGE-PREAMBLE-P5E.md`, `INTEGRATOR-DECISIONS-P5E.md` (ID-81,
ID-82, ID-95 are yours), `BRIEF-P5E.md` (§0, §1, §2 "vi", §5, §6 rulings 1, 2, 19),
`CONTRACT-P5E.md` §4 and §5.1 (landed by c0e in `MobileGL/MG_Remote/`; the draft in the notes dir is
the same text), your scout report `scout-S1.md` (all of it), and the VAO / buffer rows of
`kimi-audit.md` (rows 1-34) — your report must say, per row, retired / left barriered / not found.
All notes are in `//wsl.localhost/Arch/home/swung/w7/notes/p5e/`.
Your slug is `vi`; your tree is `~/w7/p5e-vi` (branch `p5e/vi`, based on the landed id head, already
configured and built). The twin resolvers `ResolveVaoTwin(MGPipeHandle)` and the by-handle registry
API are id's and already in your base — use them, do not re-declare.
## What "done" means for this family
On the DirectGLES draw path under an active transport, nothing in the VAO / vertex-input / index
family reads the frontend: the twin resolves from `st.BoundVertexElements`, the attribute walk and
its dirty repair run over `st.VertexBuffers[Start..Start+Count)` and the CSO record's `Attributes[]`,
the IBO arm resolves `st.IndexBuffer.Res`, every buffer ensure is
`EnsureBufferResourceForHandle(nullptr, handle)`, and the clean stamp uses the server-owned
`{elementsHandle, elementsSerial, buffersSerial}` (+ the new `iboSerial`) instead of the VAO's
config version. The three frontend-keyed scope sites of this family (`DirectGLES.cpp:1609, :6729,
:6775` at the P5d base — re-resolve) are gone.
## Scope (the only regions you may edit; anything else is the integrator's)
`MG_Backend/DirectGLES/DirectGLES.cpp`: `SyncVaoAttributeBuffersByHandle` + the IBO arm of
`SyncNeccessaryBuffers`; `ResolveVaoTwin` / `SyncCurrentVAO` / `SyncCurrentVertexAttributeValues`;
the VAO lines of `PrepareForDraw` only; the restart helpers (`BoundElementArrayBuffer`/`...Id`);
the `DrawArrays` / `MultiDrawArrays` client-array arms (monolith-only after your change).
`MG_Backend/DirectGLES/Managers.h`: `ResolvedDrawBuffers` (`Entry::frontend` leaves the split arm,
`iboSerial` added) and `PendingAttribValueMask`'s key. `Managers.cpp`: `SyncToBackendFromApplier`
(signature/entry only — its body is already record-only and is your existence proof),
`SyncClientSideAttributesForDrawArrays` (monolith-only). `MG_Remote/Client/EmitTables.cpp`: the
`kDrawClientArrays` flag and the run-ahead refusal beside the existing `CLIENT_INDICES` refusal.
Tests: `MG_Test/Pipe/VertexInputEmitTest.cpp`, a `SanityTest.cpp` sibling, and the scenario work below.
## Rulings that bind you
- ID-82 / ruling 2: client-memory vertex arrays are **not** refused today (your scout verified it).
Refuse them when run-ahead is armed — `kDrawClientArrays` on the draw record, a named
`Fatal{UnmigratedVerb, "DrawArrays+CLIENT_ARRAYS"}`-shape refusal on the client. Lockstep keeps
today's behaviour exactly. Answer the open question yourself: does any existing scenario
(`DoublePrecisionScenario`?) exercise a client array under split — if none does, add one so the
refusal has a red-once.
- ID-81 / ruling 1: handle arms only under `Transport != Monolith`; the push-monolith build keeps
its frontend arms and its bytes.
- ID-95 / ruling 19: `set_vertex_buffers`' window must cover the attributes the CSO declares; pin it
with a test in the same validate step (a narrower window is `Fatal{ProtocolCorruption, "<row>.Count"}`).
## Red-once (execute each, revert, quote the evidence line in the report)
1. Revert `ResolveVaoTwin` to the frontend lookup → the id guard's `Fatal{RoleViolation, "MGPipeSlots"}`
(use id's test hook to force "unbarriered" — run-ahead is not armed yet).
2. Publish `set_vertex_buffers` for A,B, repoint the frontend VAO at C without re-emitting, sync →
A,B must be ensured; the revert ensures C.
3. The same on `set_index_buffer` / `st.IndexBuffer.Res`.
4. `glDrawArrays` with a client array under the run-ahead flag → the named refusal.
## Gate
`build`, `unit`, `isplit`, `gens` green; `one` on `VertexAttribBindingScenario|VertexArrayEnableDisableScenario|PrimitiveRestartScenario|ResidentIndexScenario|MultiDrawScenario|DrawParametersScenario|HandleRecycleScenario|ObjectSubsystemControlScenario`;
`strict` — record which `UnmigratedPipeInput` markers of this family disappeared vs the c0e baseline
in your report (that list is the phase's progress metric). Also answer, with evidence: does any
GL-thread path bump `CurrentBufferMutationEpoch` under a transport (your scout's open question 2) —
pin the answer with an assertion or a test rather than an argument.
Trailing (do NOT do): deleting `ResolvedDrawBuffers` (needs a measurement first), staging client
arrays (P8).