Files
MobileGL/docs/Disaggregated/OPEN-QUESTIONS.md
T
BZLZHH 6e36bf2c1b [Chore, Docs] (...): drop the archived notes and move the skill under tools
- the archive freeze rule goes with the directory
- code comments lose citations to the removed notes
2026-10-31 19:29:06 +08:00

11 KiB
Raw Blame History

开放问题全文(原 ROADMAP.md「开放问题」,2026-09-24 移入)

ROADMAP.md 只留每题一行的状态;这里是每一题的完整陈述、已答部分的出处与未答部分的判据。编号稳定,引用写 "开放问题 N"。

P0 已回答的不再列出(spike A 的域、spike B 的分档、posix_spawn 不可用、OOM 探测惯用法、GetInteger64i_v/GetProgramiv 退役、D21 与 RenderbufferObject lifetime id、动态 accessor 基线)。

  1. client 侧 dirty 走查的真实每 draw CPU 代价。 已答(P2–P4a):推送没有在拉取基线之下净减少;Release 下 P2 边界 +6–12%,P3a 在 VAO 切换密的 rd12 上再加 +17–19 pt,P4a 在 Espryt 上 +3.4–5.7 pt(MEASUREMENTS.md §3–§5)。用户 2026-09-08 接受,性能自此只记录。
  2. 真实语料上纹理重铸拉取的发生率。 已答(P4a):可忽略,保留 LRU 维持默认 0——79 例 × 两后端 780 个统计窗口里共 2 次(iris-photon、iris-derivative 各 1,只在 DirectGLES)。但 P5b 下这条路径是具名 Fatal,正是这两条 trace 加 create-indirect GLES 的首阻塞(P9)。P9 W2 关闭:重铸不需要拉取——server 读 GPU 层、store 补 pending 盒(Espryt),GPU→GPU 拷贝(Magma);77 行 × {monolith, inproc} 普查仍是同两次(都是 store 无字节的渲染目标),OnTexturePullRequest 已删(见 git 历史)。
  3. spike B 的 untrusted_app 域复核。 两台设备的分档在 shell 域测得;从应用进程再跑一次 extmem_probe(spike A 的 exec 钩子已可用)。P11 前做。2026-09-22 降级:只对同机臂的 T0 / T1 有意义,stream 数据面不需要。
  4. 渲染状态的 wire 粒度。 已答(P2):16 个边界 / 15 个 chunk,7 pipeline 396 B + 8 dynamic 772 B;CSO LRU 64 暂定,P13 重调。
  5. 无存储的 capability。 已答(P2):FramebufferSrgb、DepthClamp、TextureCubeMapSeamless 三个都补了真存储,sizeof(RenderStateParameters) 仍 1168。
  6. 具名 UBO host payload 的形状(D-B8)。 Magma 在 26.3 世界每帧重打包 331 KB 具名 UBO 字节,Espryt 为 0。要么冻结第二变长尾形状,要么走备选(Magma 直接描述符绑定常驻 VkBuffer range,独立 dev PR)。P7。
  7. MG_Util 的切割缝。 server 需要 SPIRV-Cross / ESSL 转译缓存 / 格式处理器 / POST 探针,client 需要 glslang 与反射层;MG_Util 内部是否有干净的 Transpile-vs-Reflect 缝未审计。P7。
  8. 一份反射归档能否服务三个消费者。 Espryt 那一半已答(P4a):能且不需要复制。Magma 的第一个消费者已由 P5f fm 答:MagmaProgramSource 全部从 wire ProgramArchive 取,无前端对象、无复制。第二个(storage block 表)今天是否且变差了:split 下 MagmaProgramSource::EnsureStorageBlocks 每 draw 重跑 SPIRV-Reflect(monolith 臂 DirectVulkan.cpp:177-200 至少有持久缓存);答案是往 LinkArtifacts 加有序 storageBlocks(数据已在 blockReflection 里),两个消费者都改读它。已答(P7 wave 2-C,dce9953d..cf7ca59f):storageBlocks 入归档、两个消费者改读、每 draw SPIRV-Reflect 4→0;g_programResourceCaches 的 monolith 半边归 P13(G1)。
  9. viewport-array 回放能否塞进一次 draw_vbo:已答(2026-09-30,ID-P8-1):能——server 在一次 draw 内按状态分组逐遍回放(DirectGLES.cpp:8421-8465),ViewportArrayScenario 在 split 各臂绿。
  10. ResidentSubData 的不对称。 已答一半(2026-09-22 核):Magma 的实现已补(VkBufferManager.cpp:123 monolith 表、:148 wire 表,fff9d639f)。仍未答:kCapResidentSubData 从未被 server 发布——MG_Backend/Init.cpp:192-219 是全树唯一的 SetCapabilityBits 生产调用点,只 OR 了 XFB、三个 query 位与 run-ahead 位;于是 PipeFill.cpp:848 在 split 下恒 false,两个后端在拆分模式下都退回 BufferObject.cpp:711-716 的就地 memcpy,Magma 的实现在 split 里是死代码。已答(P7 wave 2-C,ID-P7-20):InitServerRoleCommon 按 server 自己的 wire 资源表发布 kCapResidentSubData,镜像收到即验收;白盒「发出的是 opcode 49」在 P11 采纳档落地前不可达(§5.4 债)。
  11. SEG_STAGE 的上限。 内容侧已答(2026-09-20):分块已实现——buffer 范围走查(1e7c372e)与纹理整宽 slab(9469d48e)按 MGPipeStageChunkBytes()(默认 32 MiB 的 1/4 = 8 MiB)切成多条 resource_subdata,所以单次 128 MiB 上传不再需要显式 MOBILEGL_IPC_STAGE_MB=256;单片仍超 arena 或该 record 类型未接入分片时仍是 Fatal{RingOverrun, "SEG_STAGE"} 兜底。仍未答(2026-09-22 收窄):a6 §6 实测没走查的只剩 program archive(唯一无界 blob)与 draw_vbo 的 NumDraws*12 range 尾;宿主索引 span 无 producer(划掉),set_global_constants 有走查。二者的分片是 P6.5 sl 与 P8 共用的同一件事,stream 发送窗口对着它们定尺。MC in-world / Create 的占用分布仍未量(门 8 已给出两条负载的字节/帧与记录/帧,逐 blob 分布只在 integration 车道取到)。 P8-0 实测(2026-09-30,ID-P8-5):最大 program archive 354,846 B、最大 draw_vbo 记录 1,936 B,都远低于 arena/4;不做分片,关闭。
  12. P13 之后 split-only 渲染 bug 的 server 侧第二意见。 verify 构建 + recorder 只覆盖推送内容,不覆盖后端对它的解释。
  13. 烘焙后的内部 shader 能否在没有活 ProgramObject 的情况下表达 uniform location 与 UBO 布局。 颜色 blit 已答(P5f fv:WireColorBlit.{vert,frag} 用 push constant,WireColorBlitSpirv.h 签进树);窄化到深度 mip 程序(今天在 split 下被编译掉、其 split 路径是具名 Fatal)与直通 TCS(ProgramFactory.cpp:4060-4262,第三个未盘点的内部 shader 生成器)。已答(P7 wave 2-B / B2):深度 mip 烘焙 (A)(D)(WireDepthMipmap.*,push constant,MOBILEGL_BAKED_INTERNAL_SHADERS 新鲜度门表驱动)与 (B′)(disaggregated 构建的 monolith 臂改用烘焙模块)落地;multisample resolve 第三套烘焙 shader 随 B2;直通 TCS 仍未盘点。
  14. 推送模型改变哪些按拉取模式调过的缓存命中率。 幸存者容量在 P13 重调。一条线索:设备上 26.3 Espryt 的 sve ≈ draw 数(每 draw 重发一次 sampler-view 集合),桌面只有 ~0.07/draw;列入 P3b/P4b 优化清单。
  15. monolith 的 *IndirectCount 不调 SyncGpuWrites() 是不是潜在缺口。 独立 dev 问题,拆分不得借机顺手修。已答(2026-09-30):是——P8-C / P8-D 主机 red-once 证实(Espryt *IndirectCount、Magma glMultiDrawArraysIndirectCount 读到 0);split 半已修(ID-P8-9),monolith 半在 P8 第二波的 dev 包里修(ID-P8-3)。
  16. 索引宿主镜像的实际内存占用。 MC / Sodium / Iris 语料里 element-array buffer 总量未测;若显著超 64 MiB,退化路径的频率与代价必须实测。P8。
  17. create-indirect fixture 在 Adreno 830 上的失败是 dev@81b17c0b 就有的(基线 APK 复现),不是本分支造成;rd12 + Magma 在两台 Adreno 830 上的 scudo::reportMapError 崩溃同样是 dev 侧。两者排除在设备 A/B 之外、留在桌面语料里;P8 要在 create-indirect 上断言 roundtrips-per-frame == 0,所以 dev 的修复在别人的关键路径上。create-indirect 部分已答(2026-09-30):原 fixture 在 GL_SHADER_STORAGE_BUFFER_OFFSET_ALIGNMENT = 16 的桌面驱动上抓,Flywheel 按 16 摆 scatter 列表;Adreno 830 两后端与 Mali 的 Vulkan 要 64,1,270 次范围绑定全被 GL_INVALID_VALUE 拒掉。原 fixture 退役,换成派生的 minecraft-1.21.1-neoforge-create-indirect-in-world-align1024(不是同一个 trace:tools/trace_replay/fixture_tools/realign_buffer_ranges.cpp --align 1024 把这些绑定挪到 1024 对齐的槽,插入 3,812 个调用,目标调用 504631 → 508443;主机 SSIM 与原 fixture 9 位一致)。红米两后端 monolith / spawn 全过;Mali-G1-Ultra 上 Magma 全过(split 臂另修了 T0 POST,见 CONTRACT-P11.md POST 节),Espryt 仍 0.848:该机 GLES 驱动顶点阶段 SSBO 上限为 0,Flywheel indirect 的顶点程序链接不了(能力缺失,不是分离缺陷)。
  18. split 两侧的负载平衡。 P5e 解锁出来的新问题:VD32(~3550 draws/帧)下 apply 线程 11-12 ms、client 15.7 ms,client 是瓶颈且打满 ~94%。把工作从 client 挪到 apply 会直接降瓶颈——这在 lockstep 下毫无意义(两侧串行相加),run-ahead 才使它成为一个杠杆。供选:编码侧的 emitter、tracker 走查、持久映射的脏页追踪(change_protection 在侧写里占 1.3%)。需先重新侧写:等待消失后尾部各项的分母都变了。排在 P5e 之后;无主,2026-09-22 建议挂在路线图推完后的优化阶段,P6.5 的 2×2 矩阵车道顺带重新侧写
  19. 链路带宽预算与压缩。 TCP 终局下 SEG_STAGE 字节/帧对的是 Wi-Fi / USB(量级 30–100 MB/s),不是内存;ARCHITECTURE.md §14 的 ~1 MB/帧预算在 60 fps 是 60 MB/s,已贴着 Wi-Fi 上限。是否对 stage 载荷做 LZ4 类压缩、纹理上传是否按内容哈希在 server 侧去重,要等门 8 的分布出来再定。P6.5 契约写下第一行之前必答。
  20. 大单次上传的停顿。 128 MiB 一次上传在 50 MB/s 上是 2.5 s;内容侧分块解决的是"装不装得下",不是"要等多久"。跨机臂上要么接受并记录,要么给上传做异步化(与 P9 的语义一起想)。不假装解决。
  21. 配对 / 认证的形式。 已裁定(ID-P7-3,2026-09-22):令牌足够,不做 TLS。 威胁模型是「任何人都能连的远程代码路径」而不是窃听:令牌常量时间比较、≥16 字节、无令牌只 loopback、数据面以 Welcome.dataNonce 绑定到已认证的控制连接、fork 前认证。TLS 作为 P12 的开放项保留。
  22. client 平台范围。 默认先 Linux + Android(现有 CI 能验),Windows client 第二批(ShmSegmentWin32 在;pipe: 具名拒绝作废、TCP 替代),macOS 仍不拆分。这决定 ARCHITECTURE.md §15.3 "Windows 机器不是正确性门"要不要改。
  23. 半开连接的检测。 Wi-Fi 掉线不产生挂断事件;dl 的闩取自描述符挂断,TCP 上需要 keepalive / 心跳超时并由传输层报告为挂断——这与"绝不取自 apply 超时"不矛盾,写清楚免得重吵。P6.5 ct。
  24. E1 对照的重定义(ID-122)。 已关闭(2026-09-29 债务审查):10bfd29f 把 E1 的像素竞速换成观测协议等待的负控 scripts/ci/wait_boundary_negative_control.py。2026-10-18 该负控退役:探针看得见缺失的等待,改由常驻单元用例 RemoteWaitBoundaryControl.AnUnwaitedPublishIsSeenAsNoWait 证明(同一个 ApplierReset,发布后不等待,必须读到 parked=0)。