Files
MobileGL/docs/Disaggregated
BZLZHH 7c72dfde2b [Docs] (P12): the ~5 ms per round trip is the DEVICE's deep-idle exit, not the link and not the client - which is what the handoff measured and could not explain
- Three one-variable experiments on the same device, same workload (the 43k-record frame): a 40x
  larger client spin moves the per-wait mean by ~10% (so it is not the client park/wake); the
  same frames over adb forward - a link whose raw RTT is several times lower - by ~25-30% (so it
  is not the link, which is what the handoff saw in 3.6 and could not account for); and pinning
  the device (governor performance on all eight cores, cpuoff_l / clusteroff_l / mcusysoff /
  s2idle disabled) by 26% per wait and 25% of the whole frame: 221.5 s -> 166.5 s for 43,218
  records and 100.5 MB staged, against 43,232 and 101.4 MB in the baseline.
- The mechanism: the server's apply thread parks between records, the SoC drops into a deep idle
  state, and every record pays the exit latency - milliseconds, once per record, which is the
  entire shape of the frame. It also matches the server profile the handoff took (65% socket
  syscalls, ~15% doorbell spin: waiting and waking, not working).
- Stated where it matters: the handoff's 249 s was taken on an UNPINNED device, so its absolute
  numbers carry this idle tax - the project has a pinning discipline for exactly this reason.
- The lever list is now ordered: batch the waits (K <= 8 by the reply-slot pool, client-only),
  keep the server hot between records (its own spin budget, which the APK does not wire yet), and
  measure split numbers on a pinned device. The device was restored to stock afterwards.
2026-09-25 21:28:13 +08:00
..

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)。