MobileGL/docs/archive/notes/p5e/STRICT-WORKLIST.md

# 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 from `BindCurrentTextures` at `:6719`)** reads
  `GetMaxUniformLocation`, `GetUniformSamplerOrImageUnitIndex`, `GetUniformType` off 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`)** reads
  `GetActiveAttributeLocationMask` and `GetAttribType`. **The code already names this as the
  remaining work and whose it is**: its own comment at `:2258-2268` says "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.