MobileGL/docs/archive/notes/p10/INTEGRATOR-DECISIONS-P10.md

P10 集成者裁定日志（sync / query / present 节奏）

形式沿用 ../p9/INTEGRATOR-DECISIONS-P9.md：一条裁定一个 ID，只记「定了什么、为什么、影响哪些文件」。计划与范围重划见 PLAN-P10.md，协议见 MobileGL/MG_Remote/CONTRACT-P10.md。

ID	日期	裁定	理由	影响
ID-P10-1	2026-09-29	范围按计划 §1 重划：client 铸造 query handle、present 1:1、credit 默认 1 已是现状，关闭；"DirectGLES fence 逐 fence 退休"与"非 present fence tick"不单独做——线上不依赖帧水位（每批后 RetireThrough(appliedSeq)），帧水位只喂 Espryt 自己的 buffer 池回收，与 monolith 相同；A 的"空闲时也查 fence"就是线上的非 present tick。	路线图行写于 09-22，逐项对照树的现状核对过。	PLAN-P10.md
ID-P10-2	2026-09-29	A 的形状：server 按创建顺序查 fence，完成的发 kEventFenceSignaled（EventKind 追加 5，8 字节）；client 已知 signaled 的轮询本地作答，不能等的未知轮询本地答"未完成"，同一 fence 连续第 MOBILEGL_IPC_POLL_ESCALATE（默认 64）次改为一次往返；可以等的调用（timeout > 0）仍然往返，语义不变。旋钮为 0 就恢复 P10 之前的行为，作 A/B 控制；设备丢失后一律走往返臂。	本地作答只用 server 说过的事实，所以不会早报；升级保证"只轮询不发记录"的循环有界。timed wait 本地等报告需要另一套唤醒路径，往返本身就是那次等待。	EventRing.h、ServerSession.{h,cpp}、PipeApplier.{h,cpp}、ServerLoop.cpp、ClientSession.{h,cpp}、EmitTables.{h,cpp}、Config.h、ConfigLoader.cpp
ID-P10-3	2026-09-29	client 记"已 signaled"的表用独立互斥锁，不用 g_fenceMutex。	事件排空发生在持有 g_fenceMutex 的发射函数内部（EmitAndWait、PollEntry 都排空），用同一把锁会让 GL 线程自锁。	EmitTables.cpp
ID-P10-4	2026-09-29	server 将要空闲且有未报告 fence 时：对最老的 pending fence 做一次 ClientWaitSync(GL_SYNC_FLUSH_COMMANDS_BIT, 0)（两个后端都会借此提交所持命令的唯一后端无关方式），仍有未报告的就限时停车 1 ms 再查；否则照旧无限期停车。SEG_EVENT 满时不报告。	red-once：去掉空闲复查 → Espryt 需 1 次升级，Magma 升级 15 次仍等不到（Magma 的 fence 不会自己提交）。每批都提交会打掉 Magma 的命令缓冲批处理，所以只在空闲时做。	ServerLoop.cpp、PipeApplier.cpp
ID-P10-5	2026-09-29	OnPresent 在归还 present credit 之前报告一次（状态查询，不提交）。	credit 放行的 client 会立刻去等一两帧前的 fence；批次结束后才发的报告会输给它。实测只在 Espryt·tcp 有变化（本地作答 36–54 → 79–101 / 598）。	PipeApplier.cpp、ServerSession.{h,cpp}（EventRingHasRoom）
ID-P10-6	2026-09-29	主机 Espryt 上 A 没有收益：在 mesa llvmpipe（ES 3.2）上 glGetSynciv 与零超时 glClientWaitSync 看不到早已完成的 fence，只有阻塞等待才能让它变成 signaled。另外试了三种做法——空闲 / present 时冲刷最新的 fence、present 时 flush 检查、1 ns 的 timed wait——都没有效果，全部撤回，ReportSignaledFences 保持门禁通过时的原样。真 GPU 上的答案由 C 给出（ID-P10-11）。	lag 1–6 的本地作答都是 0–6；server 端追踪显示队首 fence 在约 4 帧的每次检查里都是 pending，要等 client 的 timed wait 过线、server 阻塞等待之后才被报告。Magma（lavapipe）同一追踪里报告全部早于等待，tcp 每帧 −37%。	A-FENCE-POLL.md
ID-P10-7	2026-09-29	B：GL_KHR_parallel_shader_compile 由 client 的编译开关决定，caps mirror 在采纳快照时重算这一项。	编译池与 GL_MAX_SHADER_COMPILER_THREADS_KHR 都在 client；Split / Spawn 之所以一致，只是因为 server 继承了 client 的环境，tcp 的共享 fixture server 不继承，于是 Tcp 的 AsyncOff 用例两后端都红。	CapsMirror.cpp、RemoteClientTest.cpp
ID-P10-8	2026-09-29	B：发射表的 SetSwapInterval 槽改为 server 转发器，SetSwapInterval_Unmigrated 与 BackendObject_Remote 的覆盖删除；class C 清零（69 已实现 / 0 未迁移）。控制由单元用例 ServerLoopTest.TheEmitTableSwapIntervalSlotCrossesAsOneDispatchedFrame 钉住（split 车道观察不到交换间隔）。	路线图列为最后一个手写 class-C。原槽是一个永远到不了的具名 Fatal，实际调用一直走另一条路。	EmitTables.{h,cpp}、BackendObject_Remote.{h,cpp}、ServerLoopTest.cpp、RemoteClientTest.cpp
ID-P10-9	2026-09-29	B 的登记：AsyncCompileScenario（AsyncOn / AsyncOff / OptimisticShaderStatus 三形）与 XfbPrimitiveQueryScenario 在两后端的 Split / Spawn / Tcp 上登记；PrimitivesGeneratedNoXfbScenario 只登记 Magma（Espryt 上每例都按设计跳过），其中 PrimGenReroute 不登记 Magma Tcp（共享 fixture server 读不到这个开关，8 例在 spawn_lane_parity.py 里具名列出）。	保证跳过的登记只会让门看上去更大。	MG_IntegrationTest/CMakeLists.txt、spawn_lane_parity.py
ID-P10-10	2026-09-29	B 查出、不在 P10 改的两项：(1) GL_ARB_gpu_shader_fp64 按 server 的 MOBILEGL_ADVERTISE_FP64 宣告，但 fp64 收窄发生在 client 的编译里，tcp 下 server 环境不同时会不一致，属于同类问题（挂点是 CapsMirror::Adopt）→ 债；(2) Magma 没有注册 SetSwapInterval，monolith 与 split 下 eglSwapInterval 都是空操作 → dev 线独立任务。	前者无触发报告，挂点已有；后者是 dev 的缺陷，按规矩不顺手修。	DEBTS.md；独立任务
ID-P10-11	2026-09-29	真机（Adreno 830，8d0a1b6c）上 A 成立：同一 bench 在 esc=64 时，Espryt 与 Magma 都是 0 次 fence 往返、598 / 598 次本地作答，回复槽记录 601 → 3；lag 1 / 4 也一样。ID-P10-6 的现象只出现在 llvmpipe 上，A 的实现不需要按后端区分。	这正是 ID-P10-6 留给 C 的问题。	C-MEASUREMENTS.md §1
ID-P10-12	2026-09-29	P10 收官。集成头（A + B，47bbf5e6）整套门：G1 符号增 0 减 0、.text 0xa52203（同机 clang 22.1.6，与 P9 相同）；fatal census 79、link ratchet 171、spawn parity 0、协议修订 3、wire-declines 53/53；卫生 12/12；unit 2644；integration-split / spawn / tcp 356 / 273 / 277；integration-magma-split / spawn / tcp / full-split 174 / 153 / 130 / 583；integration-gpu monolith / inproc 2348 / 2348。verify 构建 unit / integration-verify / integration-verify-split 2644 / 1238 / 1172。主机 retrace 230 / 236，6 项仍是 iterationrp 的宿主 llvmpipe JIT 崩溃（monolith 同挂，同 P9）。出口门"trace 上 draw / state / upload 往返读零"成立：MOBILEGL_PIPE_STATS=1 普查 156 条 SPLIT / SPAWN 条目，稳态回包等待只有 ResourceCreate（P12 已裁定保持）、MapPersistent，以及 llvmpipe 上 Espryt 的 FenceWait（C-MEASUREMENTS.md §3）。收官审查沿用 P12：不派 agent / Codex，契约断言由集成者对照代码核过（kEventFenceSignaled = 5 与 8 字节载荷、PollEscalate 默认 64 且范围 0..1000000、kFenceIdlePollMs = 1、控制协议修订 3、class C 无 _Unmigrated 桩）。	—	全阶段
ID-P10-13	2026-09-29	PRESENT_CREDIT 默认保持 1。设备上 tcp loopback 的 credit 1 / 2 / 3 在噪声内（rd12 51.4 / 51.6 / 52.4 fps，credit 等待 ~0.2 ms / 帧，传输停车 ~11.2 ms / 帧）；跨机 Wi-Fi 的 +26%（P12）是按链路调的旋钮，不是默认值问题。present credit 的直方图不另做：P65ClientPace 每次 present 都打 credit_wait_ms，分布可以直接从日志得到。loopback 上的下一个开销是 stream 传输的停车：记为性能债，等路线图推完再回头做（用户 09-08：性能只记录）。	路线图说"credit > 1 从未量过"，现在两条链路都量过了；推翻五臂报告的建议 #2（那组数据是旧构建、未定频）。	C-MEASUREMENTS.md §2
ID-P10-14	2026-09-29	让 Android itest 读到 split 运行时计数的构建补丁（-DMGITEST_ANDROID_STATIC_PEEK=ON：改链静态库并开启 SplitRuntimePeek）不入库，只存为证据（~/w7/notes/p10/evidence/c/peek-patch.diff）。	只是这一次测量要用；要让设备上的计数门成为一条车道，得先给 Android 框架加 pbuffer 路径（spawn 臂也缺这个），那是单独一项工作。	无（证据）