swung0x48/MobileGL
1
0
Fork 0
mirror of https://github.com/MobileGL-Dev/MobileGL synced 2026-11-07 01:53:24 +09:00
Code Issues Packages Projects Releases Wiki Activity

[MG_Test] (Disaggregated): P5e wave 3 - the strict lane's expected-marker set, re-measured on the merge

Browse Source 
The file carried gl's base measurement (7c6f6886, before pa and mv landed) and said so rather than
hiding it. The merge discharged that note exactly as written, and the two-sided ratchet named both
deltas by itself rather than being told:

- GetProgramForDraw@DrawArrays no longer appears - pa retired it, 62 entries to 0, and it was the
  read that fired once per draw and kept every draw barriered. Removed here, in the wave that
  retired it, which is the whole point of the other side of the ratchet: an expected set that keeps
  rows nothing writes any more is how a lane rots green.
- GetBufferBindingSlot@DrawArrays is new, 18 entries, all of them the two indirect multi-draw
  tiers. mv NAMED it as a latent row before it could fire - BoundDrawIndirectBufferId's
  GetBufferBindingSlot(DrawIndirect), which "would surface as GetBufferBindingSlot@DrawArrays if an
  indirect tier were ever forced under strict" - and then gated the five tiers, which forced it.
  It retires in P8 (FieldOwnership.def:78), so it is a debt owed by a later phase and not by this
  one. Added with that reason.

Measured on the integration tree, two independent instruments agreeing (Harness/split_log_paths.py
markers, and a separate per-entry census that drives each entry's own command and ENVIRONMENT from
ctest --show-only=json-v1):

  integration-split      181 / 181 green
  Fatal{UnmigratedPipeInput   0 distinct pairs
  Admitted{                  10 distinct pairs - 8 by the generated table, 2 by escalation

So "the strict lane is hard green" is now a statement a script evaluates, not one a reader argues:
every entry completes, no Fatal marker over the log set ctest itself declares, every Admitted marker
checked against the same table the C++ answers from, and the ratchet fails in BOTH directions.

Gate on this head: build rc=0, unit 2254/2254, integration-split 181/181, integration-gpu 1359/1359,
gens all rc=0, flavours rc=0 (pull 915 TUs push-absent, push 929 TUs push=1).
This commit is contained in:
swung0x48
2026-09-18 12:50:06 -04:00
parent 97a6a46c0d
commit 72bc4268ff
1 changed files with 13 additions and 6 deletions
Download Patch File Download Diff File Expand all files Collapse all files
MobileGL/MG_IntegrationTest/Harness/strict-expected-markers.txt
+13 -6
View File
@@ -20,15 +20,23 @@
# and put the census it prints here.
#
# ---------------------------------------------------------------------------------------------
# MEASURED AT p5e/gl's BASE, 7c6f6886, WHICH IS BEFORE pa AND mv LANDED. That is stated rather
# than hidden: the wave-3 integration commit retires GetProgramForDraw@DrawArrays,
# GetProgramForDispatch@DispatchCompute and the ordinary GetBoundVertexArray@DrawArrays, so the
# three escalated rows below WILL stop appearing and the ratchet will say so by name. Removing
# them is part of that merge, not a failure of it.
# RE-MEASURED ON THE WAVE-3 INTEGRATION TREE (pa + mv + gl merged), 181 lane entries, 181 green,
# ZERO Fatal pairs. The note this block used to carry - that it was measured at gl's base and the
# merge would retire three rows - was discharged exactly as written: the ratchet named
# GetProgramForDraw@DrawArrays as an expected pair that no longer appears, and named
# GetBufferBindingSlot@DrawArrays as one the lane had not seen before. Both are reconciled below.
# GetProgramForDispatch@DispatchCompute never reached this file (pa retired it before it was
# written) and the ordinary GetBoundVertexArray@DrawArrays is gone; the two that remain under that
# name are the client-vertex-array entries, which are escalation-barriered and P8's.
# ---------------------------------------------------------------------------------------------
#
# Admitted by the generated table (disjuncts 1 and 2 of ID-116 / ID-125):
GetBufferBindingSlot@ReadPixels
# NEW IN WAVE 3, and it was named before it could fire: mv's report called
# BoundDrawIndirectBufferId's GetBufferBindingSlot(DrawIndirect) a latent row that "would surface
# as GetBufferBindingSlot@DrawArrays if an indirect tier were ever forced under strict", and then
# gated the five multi-draw tiers, which forced it. Retires in P8 (FieldOwnership.def:78).
GetBufferBindingSlot@DrawArrays
GetFramebufferBindingSlot@ReadPixels
GetProgramObject@ShaderStorageBlockBinding
GetTextureObject@CopyImageSubData
@@ -42,4 +50,3 @@ ValidateProgramName@ShaderStorageBlockBinding
# are NOT the ordinary draw path.
GetBoundVertexArray@DrawArrays
GetBufferBindingPoint@DrawArrays
GetProgramForDraw@DrawArrays