mirror of
https://github.com/MobileGL-Dev/MobileGL
synced 2026-11-11 20:13:23 +09:00
BZLZHH
1ef7439625
The second one-line experiment, and the one that decides whether the retention design is worth building. Ring 1024 plus the residency budget DISABLED (its constant raised out of reach), W=2 and W=4: arm waits rtt_mean by_op 2 wall W=1 (today's default) 4,543 5,672 us 4,536 28.66 s budget on + ring 8 9,078 2,598 us 9,071 27.04 s ring 1024 + budget 7 3,450 5,367 us 3,443 23.04 s ring 1024 + budget OFF W=2 2,560 4,916 us 2,553 16.80 s ring 1024 + budget OFF W=4 1,691 4,224 us 1,684 11.45 s rtt_mean does NOT grow (4,916 / 4,224 us, both BELOW the 5,672 us baseline) while the waits fall by 2x and 2.7x and the wall follows. So the ~5 ms is a WAKEUP round trip and the server drains a batch per wakeup - which is exactly what makes W pay, and it is the question the audit listed as undecidable from the repo and the watershed for whether this is worth doing at all. It is. AND IT BEATS THE HANDOFF'S OWN FLOOR: handoff-2 section 0.4 put the window's landing at 15-20 s, treating the client's ~13.4 s CPU as ADDITIVE with the waits. This frame turns out to be wait-dominated, so amortising four creates per wakeup lands at 11.45 s, 3.5 s below that estimate. 1024 IS A STAND-IN, NOT THE DESIGN: it works only because 1024 happens to be deep enough for this workload, and 1024 retained answers is ~2 GiB worst case (a ReadPixels answer can be 2 MiB). Retention gives the same property - the answer is still there - with a bound tied to the client's own deferral depth, which is why the implementation the audit specified is what gets built, not "make the ring 1024". Also corrects the note's section 7 path 1 (audit F15): on the stream arm SEG_REPLY and the Hello's ReplySlotCount have nothing to do with answers - they travel as Reply frames and StreamLink::ReadReply reads the client's own store - so "deepen the pool" does not address the arm that was measured, and should not be paid for. Reverted (ring 8, budget 7, probes deleted); 172 + 13 green.
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）。