mirror of
https://github.com/MobileGL-Dev/MobileGL
synced 2026-11-07 01:53:24 +09:00
BZLZHH
82ed1df90e
- The predicate is one function again: MGPipeResourceRespecifyWantsItsReply (PipeRoute.h) is read by the wire emitter, so the two halves of this row cannot disagree about whether an answer is owed. The buffer half never owes one (both call sites discard the Bool, PipeFill.cpp:1105/:1142); the texture half owes one exactly until MGPipeHandleIsPublished, and that latch is set only by an ACCEPTED create - which EmitResourceRespecify already sends, blocking, when it is clear (TextureEmit.h:869-879). So the object pays once, at first use, and every record after it is fire-and-forget. - MEASURED on the device, same frame, same 101,421,396 B staged, stock power policy: waits 25,154 -> 4,543 and wall 130.9 s -> 31.3 s. The op split is the proof of what changed and what did not: waits by_op 3=20611 -> absent (only 2=4536, 5=6, 9=1 remain), while the RECORDS sent are unchanged - frame-sent still shows 3=20633 and 103,094 records total. The round trips went away; the work did not. - It also lands on an independent prediction: an audit run beside this work (mgl-device/scratch/ scheme-review.md) computed 4,543 remaining waits and a 24-37 s credible range (midpoint ~30 s) from the archived logs, a host-inproc round trip of 35.4 us and a measured 43.1 MiB/s link. Measured: 31.3 s, at the midpoint. - Cumulative on that frame since this work started: 43,232 waits / 221.5 s -> 4,543 / 31.3 s (7.1x). What is left is the create row (4,536 waits, ~23 s) - the confirmation itself, not waste - plus hard floors of ~13.4 s client CPU and ~2.2 s of transfer. Going below that means batching the create row, which keeps real answers. - TWO DEBTS, STATED: (1) the invalidation guard for the one silent-loss case is NOT wired; the audit confirmed independently that no production path can drop a texture record today, and if one appears the notice it needs is protocol-surface (a tenth reverse callback). (2) No SSIM or visual check has been taken since these rows stopped asking - frame-sent agreement is strong evidence but it is not a picture. - Two stale controls in older cases were fixed rather than left: the item-B gate now names the CREATE row (its old total-based control only moved because a respecify was still waiting), and the by-op measurement asserts records-sent for the rows that deliberately stopped waiting. RemoteClientTest 169/169; red-once for the predicate is forcing it back to "always wait".
MGPipe：MobileGL 前后端拆分
做什么：在 MobileGL 的前端（处理应用的 GL 调用）和后端（调用 GLES / Vulkan 驱动）之间立一份显式接口——前端把状态变化推给后端，后端不再直接读前端的内存。有了这份接口，前后端可以放在两个线程、两个进程，甚至两台机器上运行。
做到哪了（2026-09-25）：接口与拆分已完成到"两个进程、可经 TCP 跨机"。当前在做 P12：让 Android 上的 server 自己开窗口，把画面直接显示到屏幕上——审查后的主机定向测试和 Redmi 真机七项复测已通过；FCL 与跨机 TCP 两项验收仍未完成。→ CURRENT_STAGE_PROGRESS.md
一张图
应用的 GL 调用
→ 前端 MG_Impl：处理 GL 语义；在每条"做事的命令"（draw、clear…）之前，把状态变化整理成记录
→ MGPipe 接口（两张函数指针表，由调用目录 PipeCalls.def 生成）
→ 三选一：直接调用（单线程）│ 队列 → 另一个线程 │ 队列 → 另一个进程 / 另一台机器
→ 后端 MG_Backend：Espryt（GLES）/ Magma（Vulkan），按记录更新自己的状态并调用驱动
← 反向消息（错误、GPU 写回、窗口尺寸）按顺序回到前端
文档导航
| 想知道 | 看 |
|---|---|
| 现在做到哪、下一步 | CURRENT_STAGE_PROGRESS.md |
| 设计要点与各部分设计 | ARCHITECTURE.md → design/ |
| 分几个阶段、每个阶段做了什么 | ROADMAP.md → notes/<阶段>/ |
| 性能与验证的关键数字 | MEASUREMENTS.md |
| 怎么构建、运行、测试 | guide/build-and-run.md |
| 代码在哪 / 术语 / 工程纪律 | guide/code-map.md、guide/glossary.md、guide/discipline.md |
| 各阶段的原始计划、裁定、报告、证据 | notes/ |
整理记录：2026-09-24 两次整理——顶层只留索引，设计正文拆到 design/，上手与参考放 guide/，阶段细节放 notes/<阶段>/；整理前的版本见提交 1fb18d9。更早的设计竞赛与评审稿在 git 历史（8b31de2f、1794ac94、8349babe、87ee17c6）。