[{"data":1,"prerenderedAt":381},["ShallowReactive",2],{"finding:p3-s4-host-shadow":3,"finding-runs:p3-s4-host-shadow":298,"finding-related:p3-s4-host-shadow":299},{"meta":4,"impact":45,"sections":51},{"id":5,"title":6,"subtitle":7,"eyebrow":8,"date":9,"status":10,"category":11,"polarity":12,"axes":13,"tags":16,"task_code":25,"commit":26,"branch":27,"config_paths":28,"related_runs":37,"related_findings":41},"p3-s4-host-shadow","S4 — post-backward accumulate を backward CB shadow に配置する host_schedule flag — 棄却確定 (2026-08-30 gate)","`p3-c2-bubble-attribution` 施策 #1 (期待 -3〜-5%、実装後の再見積りで -1.5〜-3%) の実装。`[backend] host_schedule = \"forward_shadow\" (default) | \"backward_shadow\"` を追加し、\u003Ccode>RefineState::accumulate\u003C\u002Fcode> (+ その入力の grad readback) だけを 1 iteration 遅らせて \u003Ccode>B_it+1\u003C\u002Fcode> の commit 直後 (\u003Ccode>B_it\u003C\u002Fcode> 自身の 6.38ms shadow の中) で flush できるようにした。実装・test・1000 iter smoke は完了していたが、\u003Cstrong>12.5k n=3 A\u002FB gate で Δ +5.63% (on が off より遅い、期待と逆符号、閾値 max(2σ,1%)=1% を大きく外れて不通過) — 棄却確定、default (ForwardShadow) は変更しない\u003C\u002Fstrong> (§8)。","2026-09 ゼミ milestones · S4 · C2 施策 #1 · gate 棄却","2026-08-30","stable","experiment","negative",[14,15],1,3,[17,18,19,20,21,22,23,24],"s4","c2","host-schedule","pipelining","depth2","refine-accumulate","gate-rejected","contaminated-pair-retry","S4: C2 施策 #1 (post-backward host 仕事の backward shadow 配置) 実装 + gate","e40a7b1b00cb (実装) \u002F gate は main HEAD 5ef49c4a8aac 上、後続 commit なし (棄却のため .rs 変更なし)","worktree-agent-a644550e0fa910e30 (実装、main merge 済み) \u002F main (gate)",[29,30,31,32,33,34,35,36],"splat\u002Fconfigs\u002F2026-08-30-s4-12500-off-r1.toml","splat\u002Fconfigs\u002F2026-08-30-s4-12500-off-r2.toml","splat\u002Fconfigs\u002F2026-08-30-s4-12500-off-r3.toml","splat\u002Fconfigs\u002F2026-08-30-s4-12500-off-r4.toml (r1 retry)","splat\u002Fconfigs\u002F2026-08-30-s4-12500-on-r1.toml","splat\u002Fconfigs\u002F2026-08-30-s4-12500-on-r2.toml","splat\u002Fconfigs\u002F2026-08-30-s4-12500-on-r3.toml","splat\u002Fconfigs\u002F2026-08-30-s4-12500-on-r4.toml (r1 retry)",[38,39,40],"splat\u002Fruns-logs\u002Fs4-12500-*.log (n=3 主系列、r1 pair は汚染で破棄・保存)","splat\u002Fruns-logs\u002Fs4-12500-retry4-*.log (r1 pair retry、r4 として採用)","splat\u002Fruns-logs\u002Fs4-12500-predecision.log (事前登録判定規則)",[42,43,44],"p3-c2-bubble-attribution","p2-s3-iteration-pipelining","p3-final-stack",{"summary":46,"rank":47,"verdict":48,"delta_wallclock":49,"delta_psnr":50},"C2 施策 #1 (post-backward host 仕事を backward CB shadow に配置) を `[backend] host_schedule` flag として実装し、12.5k n=3 交互 A\u002FB gate を実施した。**棄却 — ただしどの尺度で見ても符号は on≥off で一貫**: 採用セット (r1→r4 置換) の点推定は +5.63% だが、これは on-r4=141.77s という単一の大外れ値に支配された数字であり (on-r4 を除くと +1.8%、r1 込みの retry 前でも +1.02%)、σ_on 6.36% の広さを踏まえると真の効果量は ~1〜2% (harness 分解能付近) で null〜わずかな悪化とみるのが妥当 (`p3-tier1-bit-exact` v1 が経験した「単一の汚染値が代表値を膨らませる」パターンの符号違い版)。r1 pair は series 独立 load sampler で load1 max 7.91\u002F8.90 (LOAD_LIMIT 6.0 超) を検知し事前登録条件 (i)(ii) を満たしたため 1 回だけ retry (r4) に置換 — ただし (i) の判定は max ベースで行っており、mean ベースでは off-r1 (mean 2.72) は 1.5×中央値 (3.765) 未満で非該当になる (次回の predecision には mean\u002Fmax のどちらで評価するか明記すべき教訓、§8 参照)。retry 後の on-r4 (141.77s) はさらに大きな外れ値だが、走行中 load1 は終始 clean (mean 1.64 \u002F max 3.19) — 事前登録条件 (i) load 証拠が不成立のため追加 retry はせず (`p3-tier1-bit-exact` §5 の教訓通り、条件 (ii) 単独での retry 連鎖を回避)。discarded r1 pair 自体は on\u003Coff (on が速かった) — 「3\u002F3 一貫」は採用セットに限った話で、破棄分含む 4 pair 全体では 3\u002F4 が on>off。ms\u002Fiter trace は on-r4 で iter 2000 以降一貫して高い (discrete spike ではなく持続的) — A7 §7 off-r3 と同型の GPU thermal 蓄積の可能性はあるが host_schedule 由来と特定する根拠はない。全 pair とも off→on の順で実行 (ABAB、ABBA 均衡化なし) — on arm は常に「温まった後」の機体条件で走っており、末尾の on-r4 が最遅であることと整合するが、同構造の A7 gate では on 側が一貫して速かったこともあり主要因とは考えにくい。棄却により `.rs` は一切変更していない。","low","rejected","**逆符号 (on が遅い) — どの扱いでも正符号、代表値は使わないこと**。採用条件 Δ ≤ -1% に対し: r1→r4 置換 n=3 で **+5.63%** (on-r4 の大外れ値 141.77s が支配)、on-r4 を外れ値として除外した n=2 相当で **+1.8%**、r1 込み (retry 前) n=3 で **+1.02%**。σ_on 6.36% という広い散らばりに対し +5.63% は解像できる効果量ではなく、**真の効果量は ~1〜2% (harness 分解能付近) で null〜わずかな悪化、`p3-tier1-bit-exact` v1→v2 と同種の『単一外れ値が代表値を膨らませる』パターン**とみるのが妥当。どの扱いでも符号は一貫して不通過 (on≥off) なので棄却の結論自体は変わらない","+0.027 dB (guard 内、ただし wallclock 不通過のため判定は変わらない)",[52,55,58,85,87,102,104,109,113,115,124,126,141,143,160,162,169,171,191,274,277,280,283,286,288,293,295],{"type":53,"text":54},"lead","`p3-c2-bubble-attribution` §6 施策 #1 は「post-backward の host 仕事 (grad readback 後の `RefineState::accumulate`、SSIM host 総和、opacity decay 準備等) を forward CB の 2.00ms shadow ではなく backward CB の 6.38ms shadow 側にエンコード順序を変更する」ことを提案し、期待 Δ を -3〜-5% とブラケットした。本 finding は **その実装** (`[backend] host_schedule` flag、`Depth2Pipeline` の 1-iteration lag)、実装段階で判明した制約 (loss staleness を守るスコープ限定、既存 2 世代 scratch の再利用による安全性論証)、そして **12.5k n=3 A\u002FB gate の実測 (Δ +5.63%、期待と逆符号で棄却確定、§8)** を記録する。",{"type":56,"text":57},"heading","1. 実装 — 何を動かし、何を動かさなかったか",{"type":59,"columns":60,"align":64,"rows":66},"table",[61,62,63],"対象","動かしたか","理由",[65,65,65],"left",[67,71,74,78,81],[68,69,70],"grad readback (`chain.grad_buf` の `to_vec()`\u002Fslice 読み)","○ (backward_shadow のとき)","`RefineState::accumulate` の入力のみに使われ、他の値を消費しない — 遅延させても副作用がない",[72,69,73],"`RefineState::accumulate`","施策 #1 の本体。`grad_xy_accum`\u002F`visible_count` は refine tick でしか読まれず、tick は常に `debug_assert_drained` 経由で flush 済みを要求する drain 点",[75,76,77],"`read_loss_mean` (l1)","× (常に同期)","`StepOutcome.loss` → `history` に直接効く。1 個の float 読みでコストも無視できる",[79,76,80],"`read_mean_ssim` (SSIM host 総和、1.92M 要素)","`loss = \"l1_ssim\"` のとき `StepOutcome.loss` の一部。動かすと `loss_history` が 1-step stale になり、`crate::pipeline` module doc の逸脱項目 2 (「表示のみ 1-step stale」は不要と明記済み) を破る。**最大の未着手候補** (下記 §5 で follow-up として明記)",[82,83,84],"scale_reg\u002FMCMC L1 RMW・adam (out-of-cb)・MCMC noise","× (対象外)","これらが有効な iteration は `grad_rmw_pending`\u002F`mcmc_noise` により `prefetch_next` が構造的に false — 施策の対象になる「prefetched した iteration」には元々出現しない (実装時に確認、下記 §2 参照)",{"type":56,"text":86},"2. 安全性の論証 — 追加 buffer 世代は不要だった",{"type":88,"items":89},"kv",[90,93,96,99],{"key":91,"value":92},"grad buffer の物理的な生存期間","`chain.grad_buf` (= `Rasterize::work_grad`) は forward scratch と同じ `GenScratch` 2 世代 ping-pong に既に乗っている (`splat-metal\u002Fsrc\u002Fkernels\u002Frasterize.rs` の `work_grad: GenScratch\u003CBuffer>` field)。`ScratchGen::generation_for_iter(it) = (it-1) % 2` は周期 2 — `g(it+2) == g(it)` だが `g(it+1) != g(it)`",{"key":94,"value":95},"1-iteration lag が安全な理由","`B_it` の grad は世代 `g(it)`。`B_{it+1}` の encode は世代 `g(it+1) != g(it)` で **別の物理 buffer** を触る。よって `B_it` の grad readback を `B_{it+1}` の commit 直後まで遅らせても、`B_{it+1}` 自身の zero-clear\u002Fwrite と衝突しない。`B_{it+2}` (世代 `g(it)` を再利用) の encode が始まる前に必ず flush されていれば安全 — 実装は `B_{it+1}` の commit 直後 (= `B_{it+2}` の encode よりずっと早い、1 iteration 分の余裕がある) で flush するので十分",{"key":97,"value":98},"追加で必要だった buffer 世代","**0 (ゼロ)**。`p3-c2-bubble-attribution` §6 施策 #1 は「grad の double-buffer 化が必要 (depth3 pipelining と同じコストクラス)」と見積もっていたが、実装時に既存の 2 世代 scratch がこの用途を既にカバーしていることを確認した — 追加のメモリコストなし",{"key":100,"value":101},"flush 位置","`commit(B_it)` → `encode+commit F_{it+1}` (既存の手順 4) → **flush deferred(it-1)** (新規、`B_it` 自身の 6.38ms shadow の中) → `wait(B_it)`。flush を prefetch encode の**後**に置くことで、GPU キューへの投入 (`F_{it+1}` の commit) を host bookkeeping より先に済ませ、GPU が先に完了してもキューが空にならないようにしている (advisor レビューでの指摘を反映)",{"type":56,"text":103},"3. 実装レビュー中に見つけた配線バグ — `Trainer::Cell` 経由をやめ `backend` 直渡しに変更",{"type":105,"label":106,"variant":107,"text":108},"callout","advisor レビューで発覚: test fixture は `apply_backend_config` を通らないため Cell 配線が効かない","warning","初版実装は `pipelining_depth` と同じパターン (`Trainer::host_schedule_backward_shadow: Cell\u003Cbool>`、`apply_backend_config` が `[backend] host_schedule` から設定) を踏襲した。しかし `train_loop.rs` の test fixture (`LoopFixture::run_with_backend`) は **`apply_backend_config` を呼ばない** (pipelining 関連の 2 箇所だけ手動で配線する既存規約、A7 の `refine_scratch_persist`\u002F`refine_direct_write` は `backend: &BackendConfig` 引数から `train_loop` が直接読む設計だったため今まで問題にならなかった) — このため新規 test 3 本は **`backend.host_schedule` を設定しても `Depth2Pipeline` 内部では常に `forward_shadow` のまま実行されており、backward_shadow の実コードパスを一度も通っていなかった** (`byte_exact_1iter`\u002F`across_refine_ticks` は forward_shadow 同士の比較になり trivial に pass、新規に足した 6-iteration steady-state test だけが偶然 tolerance を超えて fail した)。advisor レビューでの指摘を受けて検証中に発覚。**修正**: `Trainer::host_schedule_backward_shadow` Cell を削除し、`refine_scratch_persist`\u002F`refine_direct_write` と同じ配線パターン (`train_loop` が `backend: &BackendConfig` から直接読み、`Depth2Pipeline::new(trainer, depth, backward_shadow: bool)` に third arg として渡す) に統一した。修正後は 6 本の parity test すべてが実コードパスを通ることを確認済み (CLI 経由の smoke でも `[backend] BackendConfig { ..., host_schedule: BackwardShadow, ... }` のログ行で直接確認 — **CLI 本番経路 [`splat train`] はこのバグの影響を受けていなかった**、`apply_backend_config` は常に呼ばれるため)。",{"type":105,"label":110,"variant":111,"text":112},"副産物: single-texel fixture の複数 iteration 比較は元々 flaky (host_schedule と無関係)","info","配線バグ修正後、6-iteration の steady-state test (`forward_shadow` vs `backward_shadow`、両方 depth2、tick 無しで連続 prefetch) を 8 回走らせたところ **6\u002F8 で `assert_params_close` の tolerance (rel\u003C1e-4) を超えて fail** した。原因は `host_schedule` ではなく、`per_kernel_single_texel_run_to_run_deterministic_1iter` の doc が既に明記していた「iter 2 以降は同一設定を 2 回走らせても atomic 加算順の非決定性で ulp 差が出る」という **fixture 固有の既知の性質** — resync 点 (refine tick 等) が無い長い連続 iteration では、この ulp 差が iteration を追うごとに複利的に効いて、たまたま tolerance を超える。既存の複数 iteration test (`across_refine_ticks` 系) が安定して pass するのは `every=2` 等で頻繁に host 側の同期点が挟まるためで、drift そのものを消しているわけではない。**対応**: steady-state test の iteration 数を 3 に絞り (defer→flush を 2 回連続で踏むには十分)、8\u002F8 pass を確認して確定させた。次にこの fixture で複数 iteration の tight tolerance test を追加する人向けに、この性質を明記しておく。",{"type":56,"text":114},"4. flag 配線と test",{"type":116,"items":117},"list",[118,119,120,121,122,123],"`splat\u002Fcrates\u002Fsplat-train-v1\u002Fsrc\u002Fconfig.rs`: `HostScheduleKind { ForwardShadow (#[default]), BackwardShadow }`、`BackendConfig::host_schedule` field、`validate()` に `host_schedule = \"backward_shadow\"` は `pipelining = \"depth2\"` を要求する hard error を追加 (silent override 禁止規約)","`splat\u002Fcrates\u002Fsplat-train-v1\u002Fsrc\u002Fpipeline.rs`: `Depth2Pipeline::new` が `backward_shadow: bool` を引数で受け取る (§3 の配線修正後の最終形、`Trainer::Cell` は使わない)。`Depth2Pipeline` に `backward_shadow: bool` \u002F `deferred_accumulate: Option\u003CDeferredAccumulate>` を追加。`flush_deferred_accumulate()` を新設し `step()` の手順 4 直後 (手順 5 の前) で常時呼ぶ (no-op if `None`)。`debug_assert_drained()` と `drain()` に deferred flush の防衛的チェック\u002Fflush を追加 (`drain()` の signature が `refine_state` を取るよう変更、呼び出し元は `train_loop.rs` の 1 箇所のみ、この flush は現状の `train_loop` からは到達しない backstop — §5 と同じ理由)","`splat\u002Fcrates\u002Fsplat-train-v1\u002Fsrc\u002Ftrain_loop.rs`: `backend.host_schedule` を直接読んで `Depth2Pipeline::new` に渡す (`refine_scratch_persist`\u002F`refine_direct_write` と同じパターン)。`apply_backend_config` を通らない caller 向けの runtime assert (`pipelining = off` との併用禁止) も `backend` から直接判定するよう統一","`splat\u002Fcrates\u002Fsplat-cli\u002Fsrc\u002Futil.rs`: `apply_backend_config` の exhaustive destructure に `host_schedule: _` を追加 (train_loop が backend 引数から直接消費、という既存 no-op field 記法。追加漏れは compile error になる guard が機能することを `cargo check` で確認)","新規 test 3 本: `pipelining_depth2_backward_shadow_matches_off_across_refine_ticks` (refine every=2 \u002F opacity_reset every=3 \u002F checkpoint iter=5 を跨ぐ 8 iteration、Off と `num_splats` 軌跡・param が一致することを確認 — eager-flush-before-tick の経路を pin)、`pipelining_depth2_backward_shadow_matches_forward_shadow_byte_exact_1iter` (1 iteration では deferred を作る機会が無いので byte-exact)、`pipelining_depth2_backward_shadow_matches_off_steady_state_chain` (tick 無し 3 iteration 連続 prefetch — steady-state の defer→flush→defer→flush chain を forward_shadow と直接比較、§3 で見つけた fixture の flakiness を踏まえ iteration 数を絞って安定化)","既存 `pipelining_depth2_matches_off_*` 系 (byte_exact 1\u002F2iter・refine tick 跨ぎ・A7 direct_write 併用・grad RMW 順序) は **無改変で全 pass** — forward_shadow (default) パスの挙動が一切変わっていないことの regression guard",{"type":56,"text":125},"5. 検証結果",{"type":59,"columns":127,"align":130,"rows":131},[128,129],"検証","結果",[65,65],[132,135,138],[133,134],"`cargo test --workspace --release`","全 pass (splat-metal 91、splat-train-v1 88 [新規 3 本含む]、他クレート含め failure 0)。`cargo test -p splat-train-v1` (debug profile、`debug_assert!` 有効) も全 pass — steady-state chain test が `Depth2Pipeline::step`\u002F`drain` の deferred-flush 不変条件を debug assert 込みで通過することを確認",[136,137],"1000 iter smoke (Lego、`loss=l1_ssim`、`refine.every=100 start=500` → tick 6 回)","off\u002Fon とも `peak_in_flight=2` \u002F `sync_iters=6` \u002F crash なし。PSNR (19.5〜19.6 dB, n=1) と `final splats` (6833〜6896) は off 同士の 2 run 間 (6886 vs 6896) と on 込み (6886 vs 6833) で同程度のばらつき — **atomic 非決定性の範囲内、backward_shadow による correctness regression の兆候なし**",[139,140],"1000 iter smoke の `host_lead`\u002F`cb_gap` p50","off\u002Fon で有意差なし (例: overall `cb_gap` p50 0.242ms [off] vs 0.246ms [on]、`host_lead` p50 -0.187ms [off] vs -0.188ms [on])。**予想通り** — このスケール (splats ~6.9k) では移動した仕事 (grad copy ~248KB + accumulate 6.9k 要素) が 12.5k 規模 (400k splats, 移動量 ~14.4MB + 407µs) の ~1\u002F60 で、shadow への fill 率の変化が計測ノイズに埋もれる。**この smoke は「correctness + plumbing (flag が実際に効いている、drain 不変条件が壊れない)」の確認であり、性能効果の検証ではない** (advisor レビュー指摘どおり、性能検証は 12.5k gate に委ねる)",{"type":56,"text":142},"6. 期待 Δ の再見積り (SSIM を動かしていない前提で)",{"type":88,"items":144},[145,148,151,154,157],{"key":146,"value":147},"12.5k での host 仕事の内訳 (再掲、`p3-c2-bubble-attribution` §4)","forward shadow 2.00ms に対し host 仕事 1.871ms\u002Fiter (fill 93.6%) — 内訳は概ね `ts_refine_accumulate` 407µs + grad copy (`chain.grad_buf` → `Vec\u003Cf32>`, 400k splats で ~14.4MB, 概算 ~150µs) + `read_mean_ssim` (1.92M 要素 CPU f64 sum、最大項と推定) + `read_loss_mean` (無視できる)",{"key":149,"value":150},"本実装が backward shadow (6.38ms、余裕大) に移した分","grad copy (~150µs) + `RefineState::accumulate` (407µs) ≈ **0.55ms\u002Fiter**。`read_mean_ssim`\u002F`read_loss_mean` は動いていない (§1 参照)",{"key":152,"value":153},"forward shadow の fill 率の変化","1.871ms → (1.871-0.55)=1.321ms、fill 率 93.6% → **65%** (2.00ms shadow に対し)",{"key":155,"value":156},"回収できる残差の見積り","残差 (通常境界の bubble、`p3-c2-bubble-attribution` 実測 7.2〜8.1s、wall比 5.8〜6.5%) が host-late (forward shadow からのはみ出し) にほぼ 1:1 で対応するという機構仮説のもとでは、回収量は概ね「動かした host 仕事の割合」に比例する。動かした 0.55ms は元の host 仕事 1.871ms の **29%** — 残差 7.2〜8.1s の 29% ≈ **2.1〜2.3s (wall 124.75s 比 1.7〜1.9%)**。ただし fill 率が 100% を割った時点 (65% \u003C 100%) で理論上ボトルネックが解消されるはずなので、実際の回収はこの比例見積りより大きく出る可能性もある — レンジとして **-1.5〜-3%** とする (`p3-c2-bubble-attribution` の元見積り -3〜-5% は SSIM 総和も動かす前提だったため、それを除いた分だけ保守的に下方修正)",{"key":158,"value":159},"SSIM 総和を動かした場合の追加余地 (未実装、follow-up)","`read_mean_ssim` が host 仕事 1.871ms の中で最大項と推定される (1.92M 要素の f64 sum) ため、これも動かせれば fill 率をさらに大きく下げられ、元の -3〜-5% レンジに近づく可能性が高い。§7 の follow-up 設計 (loss_history の bit-exact 性を保ったまま progress log だけずらす) が前提",{"type":56,"text":161},"7. 未解決点 \u002F 次段への申し送り (gate 前時点、履歴として保持)",{"type":116,"items":163},[164,165,166,167,168],"**12.5k A\u002FB gate (n=3) 実施済み — §8 参照、棄却確定**。gate config は本 finding 記載の 8 本 (r1-r4、r4 は r1 retry) で完了。実測は期待 (-3〜-5%、後に -1.5〜-3% に下方修正) と逆符号で、どの切り出し方でも on≥off (§8 参照、代表値 +5.63% は on-r4 の外れ値に支配されており真の効果量は ~1〜2% とみるのが妥当)","**SSIM host 総和 (最大の未着手候補) の follow-up 設計** — `read_mean_ssim` を動かせば §4 の 1.871ms のうち最大項を狙えるが、`loss_history` の bit-exact 性を保ったまま progress log の per-iteration 帰属だけをずらす追加設計が要る (advisor 提案: `history.push` を 1 slot 遅らせ、loop 末尾で flush する形にすれば `loss_history` は変わらない)。**§8\u002F§9 の gate 結果を踏まえると、この follow-up に着手する前に §9 の『改善が現れなかった理由』(相殺 \u002F shadow 位置ズレ \u002F 効果自体が小さすぎる) を先に切り分けるべき** — 施策 #1 単体で期待した改善が測定できなかった以上、同じ設計方針を延長した SSIM 総和 deferral も同程度に測定できない可能性が高い","`prefetched == false` の iteration (grad RMW \u002F MCMC noise \u002F refine tick 自体) は元々 deferral の対象にならない — 「sync iteration が続くと恩恵が無い」「refine tick iteration 自身の accumulate は同期のまま」は設計上の意図であり compromise ではない (`HostScheduleKind::BackwardShadow` doc 参照、次に読む人が『直す』対象と誤解しないよう明記)","**gate run 完了 — `p3-c2-bubble-attribution` §6 施策 #1 の verdict は「棄却」で確定。`[backend] host_schedule` の default (ForwardShadow) は変更しない。`.rs` は一切触っていない**","**(参考、実施していない) 仮に採用判定だった場合の flip 実装は 3 行の単純作業ではなかったことが判明した** — 詳細 §10。次に同種の default flip を判断する人向けの申し送り",{"type":56,"text":170},"8. 12.5k A\u002FB gate (n=3、2026-08-30) — 棄却確定",{"type":88,"items":172},[173,176,179,182,185,188],{"key":174,"value":175},"binary provenance","HEAD `5ef49c4a8aaccb42e9cf4f7df2cbf7fbf3ad7157` (直前の実装 merge commit `9cc5278` から docs-only 1 commit 進んだ状態、`.rs` 差分ゼロを `git diff --name-only` で確認済み)。binary sha256 `38ca2d6d732fc3f9d7efe3246f1a70f07891ba88fe5245bf71f098f3b96e8b72`、series 前後 (主系列・retry とも) 不変を driver ログで確認。`cargo build --release` は 0.06s で完了 (既存 binary が最新、再ビルド不要)",{"key":177,"value":178},"電源 \u002F GPU 権","AC 接続 (`pmset -g batt` で series 通じて `AC Power`)。起動前に `pgrep -fl \"target\u002Frelease\u002Fsplat\"` で他 agent の GPU run 無しを確認 (空)",{"key":180,"value":181},"ambient load (series 開始時)","1.64 \u002F 2.00 \u002F 2.26 (通常範囲)。`LOAD_LIMIT=6.0` \u002F `QUIESCE_MAX=90` の default を変更せず使用 (ambient に十分な余裕があったため)",{"key":183,"value":184},"driver","`splat\u002Fscripts\u002Fgate-ab-n.sh configs\u002F2026-08-30-s4-12500-off configs\u002F2026-08-30-s4-12500-on s4-12500 3` (主系列、ABABAB 順)。r1 pair のみ `splat\u002Fscripts\u002Fretry-pair-s4-r4.sh` (新規、`retry-pair-r6.sh` と同型) で個別 retry",{"key":186,"value":187},"flag 実測確認 (6\u002F6 主系列 + 2\u002F2 retry)","全 8 run の `[backend] BackendConfig { … }` ログ行から `host_schedule` を抽出し、off 系 4 run 全て `ForwardShadow`、on 系 4 run 全て `BackwardShadow` を確認 (§3 で発覚した配線バグの再発なし、`train_loop` のログ行 `host_schedule = forward_shadow|backward_shadow (C2\u002FS4)` でも二重確認)",{"key":189,"value":190},"判定規則 (事前登録、`runs-logs\u002Fs4-12500-predecision.log` に全文)","採用条件 = wallclock (Δ ≤ -max(2σ_off,1%)) AND PSNR guard (on mean ≥ off mean - 0.05dB) の AND。retry は最大 1 pair のみ、かつ (i) load 証拠 AND (ii) 自 arm 内 3σ超 が同時成立する場合に限る (`p3-tier1-bit-exact` §5-6 の「条件 (ii) 単独では停止できない除外連鎖」教訓を踏まえ AND を必須にした)",{"type":59,"columns":192,"align":200,"rows":202},[193,194,195,196,197,198,199],"実行順","arm","run","train elapsed (s)","PSNR (dB)","run 窓内 load1 平均\u002F最大","備考",[65,65,65,201,201,201,65],"right",[203,211,219,226,232,238,244,251,258,265,269],[204,205,206,207,208,209,210],"1","off (A)","s4-12500-off-r1","129.23","36.159","2.72 \u002F 7.91","**CONTAMINATED、破棄** (load1 max 7.91 が LOAD_LIMIT 6.0 超、自 arm 内 3σ 超も該当 — (i)(ii) 双方成立)",[212,213,214,215,216,217,218],"2","on (B)","s4-12500-on-r1","128.53","36.176","4.47 \u002F 8.90","**CONTAMINATED、破棄** (同一 pair、load1 max 8.90 も LOAD_LIMIT 超。ペア単位で retry)",[220,205,221,222,223,224,225],"3","s4-12500-off-r2","125.41","36.151","1.89 \u002F 2.89","採用",[227,213,228,229,230,231,225],"4","s4-12500-on-r2","126.39","36.163","2.39 \u002F 3.64",[233,205,234,235,236,237,225],"5","s4-12500-off-r3","124.62","36.239","1.51 \u002F 1.84",[239,213,240,241,242,243,225],"6","s4-12500-on-r3","128.19","36.215","2.63 \u002F 4.47",[245,205,246,247,248,249,250],"7 (retry)","s4-12500-off-r4","125.19","36.131","1.81 \u002F 2.35","r1 の代替として採用、load 終始 clean",[252,213,253,254,255,256,257],"8 (retry)","s4-12500-on-r4","141.77","36.225","1.64 \u002F 3.19","r1 の代替として採用。**大外れ値 (on 他 2値から見て統計的に大きく外れる) だが load は終始 clean (max 3.19) — 事前登録条件 (i) 不成立のため追加 retry せず、そのまま採用**。ms\u002Fiter trace は iter 2000 以降一貫して on-r3 より高い (discrete spike ではなく持続的、A7 §7 off-r3 と同型の GPU thermal 蓄積の可能性、host_schedule 由来と特定する根拠はない)",[259,260,261,262,263,264,261],"**mean (n=3、r1→r4 置換)**","**off**","—","**125.073** (σ 0.326%)","**36.174**","series 独立 load sampler 最大値 8.90 (r1 pair、破棄分)。採用 4 run のみなら load 終始 6.0 未満",[259,266,261,267,268,261,261],"**on**","**132.117** (σ 6.36%)","**36.201**",[270,261,261,271,272,261,273],"**Δ**","**+5.63%**","**+0.027**","閾値 max(2σ_off,1%)=1% を大きく外れて不通過 (符号も逆)",{"type":105,"label":275,"variant":107,"text":276},"判定 — 棄却確定 (wallclock がどの扱いでも符号込みで不通過、PSNR guard の pass は判定を左右しない)","wallclock: 採用セット (r1→r4 置換) の Δ は **+5.63%** (on が off より遅い) で「Δ ≤ -1%」の採用条件と符号が逆。ただし\u003Cstrong>この数字を効果量の代表値として扱ってはいけない\u003C\u002Fstrong> — on-r4=141.77s という単一の大外れ値 (on 他 2 値 126.39\u002F128.19 から大きく外れる) がほぼ全てを支配しており、on-r4 を除くと Δ は +1.8%、retry 前の r1 込み n=3 でも +1.02% と、\u003Cstrong>どの切り出し方でも符号は一貫して不通過だが、大きさは ~1〜2% (σ_on 6.36% の分解能付近) と見るのが妥当\u003C\u002Fstrong> — `p3-tier1-bit-exact` v1 が「off arm 汚染で -4.99% が見かけ上膨らんでいた (真の効果量は ~1%)」と自己反証した構図の符号違い版である。3\u002F3 pair (採用セット) とも on>off で一貫 (r2 +0.78%、r3 +2.86%、r4 +13.24%) — \u003Cstrong>一貫性はあるが「施策が効いている」ではなく「施策が一貫してわずかに悪化させている」ことを示す一貫性\u003C\u002Fstrong>。破棄した r1 pair は逆に on<off (on が速かった) であり、4 pair 全体では 3\u002F4 が on>off ― 採用セットの「3\u002F3 一貫」を全体の一貫性と誤読しないこと。PSNR guard (+0.027dB) は形式的に pass するが wallclock が既に不通過なので AND 判定全体としては不通過。\u003Cstrong>採用しない。`[backend] host_schedule` の default (`ForwardShadow`) は変更せず、`.rs` は一切変更していない\u003C\u002Fstrong>。",{"type":105,"label":278,"variant":111,"text":279},"on-r4 の大外れ値 — retry の連鎖はしない (tier1 §5-6 の教訓の実地適用)","on-r4 (141.77s) は on 系列の他 2 値 (126.39s, 128.19s) から見て統計的に大きく外れている。しかし独立 load sampler は on-r4 の run 窓内で終始 clean (mean 1.64, max 3.19、LOAD_LIMIT 6.0 を一度も超えない) であり、事前登録した retry 条件の (i) (load 証拠) を満たさない。`p3-tier1-bit-exact` §5-6 が明記した教訓 (「自 arm 内 3σ超」単独でのretryは停止条件のない除外連鎖になり得る) をそのまま適用し、追加 retry はしない。ms\u002Fiter trace を on-r3 (同一 config、対照的に正常) と比較すると、on-r4 は iter 2000 (5.4 vs 4.7 ms\u002Fiter) から一貫して高く、iter 12500 時点でも 13.1 vs 12.2 ms\u002Fiter — discrete spike ではなく持続的な劣化パターンで、`p3-refine-3pass` §7 の off-r3 (GPU thermal throttling 疑い) と同型。この session では合計 8 本の 12.5k full run (r1×2 + r2×2 + r3×2 + r4×2) を連続実行しており、終盤の run ほど GPU 熱蓄積の影響を受けやすい一般的リスクはあるが、\u003Cstrong>host_schedule=backward_shadow 由来と特定する直接証拠はなく、むしろ off 側にも同型の劣化が既に他 gate (`p3-refine-3pass` off-r3) で観測されている\u003C\u002Fstrong>ため、config family 共通のノイズ源として扱う。仮に on-r4 を外れ値として除外し on 系列を r2\u002Fr3 の 2 値だけで評価しても mean 127.29s (Δ +1.82%) となお逆符号で不通過であり、\u003Cstrong>on-r4 を含めるか除外するかで結論 (棄却) は変わらない\u003C\u002Fstrong>。",{"type":105,"label":281,"variant":111,"text":282},"開示 1 — retry 条件 (i) は max ベースで評価した (mean だと off-r1 は非該当)","事前登録した条件 (i) 「load1 が series 中央値の 1.5倍超」は mean\u002Fmax のどちらで評価するかを predecision log 上で明記していなかった。実際の判定は **run 窓内 load1 の max** で行った (off-r1 max 7.91 \u002F on-r1 max 8.90、いずれも series 全 run の max の中央値 4.055 の 1.5倍=6.08 を超過)。**mean ベースで再評価すると off-r1 (mean 2.72) は series 全 run の mean の中央値 2.51 の 1.5倍=3.765 未満で非該当**になり、pair 破棄を単独で licenseするのは on-r1 (mean 4.47 > 3.765、こちらは mean でも該当) 側だけになる。ペア単位retryのため実務上の判断 (r1 pair 全体を破棄) は変わらないが、次回の predecision log では「(i) は mean\u002Fmax のどちらで評価するか」を事前に明記すべき、という運用上の教訓として記録する。",{"type":105,"label":284,"variant":111,"text":285},"開示 2 — 実行順は ABAB (ABBA 均衡化なし)、on arm は常に後attackで走る","6 pair とも off→on の順で実行しており (`gate-ab-n.sh` の固定 ARM_SEQ)、ABBA 的なカウンターバランスはしていない。そのため on arm は常に同一 pair 内で「後に (=機体がより温まった状態で)」走る構造的バイアスの可能性を排除できない — 最も遅い run (on-r4) が系列終盤かつ on 側であることはこの仮説と整合する。ただし同一 config family・同じ ABAB 順で行った `p3-refine-3pass` gate (a7v2-12500) では on 側 (改善案) が一貫して off 側より速く出ており、このバイアスが支配的でないことも示唆される。次回の gate 設計では ABBA 順の採用を検討する価値がある、という申し送り。",{"type":56,"text":287},"9. 施策の効果が現れなかったことの解釈 — 推測、追加検証はしていない",{"type":116,"items":289},[290,291,292],"§8 の再検討通り、実測の効果量は ~1〜2% (null〜わずかな悪化) であり、+5.63% という大きな悪化ではない。説明が必要なのは『なぜ大きく悪化したか』ではなく『なぜ §6 が見積もった -1.5〜-3% の改善が (悪化さえせず) 全く現れなかったか』である。§6 の比例モデル (「動かした host 仕事 0.55ms\u002Fiter が forward shadow の fill 率を 93.6%→65% に下げれば、その分だけ残差 bubble が回収される」) はこの規模の gate では支持されなかった","候補仮説 (未検証、次段の追加調査候補、大きな悪化ではなく『改善が相殺された』前提で立て直したもの): (a) `chain.grad_buf` を 1 iteration retain することで生じる追加の host 側分岐\u002F状態管理コスト (`Depth2Pipeline` の `Option\u003CDeferredAccumulate>` 管理、`flush_deferred_accumulate()` の呼び出し自体) が、移動した 0.55ms\u002Fiter の節約分とほぼ相殺している、(b) `flush_deferred_accumulate()` の実際の実行位置が想定 (`B_{it+1}` の 6.38ms shadow の中で十分に隠れる) からズレており、期待したほど shadow に収まっていない、(c) 1000 iter smoke (§5) で host_lead\u002Fcb_gap に有意差が出なかったのと整合的に、12.5k でも同程度のスケールでは施策の影響自体が測定ノイズ (σ_on 6.36%) に埋もれる程度しかない、という『そもそも効果が小さすぎる』仮説","本 finding はこれらの仮説を検証していない — 棄却が確定した以上、追加コストをかけて機序を特定する優先度は低いと判断し、次段の判断 (main) に委ねる",{"type":56,"text":294},"10. (参考、実施していない) default flip の実装上の注意 — 単純な 3 行変更ではない",{"type":105,"label":296,"variant":111,"text":297},"本 gate は棄却のため .rs は一切変更していない。以下は次に同種の default flip を判断する人への申し送り","採否を判断する過程で `host_schedule` の default を `BackwardShadow` に flip する実装可否を検討したところ、単純な `#[default]` 属性移動 + `BackendConfig::default()` 変更では済まないことが判明した。(1) `host_schedule` field には field-level `#[serde(default)]` が付いている (`splat-train-v1\u002Fsrc\u002Fconfig.rs`) — struct-level `#[serde(deny_unknown_fields, default)]` と併存する場合、field-level 側が優先され、TOML で省略された値は `BackendConfig::default()` の literal ではなく `HostScheduleKind::default()` (enum 側の `#[default]` 属性、現在は `ForwardShadow`) から解決される。これは `refine_scratch_persist`\u002F`target_cache` の bool field が field-level `#[serde(default)]` を意図的に付けていない理由 (`bool::default()`=false で struct 側の true を上書きしてしまう) と同型の罠で、enum でも同じ罠が成立する — flip するなら enum の `#[default]` 属性そのものを移動する必要があり、`BackendConfig::default()` の literal だけ変えると TOML 経由の default と Rust 構築の default が silently 分岐する。(2) enum の `#[default]` を移動してもなお、`pipelining = \"off\"` を明示し `host_schedule` を省略する既存 config が `splat\u002Fconfigs\u002F` に **37 本**確認できる (`grep -rln 'pipelining\\s*=\\s*\"off\"' splat\u002Fconfigs\u002F`) — これらは flip 後、省略された `host_schedule` が新 default (`BackwardShadow`) に解決され、`BackendConfig::validate()` の hard error (`host_schedule = \"backward_shadow\" (C2\u002FS4) requires pipelining = \"depth2\"`, config.rs:652 付近) で **一括して壊れる**。container-level default は他 field の値に条件分岐できない (`BackendConfig::default()` は静的な struct 一つ) ため、field 自体の default 値だけでこの依存関係を解決することはできない。(3) 解決の方向性として、`splat-cli\u002Fsrc\u002Fcmd\u002Fbench.rs` の `demote_unspecified_pipelining` (raw TOML 文字列を line scan して `pipelining` が明示されているかを判定し、未指定なら `Off` に demote する) と同型のイディオムが既に存在する — これを `host_schedule` 版として実装し `pipelining != Depth2` かつ raw TOML に `host_schedule` の明示行が無い場合だけ `ForwardShadow` に demote する仕組みを、bench 経路だけでなく **train 側の config load path (`splat-cli\u002Fsrc\u002Fconfig.rs::FullConfig::from_toml_str`)** にも追加する必要がある (bench 側の関数は bench 経路にしか適用されない)。この demote は「明示された `backward_shadow` + `pipelining=\"off\"`」の組合せは引き続き hard error にする (silent override 回避の規約を保つ) 設計にすること。以上は次に flip を判断する人が同じ調査をやり直さずに済むよう記録するもので、本 finding の棄却判定そのものには影響しない。",[],[300,325,350],{"id":42,"title":301,"date":9,"status":10,"polarity":302,"category":303,"axes":304,"tags":305,"task_code":316,"related_runs":317,"delta_psnr":319,"delta_wallclock":320,"rank":321,"verdict":322,"impact_summary":323,"detail_path":324},"C2 実測 — 残差 bubble は host-late 支配 (7.2〜8.1s)、refine tick drain は A7 で半減済み (3.0〜3.8s)。handoff は定常帯で headroom ほぼ無し","mixed","measurement",[14,15],[18,306,307,308,309,310,311,312,313,314,315],"gap-report","cb-gap","host-lead","drvproc","handoff","residual-bubble","refine-drain","post-m4-a7","lego","measurement-only","C2: 12.5k の残差 bubble 帰属計測と分析",[318],"c2-12500-depth2-prof","n=1 self-eval: 36.068 dB (100 views)。C2 は測定目的の run で PSNR gate 対象ではないが、p3-final-stack の n=3 mean (36.219 dB) からの乖離は n=1 ノイズ帯として妥当な範囲","train elapsed 124.75s (n=1)。p3-final-stack n=3 mean 124.393s (σ0.756%) の guard 内 — profile=true + gap report 計装のオーバーヘッドは計測可能な歪みを生んでいない、と読める","high","residual-is-host-late-dominated \u002F handoff-headroom-thin \u002F refine-drain-already-halved-by-a7","`p3-kernel-share-post-s3.toml` §4\u002F§8 の宿題 (「残差は既存計装では分解不能、実装後も 12.5k 実測がまだ無い」) を、`2026-08-30-c2-12500-depth2-prof.toml` (M4+A7 default 込み、S3 gate arm B と [backend] bit-exact) の 1 run で埋めた。\u003Cstrong>reliable=true \u002F dropped=0 \u002F kernel_invalid=0 \u002F sum\u002Funion=1.000000x\u003C\u002Fstrong> — 信頼性ゲート健全、全列使用可。wall 124.75s \u002F busy 113.627s (91.1%) \u002F sync-tax 11.126〜11.129s は `p3-final-stack` の n=3 mean (124.393s, σ0.756%) の guard 内 (n=1 の点推定として妥当)。\u003Cstrong>Σcb_gap=11.085s が sync-tax 全量の 99.6% を説明\u003C\u002Fstrong>し、`p50×n` (band 別合計 7.244s) と `mean×n` (11.081s) の差 3.837s を refine tick 由来の外れ値と読むと、\u003Cstrong>残差 (通常境界) 7.2〜8.1s (5.8〜6.5%) \u002F refine tick drain 3.0〜3.8s (2.4〜3.1%)\u003C\u002Fstrong> にブラケットできる。refine 側は `ts_refine`(2.869s)+`ts_opacity_decay`(0.185s)=3.054s の独立 host 実測が下限とほぼ一致し、クロスチェックが成立した。\u003Cstrong>旧 3 分解 (refine 6.26s \u002F encode(B) 3.41s \u002F 残差 4.54s、旧 sync-tax 全量 14.206s) との整合\u003C\u002Fstrong>: 旧「残差」+「encode(B)」= 4.54+3.41=7.95s ≈ 新「通常境界」7.24s (wall が 151.70→124.75s に縮んだ分を割り引けば近い) — \u003Cstrong>旧 encode(B) バケツは独立した加算成分ではなく、非重複だった encode コストが host-late として `cb_gap` に同じ形で現れていた\u003C\u002Fstrong>と判明し、旧 3 分解を「refine drain \u002F それ以外 (通常境界)」の 2 分解へ訂正する形になった。\u003Cstrong>帰属の結論: 通常境界の bubble は host-late が支配的、driver 処理 (`drvproc`) と GPU キュー待ち (`handoff`) は定常帯で中央値がほぼゼロ (headroom 薄い)\u003C\u002Fstrong> — task が例示した「handoff → CB 統合」は主因ではないと実測が明示的に否定した。","\u002Ffindings\u002Fp3-c2-bubble-attribution\u002F",{"id":44,"title":326,"date":9,"status":10,"polarity":327,"category":11,"axes":328,"tags":329,"task_code":338,"related_runs":339,"delta_psnr":345,"delta_wallclock":346,"rank":321,"verdict":347,"impact_summary":348,"detail_path":349},"M7 最終スタック確定 — 12.5k 124.39s (独立 n=3)、msplat 等価 gap 0.927×→0.755×、throughput 1.135×負け→0.926× (msplat 側 avg splats 借用値 ±8% 未満なら逆転)","positive",[14,15],[330,331,332,333,334,335,314,336,337],"m7","seminar05-milestones","final-stack","msplat-parity","pareto-v3","throughput-parity","gpu-gate","independent-remeasurement","2026-09-seminar05-milestones M7 (最終スタック確定 + msplat 等価再比較 + Pareto v3)",[340,341,342,343,344],"final-12500-r1","final-12500-r2","final-12500-r3","final-12500-r4","c1v2-12500-off-prof","12.5k self-eval (r2-r4 n=3 mean): **36.219 dB** (σ 0.046%)、baseline guard 36.202±0.1dB 内。brush cross-eval q8 (r2-r4 mean): **36.249 dB** (msplat 30K 保守値 34.243 比 **+2.006dB**、旧 +1.97dB とほぼ不変)。white cross-eval (r2-r4 mean): **35.147 dB** (msplat 30K cross-eval 最小 36.252 比 **-1.105dB**、旧 -1.10dB とほぼ不変)","12.5k train elapsed 独立 n=3 (r2\u002Fr3\u002Fr4、clean set): **124.393s (σ 0.756%)**。A7 gate on-arm mean (124.807s) を **-0.33%** で再現。msplat 等価 gap (block1 n=2 分母 164.69s): **0.755×** (旧 0.927×)。per-splat·iter throughput: 本実装 **30.94ns** vs msplat 33.4ns = **0.926×** (旧 1.135×負けから逆転)","final-stack-confirmed-msplat-gap-0.755x-throughput-parity-crossed-pending-msplat-avg-splats-recheck","2026-09-seminar05-milestones M7 を実施した。(1) **12.5k full run 独立 n=3**: `2026-08-30-final-12500-r{1,2,3}.toml` を単純 3 repeat (off arm なし、全 [backend] flag は default 任せ = M4 radix_scatter=SimdBallot + A7 refine_scratch_persist\u002Frefine_direct_write=true 込み) で実行。r1 (131.84s) が r2\u002Fr3\u002Fr4 (123.34\u002F124.69\u002F125.15s) から外れて見えたため、advisor レビューを経て診断用の r4 を追加実行した結果、**r1 は script 再起動時に load sampler window ログが truncate され窓内記録が皆無**という house 規約 (p2-msplat-parity-final §7「事前 gate だけでは不十分、窓内記録が必須」) 上の欠陥を抱えていたことが判明し、r2\u002Fr3\u002Fr4 (全 run とも window 記録あり、load 正常) を正式な n=3 として採用した。**mean 124.393s (σ 0.756%)** — A7 gate on-arm mean 124.807s を -0.33% で独立再現しており、この近さ自体が両 session の健全性証拠になる。r1 込みの参考値 (n=3 リテラル\u002Fn=4 全部) も §1 に残す。(2) **per-kernel share v2**: `2026-08-30-c1v2-12500-off-prof.toml` (submission=per_kernel\u002Fforward_submission=per_stage\u002Fpipelining=off、M4\u002FA7 default 込み) を 1 run。leaf gpu_ms 合計 114.508s は busy union と exact 一致。radix share 26.40%→12.01% (絶対 -63.25%、M4 gate の per_stage 補助計測 -63.7% と独立一致)、backward_raster が単独最大ブロックとしてさらに優位 (33.86%→40.07%)。詳細は `p3-kernel-share-post-s3.toml` §6 に追記。(3) **累計 ablation**: p2 の 8 段 (Phase0 766.07s → S3 151.70s) に M4 (127.53s、-14.9%) \u002F A7 (124.81s、-2.15%) \u002F M7 独立再計測 (124.39s、-0.33%、ほぼ noise level) を継ぎ足し、Phase 0 比 **-83.76%**。(4) **msplat 等価再比較**: p2-msplat-parity-final の計算手順を最終値で再計算。gap 分母は継続性のため block1 n=2 mean (164.69s) を維持 (msplat 側は再実行していない)。**wallclock gap 0.927×→0.755×**。throughput は avg splats を新 4 run の trapezoid 積分から自前算出 (321,637、旧値 322k とほぼ一致し手法の妥当性を裏づける) して **1.135×負け→0.926×勝ち** (ただし msplat 側 avg splats ~165k は p2 からの借用値で本 session では再導出できておらず、逆転が成立するのはこの借用値の誤差が +8.0% 未満の場合に限る、§4 callout 参照)。brush\u002Fwhite PSNR は既存 final.ply に対し `splat eval` を回して再計測し (新規 GPU 学習 run は不要)、両 convention とも旧値からほぼ不変 (brush +2.01dB \u002F white -1.11dB) — M4\u002FA7 は PSNR trajectory に理論上影響しない施策なので想定どおり。matched-iteration (30K vs 30K) \u002F matched-wallclock (旧 13.3k 点) \u002F matched-PSNR(brush) の旧 6.0k 点 \u002F energy は**新規 GPU run が必要なため本 session では再計測せず**、旧スタック値を明示ラベルで carry forward するに留めた (外挿スケーリングによる偽の精度を避ける、advisor レビュー指摘)。(5) **Pareto v3**: `make_msplat_pareto.py` の入力を msplat 等価比較 4 点 Pareto curve (p2-msplat-parity-final §10 の未実施項目) に更新し `docs\u002Ffigures\u002Fpareto-v3-msplat-lego-final-stack.png` を生成。12.5k 点のみ最終スタック値、他 3 点 (6.0k\u002F13.3k\u002F30k) と msplat は旧スタック値のまま明示ラベル。","\u002Ffindings\u002Fp3-final-stack\u002F",{"id":43,"title":351,"date":352,"status":10,"polarity":327,"category":11,"axes":353,"tags":354,"task_code":364,"related_runs":365,"delta_psnr":376,"delta_wallclock":377,"rank":321,"verdict":378,"impact_summary":379,"detail_path":380},"S3 iteration pipelining depth 2 — 12.5k -18.1% \u002F busy 78 → 91% (default flip)","2026-08-17",[14,15],[355,356,357,358,359,360,361,362,314,363],"1x-roadmap-v2","s3","iteration-pipelining","command-buffer","gpu-busy","sync-tax","double-buffering","scratch-generation","unified-memory","2026-08 1× 工程表 v2 — AC 復帰後 計測 queue #2' (S3 gate)",[366,367,368,369,370,371,372,373,374,375],"s3-smoke-1000-off","s3-smoke-1000-depth2","s3-12500-off-prof","s3-12500-depth2-prof","s3-12500-off-r1","s3-12500-off-r2","s3-12500-off-r3","s3-12500-depth2-r1","s3-12500-depth2-r2","s3-12500-depth2-r3","12.5k **同一 session 交互 A\u002FB** n=3 mean: depth2 **36.202 dB** (36.195 \u002F 36.179 \u002F 36.231) vs off **36.185 dB** (36.178 \u002F 36.192 \u002F 36.186) = **+0.016 dB** (guard 36.167 ± 0.1 の内側、n=3 mean 判定 — n=1 判定なし)。final splats は depth2 406,439 \u002F off 408,874 で **depth2 のほうが 0.6% 少ない** (前段の profile pair では逆に +0.6% で、方向が一致しない = 既存 atomic 非決定性の chaos 増幅の範囲)","12.5k full run **同一 session 交互 A\u002FB n=3 mean: 185.21 → 151.70s = -18.1%** (train elapsed)。process wallclock では **188.33 → 154.00s = -18.2%**。σ は off 3.33% \u002F depth2 1.18% なので有意閾値 max(2σ,1%) = 6.7%、実測 Δ は**その 2.7 倍**。同一 session の off arm は S2 gate 当日の S2 arm (train 184.61s \u002F process 187.65s) を **+0.3% で再現**しており、session の健全性が確認できている。参考: profile=true の 1 対 1 比較では 180.49 → 162.72s = -9.85% (計装自体が host 側 critical path に乗るため S3 の効果を過小評価する)","s3-adopted-default-flip-pipelining-depth2","1× 工程表 v2 が「S2 後の単独本命」に指定していた S3 を gate し、採用した。S2 までの施策が \u003Cstrong>CB の数\u003C\u002Fstrong>を減らすものだったのに対し、S3 は \u003Cstrong>CB の並び方\u003C\u002Fstrong>を変える — iteration N の loss\u002Fbackward CB (B\u003Csub>N\u003C\u002Fsub>) を commit したら wait せずに iteration N+1 の forward CB (F\u003Csub>N+1\u003C\u002Fsub>) を組んで commit し、\u003Ccode>wait(B\u003Csub>N\u003C\u002Fsub>)\u003C\u002Fcode> の後の host readback \u002F \u003Ccode>accumulate\u003C\u002Fcode> を F\u003Csub>N+1\u003C\u002Fsub> の GPU 実行の影に置く。\u003Cstrong>12.5k 同一 session 交互 A\u002FB n=3 で 185.21 → 151.70s = -18.1%\u003C\u002Fstrong> (閾値 max(2σ,1%) = 6.7% の 2.7 倍)。\u003Cstrong>GPU busy 77.5 → 91.3% \u002F sync-tax 3.244 → 1.136 ms\u002Fiter (-65%)\u003C\u002Fstrong> で counter session が置いた「busy 100% = 理論上限」への距離は 22.5 pt → 8.7 pt に縮んだ。\u003Cstrong>1k smoke では busy 65.8 → 72.0% にしか上がらず判定不能だった\u003C\u002Fstrong> — smoke の splat 数 6.8k では forward の GPU 影 (1.06 ms\u002Fiter) が image size 固定の host 仕事 (~1.7 ms\u002Fiter) を隠しきれないためで、これは \u003Cstrong>「pipelining の gate は smoke では代替できない」という harness 上の教訓\u003C\u002Fstrong>として残す。残 bubble の内訳も確定した: \u003Cstrong>refine tick の drain 6.04s (43%) > encode(B) 4.66s (33%) > 残差 3.28s (23%)\u003C\u002Fstrong> — 次の一手が roadmap の「即効ペア (refine capacity スコープバグ修正)」であることが実測で決まった。msplat 同日等価 gap \u003Cstrong>1.105× → 0.907×\u003C\u002Fstrong>、Phase 0 からの累計 766.07 → 154.0s = \u003Cstrong>-79.9%\u003C\u002Fstrong> (全て数学的同値の施策のみ)。","\u002Ffindings\u002Fp2-s3-iteration-pipelining\u002F",1790227327661]