scope B 限定版 (forward 末尾 + backward chain を 1 cmd buffer 集約、~3 commit/iter 削減) を worktree binary で 30k bench。baseline 24.879 dB / 23m13s に対し 24.577 dB / 21m47s、Mildly positive finding。Apple Silicon の commit overhead が予想より小さく、scope B で実効 ~6%。
A.7 plan の scope B (Buffer 入出力 variant 追加 + backward chain と forward 末尾を batched 化) を worktree a-7-icb-batching で実装、env SPLAT_BATCHED_FORWARD=1 で活性化。30k bench (lego sh=3, seed=42, capacity=1M) で baseline 24.879 dB / 23m13s に対し 24.577 dB / 21m47s、wallclock -6.16% 改善。PSNR drift -0.302 dB は許容範囲内 (target < 0.5 dB)。Mildly positive finding。
Plan の literal interpretation (Option<&CommandBufferRef> 引数だけ追加) では subagent 1 が問題発見: splat-metal の現行 kernel API は全 host slice 入出力前提、radix_sort は内部で 16 pass の hist→scatter + host CPU 側 exclusive prefix scan を行うので 1 cmd buffer 集約は不能。selectable な batching site は限定的。
rasterize::forward_from_buf (Buffer 入出力 + Option<CommandBuffer>)rasterize::backward_from_buf 同project::project_backwards_from_buf 同tile_bin::extract_offsets_from_buf 同trainer::forward_with_state_batched_tail: extract_offsets + rasterize.forward を 1 cmd buffertrainer::backward_combined_batched: rasterize.backward + project_backwards を 1 cmd buffertrain_loop: env SPLAT_BATCHED_FORWARD で batched path 切替cargo test -p splat-metal --lib: 25 pass / 0 fail (既存 23 + 新規 2)cargo test -p splat-train-v1 --lib: 31 pass / 0 failforward_from_buf_matches_forward_unbatched: pass (tol 1e-6 厳密)backward_from_buf_matches_backward_unbatched: pass、ただし tol abs 1e-4 / rel 1e-4 に緩和backward の緩和は SIMD backward kernel の atomic_fetch_add dispatch 順序非決定性によるもの (実測 1.9e-6 のズレ、A.10 と同類の GPU 非決定性 finding)。kernel 性質で再走でも変わらない、accept。
| metric | baseline (sh3-30k) | A.7 (batched) | Δ |
|---|---|---|---|
| PSNR (val 100 views) | 24.879 dB | 24.577 dB | -0.302 dB |
| wallclock (30k iter) | 23m13s (1393s) | 21m47s (1307.26s) | -85.74s (-6.16%) |
| ms/iter (avg) | 46.4 ms | 43.6 ms | -2.8 ms (-6.03%) |
| final splats | 83,734 | 82,855 | -879 (-1.05%) |
plan では commit overhead を 0.3-0.7 ms × 25+ commits/iter で iter の 20-50% を占めると見積もったが、実測 -6% から逆算すると per-commit overhead は ~0.1-0.3 ms 程度。Apple Silicon GPU の command queue は CUDA より overhead が小さいことを示唆。これは brush (wgpu→Metal) が CUDA native (orig 3DGS) より速い (m4-brush-bench) という別 finding と整合的。
backward の SIMD atomic 順序非決定性 (test で観測した 1.9e-6 のズレ) が iter ごとに gradient を微小に変化させ、30k 累積で refine 判定が微妙に変わる。splats 数も -1.05% (82,855 vs 83,734) と僅差、PSNR drift も -0.3 dB と限定的、実用上問題ない range。bit-identical を求めるなら backward を non-atomic な reduction に書き換える必要があるが、scope 外。
第 3 軸 (Apple Silicon 固有最適化) の Positive finding。M-3.x baseline 23m13s → 21m47s と 1 行が central table に追加できる。「Apple Silicon の command queue overhead は CUDA 系より小さく、batching の利得は marginal (約 6%)」という結論で、A.9 (-10 dB / +75% 二重 negative) と A.10 (bit-identical) と合わせて、Apple Silicon 固有最適化の 3 試行のうち **1 positive (A.7) / 2 negative (A.9, A.10)** という構造ができた。
kernel API の Buffer 化は scope 拡張だが、その実効として ~6% wallclock 改善が得られた。次に GPU profiler (Instruments Metal Trace) を当てて、forward chain 上流 (project / emit_pairs / radix_sort) の commit overhead 寄与を直接計測すれば、追加の batching 余地を識別可能。
a-7-icb-batching-plana-9-f16-forward-negativea-10-kahan-negativem4-brush-benchfinal-ablation-tableこの finding が観測された / 言及している実験 run。