Files
MobileGL/docs/Disaggregated/MEASUREMENTS.md
T
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

5.4 KiB
Raw Blame History

实测(索引)

这一页只有结论和去向;完整的表、命令、协议与读法在各阶段 notes/<阶段>/README.md 的"实测"节。代码和旧笔记里的 MEASUREMENTS.md §N 按下表"§"列找到对应阶段(小节编号在那里原样保留)。

口径:性能只记录、不设门;看逐线程 CPU 时间,不看整机帧率。性能对比只用一台手机(Redmi 2f7cbe2e,Adreno 830),定频、同热窗口、两臂交替跑(guide/pin-verification-2026-09-07.md)。

关键结论

  • 接口本身的代价:单进程里改成"前端推、后端收",CPU 多约 6–12%(P2),已接受;顶点数组切换密集的场景更高(P3a,+27–30%)。
  • 拆成两线程:起初游戏里只有 7–13 fps;优化后 103–106 fps(P5d);client 发完就走以后,重负载(渲染距离 32)下与单线程持平(P5e)。
  • 拆成两进程:真机上与两线程成本持平;两者的 GL 线程 CPU 都比单线程少约 30%(后端工作挪到了另一线程 / 进程)(P6)。
  • 跨机:电脑经 TCP 连手机,102 个集成用例全过;server 被杀后 133 ms、Wi-Fi 断开后约 5 s 干净报"设备丢失"(P6.5)。
  • 纹理上传的等待粒度(P12,handoff §4):wire 臂上纹理那半 resource_subdata 不再逐条买回包,等待点从「每条记录」落到「SEG_STAGE 窗口用尽」。 单条纯上传占用的回包等待 1 → 0(wait_replies,正是 §3.2 里"一帧 55,428"的那个计数器)。 按形状实测(RemoteClientControls.ReplyWaitsByOpForAnAtlasShapedLoad,主机 inproc,按 op 计数):图集拼接(一张 level 上 64 次 glTexSubImage2D)64 → 0 次回包等待; 每 sprite 一张纹理(64 张纹理 + 256 次 glTexParameteri)384 → 320,剩下的全是 per-resource / per-call 的三条 row(create 76 / respecify 130 / params 130)—— 它们的拒绝是「服务端没有这个 handle」的唯一客户端可见信号,删掉等待就是删掉信号,裁定见 CONTRACT-P5E.md §2.5。 真机(TrebleDroid GSI,MC 26.2 经 TCP 入世界)那一帧的构成为 ResourceRespecify 20,633 + SetTextureParams 18,056 + ResourceCreate 4,536 条各等一次, 而 ResourceSubData 12,671 条零等待(B 的实机证据);这些记录都是真实状态变化,客户端没有可去重的(同一值的 glTexParameteri 本来就不产生记录)。
  • 单次往返那 ~5 ms 是设备侧的深度空闲退出,不是链路也不是客户端(P12,本轮实测):同一帧、同一批记录, 客户端自旋 40× 只快 ~10%;换 adb forward(USB)快 ~25–30%;而把设备 8 核钉 performance 并关掉 cpuoff_l/clusteroff_l/mcusysoff/s2idle 后, 单次等待 5,040 → 3,715 µs、那一帧墙钟 221.5 s → 166.5 s(−25%)——记录数与字节数都不变。 这解释了 handoff §3.6「换快 3.4 倍的链路墙钟不变」:钱花在设备每次唤醒上;handoff §3.2 那 249 s 是在未定频的机器上取的,含这份空闲税。 见 notes/p12/DEVICELOST-AND-UPLOAD-WAITS.md §2.6–2.10。
  • 画面正确:Vulkan 后端真机画面检查 36/36 通过,CTS 五块相对基线没有超过 0.5 个百分点的退步、没有新崩溃(P7);server 自有窗口上屏两后端 SSIM 1.0(P12)。

按阶段

§ 阶段 一句结论 全文
1 P0 能从应用进程拉起第二个进程;跨进程共享 GPU 内存只有一条路在所有设备上可用 notes/p0
2 P1 逐 draw 核对推送状态,79 条 trace 零分歧 notes/p1
3 P2 桌面基准:新 tracker 比它替掉的旧填充更便宜 notes/p2
4 P3a 两机真机 Release:接口代价 +6–12%,VAO 切换密集的场景 +27–30% notes/p3a
5 P4a 换到 Redmi;P4a 自己只加 3–6 个百分点 notes/p4a
6 P5 两线程第一帧画对;真机两线程臂还跑不完 notes/p5
7 P5b 真机两线程跑通四条游戏 trace;两线程额外代价 +6–18% notes/p5b
8 P5c 两线程之间零共享内存后,全部测试仍绿 notes/p5c
9 P5d 游戏内 7–13 → 103–106 fps,client CPU 15.0 → 9.2 ms/帧 notes/p5d
10–11 P5e 发完就走比每条都等快 69%;重负载下与单线程持平 notes/p5e
12 P6 两进程与两线程持平;每帧数据量与记录数首次实测 notes/p6
13 P3b/P4b 纹理上传形状在四种拓扑下完全一致 notes/p34b
14 P6.5 跨机 TCP 102/102;断线约 5 s 检测到 notes/p65
15 P7 真机画面 36/36;server 内存无界增长收住(主机 825 → 546 MiB) notes/p7
16 P12 审查后真机复测:Espryt SSIM 1.0;Magma 1.0 / 0.999999511;P12 定向 CTest 46/46;纹理上传回包等待 1→0(主机机制门,真机墙钟待测);FCL 与跨机 TCP 收官门仍待完成 notes/p12