swung0x48
aba329cc53
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.
5.6 KiB
P5e — what is actually left before the strict lane can be a hard gate
Head 7c6f6886. Measured, not assumed: the per-entry marker census is
~/w7/p5e-logs/strict-census/census2.tsv (produced by strict_census2.sh, which runs each red
entry alone against the test binary because ctest swallows MGLOG_F and the log-file knob is read
before the config loader, so the lane's own entries never write one).
1 The census
integration-split is 116/116 green. Under MOBILEGL_IPC_STRICT_ERRORS=1: 7 pass, 109 abort.
| marker | entries | who retires it | verdict |
|---|---|---|---|
GetProgramForDraw@DrawArrays |
61 | P5e | must go |
GetFramebufferBindingSlot@ReadPixels |
21 | P5e row, but a READBACK | allowlist candidate |
GetBoundVertexArray@DrawArrays |
9 | P5e | must go |
GetProgramForDispatch@DispatchCompute |
7 | P5e | must go |
GetTextureObject@CopyImageSubData |
6 | P7 | allowlist candidate |
ValidateProgramName@ShaderStorageBlockBinding |
2 | P9 | allowlist candidate |
GetTextureUnitObject@CopyTexImage2D |
2 | P5e row, but CopyTex | allowlist candidate |
| (none captured) | 1 | — | census artifact, see §4 |
2 The program family (68 of the 109) — and the wire already carries the answer
The important finding: no wire change is needed. MGPipeShaderCsoRecord
(MG_Pipe/PipeApply.h:391) already holds SharedPtr<const ProgramArchive> Archive — the whole of
the frontend's LinkArtifacts plus the SPIR-V, encoded once per link by pg — and the three
post-link mutable tails (BlockBindings, SamplerUnits, StorageOverrides) with a
BindingsSerial. What is missing is not data on the wire; it is readers that still ask the
frontend object instead of the archive.
Three sites, all in MG_Backend/DirectGLES/DirectGLES.cpp:
| site | what it is | state |
|---|---|---|
:6006 PrepareForDraw |
const auto& currentProgram = MGB_CTX->GetProgramForDraw(); — unconditional, no arm test. Merely calling the accessor trips MGP_INPUT_CHECK (MG_Backend/MGPipe/PipeInputs.h:659), so this alone is the per-draw marker. |
the whole fix |
:6746 BindCurrentTextures() (the no-arg overload) |
same accessor, same problem | same fix |
:7374, :7446 |
already behind if (ProgramHandleArm()) — pg did these |
done |
Two genuine consumers keep it alive under the handle arm:
ResolveAndBindUnitTextures(:6090, reached fromBindCurrentTexturesat:6719) readsGetMaxUniformLocation,GetUniformSamplerOrImageUnitIndex,GetUniformTypeoff the frontend program. The memo KEY above it is already handle-only (:6644-6663, ruling ID-86) — it is the miss path that still reads the frontend.SyncCurrentVertexAttributeValues(:2243, called at:6070) readsGetActiveAttributeLocationMaskandGetAttribType. The code already names this as the remaining work and whose it is: its own comment at:2258-2268says "WHAT IS NOT RETIRED HERE, and it is S4/pg's not vi's: the two program reads below … stay until pg carries the attribute mask and types in the ShaderCso record."
So the package is: give both readers a handle arm that answers from record->Archive->Link, then
arm-select the two accessor calls themselves. GetProgramForDispatch@DispatchCompute is the same
shape in PrepareForCompute.
3 GetBoundVertexArray@DrawArrays (9) is confined to multi-draw
All nine entries are MultiDrawScenario.* plus IndexedDrawFamilyScenario.MultiDrawElementsBaseVertexPaintsEverySubDraw.
vi retired the bound-VAO row on the record arm inside SyncCurrentVertexAttributeValues
(:2290, fromRecords ? noVao : MGB_CTX->GetBoundVertexArray()), so this is a DIFFERENT site on
the per-sub-draw path. Find it and give it the same treatment.
4 The one entry with no marker is a census artifact, not a finding
DirectGLES.Split.PersistentMapArm.PersistentCoherentMapScenario.TheMapLandsInTheArmItsLaneDeclares.
The lane prefix PersistentMapArm carries EXTRA ctest ENVIRONMENT (the arm knob) that the
direct-binary re-run did not reproduce, so the entry took a different path. Every entry with a
third name segment (Ct., F1., SmallRing., PersistentMapArm., NamedBlit.) is subject to the
same doubt and its marker must be re-taken under its own lane environment before the table is
trusted.
5 The lane cannot go literally green as the knob is written
CountBarrierPull (MG_Backend/MGPipe/PipeInputs.cpp:98) aborts on EVERY barrier-pulled read when
StrictErrors is set, allowlisted or not. So "GREEN as a hard lane" (BRIEF §3.3) cannot mean
116/116 under the knob unchanged. Either the knob becomes allowlist-aware, or the gate becomes a
marker-set comparison. StrictBarrierPullFatal's why argument already exists for this
purpose — its comment says "the lane's allowlist step reads this line and the two reasons mean
different things to it". Whatever is chosen has to be decided once and mechanised, not kept by hand.
6 The performance target, measured
Monolith at this head, Redmi, MC 26.3-rc-3, ~849 draws/frame, GPU pinned, fan on, 30 s window:
| fps | 254.9 (p50 267.9, min 197.7, max 275.9) |
GL thread Thread-17 |
993.7 ms CPU per second — 99.4% of one core |
| per frame | 3.898 ms |
Monolith is single-thread CPU-bound at 3.9 ms/frame. Parity therefore means
max(client, apply) <= 3.9 ms/frame on the split arm, which is a question about balance and
overhead, not a question about total work: the split may spend MORE total CPU than monolith and
still win, as long as neither thread exceeds monolith's single-thread cost. That is the arithmetic
the optimisation phase has to hit.