Files
MobileGL/docs/Disaggregated/notes/p5e/TASK-ra2.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

6.4 KiB

TASK-ra2 — make run-ahead actually correct

Read PACKAGE-PREAMBLE-P5E.md and PREAMBLE-ADDENDUM-WAVE3.md first. Your tree is ~/w7/p5e-ra2, branch p5e/flip, head 985ae62d. Your slug for the gate driver is ra2.

Your head already has the flip thrown. Both kMGPipeP5eRunAheadReady (MG_Backend/Init.cpp) and kMGPipeP5eClientWaitRuleLanded (MG_Pipe/PipeApply.h) are true. That is the whole point: everything below reproduces on your head the moment you build it.

1 What is measured, and what it is not

The phase's strict lane is HARD GREEN on the integration branch (72bc4268): 181/181, zero Fatal{, ten Admitted{ rows all owned by later phases. That lane runs under LOCKSTEP, where PipeApplier::ApplyOne stamps every record barriered, so it cannot see anything that only happens once the client stops waiting. It measures remaining debt. It does not measure whether run-ahead is correct. Your package is what measures that.

With the flip thrown, on your head:

gate result
build rc=0
unit 2254/2254
gens all rc=0
flavours rc=0
isplit 112 / 181
gpu 1290 / 1359

The 69-70 failures are flaky: 71 at -j 4, 68 at -j 1, and a single entry run alone passes and then aborts on a repeat (ctest -R '<entry>' --repeat until-fail:12).

A census over all 181 entries, each under its OWN command and ENVIRONMENT taken from ctest --show-only=json-v1 (~/w7/notes/p5e/strict_census3.py, and ~/w7/notes/p5e/catch_flip_abort.py to catch one entry's abort text), gives 70 red on 17 distinct <field>@<verb> pairs over just FOUR fields:

count field
27 GetRenderStateParametersVersion
25 GetTextureContextId
16 GetBufferBindingSlot
2 IsCapabilityEnabled

across eleven verbs: Clear, DrawArrays, DrawElements, DrawElementsBaseVertex, DrawElementsIndirect, DrawElementsInstancedBaseVertex, EndTransformFeedback, GetIntegeri_v, GetSyncStatus, MultiDrawElementsBaseVertex, ReadPixels.

Two populations, and the split matters:

  • 16 abort on the UNBARRIERED arm — the marker carries [BARRIER-PULLED, UNBARRIERED, …].
  • 54 abort with NO [BARRIER-PULLED] bracket at all. That is the plain unfresh-read abort for a field whose ownership is kRecordSupplied — the freshness stamp says it was never filled. Example verbatim: MGPipe: Fatal{UnmigratedPipeInput, "GetTextureContextId@ReadPixels"}.

The census outputs are at ~/w7/p5e-logs/census-flipped/ (per-entry logs plus census3.json).

2 The hypothesis you must TEST, not assume

One field at one verb, consistently, would be a missing migration. Four fields scattered over eleven verbs, flaky run to run, and including verbs that are barriered (ReadPixels, GetSyncStatus) is the signature of a RACE.

The obvious candidate: gPipeInputs is shared mutable state whose mutual exclusion WAS the lockstep. Under run-ahead the client still fills it for BARRIERED verbs (MGPipeValidateForVerb, MG_Impl/Pipe/PipeFill.cpp:3219, fillOwed = barriered) while the apply thread may still be draining EARLIER unbarriered records and reading the same block. The client's fill and the server's MGPipeServerStampVerbBoundary (MG_Backend/MGPipe/PipeInputs.cpp:183) then overlap, and whichever writes FilledGen[] last decides whether the other's read is fresh.

This is consistent with something the project already wrote down: P5d's own research concluded that retiring this barrier needs gPipeInputs versioning or double-buffering, and deferred it to P11 after P3b/P4b's handle-keyed twin tables (see the P11 row in docs/Disaggregated/ROADMAP.md and P5d's report). If that conclusion is right, the honest outcome of your package may be "run-ahead cannot land before that work", and saying so with evidence is a complete and acceptable result.

Do not start from the hypothesis. Start from the failure. Instrument, get a reproducer smaller than a scenario if you can, and establish WHICH writer clobbers WHICH read, with evidence. If the hypothesis is wrong, say what is actually happening.

Two facts that will help you rule things in or out:

  • RefusePipeInputsTouchWhileApplierOwnsIt (MG_Remote/Client/ClientSession) already exists as the guard for exactly this class, and it takes an isBarrieredFill argument. Find out whether it fires, and if it does not, why not.
  • MOBILEGL_IPC_RUN_AHEAD=0 at runtime turns the client's waiting back on with identical server code and identical records (MobileGL/Config.h, the RunAhead comment). That is your A/B control: if a failing entry passes under it on your head, the defect is in the wait rule and not in a record's content. Run it. Do NOT use MOBILEGL_IPC_VERB_BARRIER=0, which is the first conjunct of RunAheadArmed() and turns run-ahead off as a side effect.

3 What to deliver

In order of value:

  1. The diagnosis, with evidence. Which writer, which reader, which field, what the interleaving is. A verbatim reproducer.
  2. The verdict: is this fixable inside P5e, or does it need the gPipeInputs versioning that P5d deferred to P11? Answer with the argument, not with a preference. If the answer is "needs P11", say exactly what P11 has to provide and what the smallest version of it would be.
  3. The fix, if it is P5e-sized. Every arm you add follows ID-81 and ID-110: the arm is decided by MG_Config::Transport or a family selector that reduces to it, STATED not inferred, and a missing record is a named refusal, never a quiet fall-back.
  4. A regression test that fails without the fix. The strict lane cannot catch this class by construction (it runs under lockstep), so whatever you add must run with the flip thrown. Say where it lives and how the gate reaches it.

4 Gate

build · unit · isplit · gpu · gens · flavours, all on your tree, plus the census (strict_census3.py). The bar for "fixed" is isplit 181/181 and gpu 1359/1359 with the flip still thrown, and the census showing no Fatal{ that is not one of the ten admitted rows.

If you cannot reach that bar, report the exact remaining set rather than reverting the flip to make the numbers look green — the flip is the thing under test.

5 Report

~/w7/notes/p5e/reports/ra2-v1.md. Lead with the verdict in §3.2, because that is the decision the integrator has to make. Then the diagnosis with its evidence, then what you changed, then the gate table, then what you did not do and why.