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.
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 iskRecordSupplied— 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 anisBarrieredFillargument. Find out whether it fires, and if it does not, why not.MOBILEGL_IPC_RUN_AHEAD=0at runtime turns the client's waiting back on with identical server code and identical records (MobileGL/Config.h, theRunAheadcomment). 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 useMOBILEGL_IPC_VERB_BARRIER=0, which is the first conjunct ofRunAheadArmed()and turns run-ahead off as a side effect.
3 What to deliver
In order of value:
- The diagnosis, with evidence. Which writer, which reader, which field, what the interleaving is. A verbatim reproducer.
- The verdict: is this fixable inside P5e, or does it need the
gPipeInputsversioning 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. - The fix, if it is P5e-sized. Every arm you add follows ID-81 and ID-110: the arm is decided
by
MG_Config::Transportor a family selector that reduces to it, STATED not inferred, and a missing record is a named refusal, never a quiet fall-back. - 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.