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.
6.9 KiB
The symbolized profile, and what run-ahead actually removes
Companion to PERF-BASELINE-7c6f6886.md. This is the number that phase's perf scout said had to be
measured before any optimisation was written, and it is now measured.
Capture: p5d_profile_r3.sh, Redmi 2f7cbe2e, inproc, Minecraft 26.3-rc-3 in world, GPU pinned,
simpleperf record -e cpu-cycles -p <pid> -g --duration 15. 136,856 samples, 73.4 G cycles.
Symbolized against the unstripped libMobileGL.so from
FCL/build/intermediates/merged_native_libs/fordebug/..., not the APK copy.
1 Where the cycles are, by thread
| thread | share of process cycles |
|---|---|
Thread-17 (the client GL thread) |
47.3% |
mgl-srv-apply (the apply thread) |
30.1% |
Server thread (the JVM's) |
9.4% |
C2 CompilerThre |
6.0% |
2 The client thread, inclusive
| inclusive | self | symbol |
|---|---|---|
| 35.56% | 0.41% | ClientSession::EmitAndWaitTails |
| 31.77% | 31.58% | SessionProducer::WaitForAppliedOrEventBacklog |
| 34.42% | 0.15% | EmitIndexedDraw |
| 31.19% | 0.09% | EmitDrawRecord |
| 18.03% | 3.72% | MGPipeValidateForVerb |
| 16.88% | 0.06% | DrawElementsInstancedBaseVertex_Backend |
31.6% of the client GL thread is spent spinning inside the lockstep wait, almost all of it self time — it is the spin, not work reached through the wait.
3 The apply thread, inclusive
| inclusive | self | symbol |
|---|---|---|
| 97.74% | 60.64% | ServerLoop::ApplyThreadMain |
| 36.60% | 0.26% | ServerLoop::DrainRing |
| 34.73% | 0.17% | PipeApplier::ApplyOne |
| 22.13% | 0.48% | ServerVerbSink::OnDrawVbo |
| 14.10% | 0.17% | DirectGLES::PrepareForDraw |
60.6% of the apply thread is self time in ApplyThreadMain — the idle poll waiting for the next
record. Only ~37% is real applying.
4 Run-ahead removes TWO costs on the client, not one
The wait is the obvious one. The second is MGPipeValidateForVerb, and it is worth reading
MG_Impl/Pipe/PipeFill.cpp:3219-3280 to see why:
const Bool runAhead = ClientRunsAhead();
...
const Bool barriered = !runAhead || ClientVerbIsBarriered(verb, ctx);
const Bool fillOwed = barriered;
...
if (fillOwed) { /* the residual fill */ }
Under run-ahead, an unbarriered verb skips the residual fill entirely — gPipeInputs becomes
server-role memory for that record and the client neither fills it, stamps it, nor withdraws the
server's stamp. So the 18.03% is not merely reduced, it is not executed for unbarriered draws.
Today ClientRunsAhead() is false by construction: RunAheadArmed() requires
Caps().HasCap(kCapRunAheadApply), which requires kMGPipeP5eRunAheadReady, which is false until
the integration commit.
5 The arithmetic, and the prediction
Measured client thread cost: 6.1 ms/frame. Of it, EmitAndWaitTails 35.6% and
MGPipeValidateForVerb 18.0% — about 53% of the thread — are what run-ahead removes for
unbarriered records. Barriered records (readback, XFB, CopyTex, set_storage_block_binding per
ruling ID-84) keep both, but in this workload those are a handful per frame against ~849 draws.
| now | predicted after run-ahead | |
|---|---|---|
| client GL thread | 6.1 ms/frame | ~3.0 ms/frame |
| apply thread | 5.3 ms/frame | ~2.0 ms/frame |
| bound by | client | client |
| implied fps | ~164 | ~330 |
| monolith, same session | — | 3.9 – 4.8 ms/frame, 208 – 256 fps |
So the honest prediction is not merely parity but past it. The split arm's remaining client work (frontend tracking plus record encode) is smaller than monolith's whole frame, because the backend GL work has genuinely moved to the other core and the apply thread has ~2 ms of real work against a ~3 ms client.
This is a prediction from a profile, not a measurement of the end state, and it should be treated as such until the flip lands and the four-arm matrix is re-run. The two things that could spoil it:
- The apply thread's 60.6% idle poll is a spin too. If the client stops feeding it in lockstep and starts feeding it in bursts, that poll's behaviour changes and its cost must be re-measured, not assumed to fall proportionally.
- Core placement. In this capture the split client sat on a mid core at 1555 MHz while the
monolith render thread gets cpu7 at 1958 MHz, and the kernel ignores the library's affinity
requests. That is a ~26% clock handicap the split arm pays for reasons outside this phase, and it
is explicitly out of scope by instruction. Compare per-thread CPU ms/frame, which is clock-biased
the same way in both arms only if both land on the same core class — state the core in every
result (
p5d_bench_fcl4.shalready records theprocessorfield per thread).
6 What this means for the order of work
The two asks — "make the strict lane hard green" and "make inproc as fast as monolith" — are one
task. GetProgramForDraw@DrawArrays is read once per draw; a record that reads client memory
cannot be unbarriered; run-ahead cannot be armed until that read is gone. So the strict lane is not a
precondition imposed by process, it is the same work seen from the correctness side.
After the flip, the next target is visible in §2 and is NOT the wait: MGPipeValidateForVerb's
residual 3.72% self plus whatever fill survives for barriered verbs, and the encode path
(EmitIndexedDraw / EmitDrawRecord) which is where the client's remaining ~3 ms lives.
7 The monolith arm, profiled the same way
Same capture recipe, MOBILEGL_TRANSPORT=monolith, 15 s. Its Thread-17 is 62.0% of process cycles
(there is no apply thread to share with).
| inclusive | self | symbol |
|---|---|---|
| 46.35% | 0.24% | DirectGLES::DrawElementsInstancedBaseVertex |
| 30.28% | 0.27% | DirectGLES::PrepareForDraw |
| 15.64% | 1.37% | TextureImpl::SyncNeccessaryTextures |
| 14.45% | 3.44% | MGPipeValidateForVerb |
| 7.02% | 0.88% | BindCurrentProgramWithResources |
| 4.92% | 2.64% | MGPipeFillAccess::CopyField |
The push-monolith arm pays the residual fill too, and that is not a surprise once stated: the
fill is gated on ClientRunsAhead(), which is false on monolith for the same reason it is false on
inproc today, so fillOwed is true and MGPipeValidateForVerb does the full copy. 14.45% of
monolith's thread, ~0.62 ms/frame at its measured 4.3 ms.
This sharpens the comparison rather than muddying it. After the flip, inproc's unbarriered draws stop
paying that cost while the monolith arm keeps paying it, because monolith never arms run-ahead
(ID-81 keeps its frontend arms and kCapRunAheadApply is a transport-side bit). So the projected
end state is:
| client thread ms/frame | |
|---|---|
| monolith (unchanged) | 3.9 – 4.8, including ~0.62 of residual fill |
| inproc after run-ahead (projected) | ~3.0 |
The split arm should end up ahead. Note also what this says about the pull build, which has no fill at all: part of what the push build costs BOTH arms today is machinery that only the split arm will eventually stop paying.