[{"data":1,"prerenderedAt":545},["ShallowReactive",2],{"finding:p3-kernel-share-post-s3":3,"finding-runs:p3-kernel-share-post-s3":468,"finding-related:p3-kernel-share-post-s3":486},{"meta":4,"impact":42,"sections":48},{"id":5,"title":6,"subtitle":7,"eyebrow":8,"date":9,"status":10,"category":11,"polarity":12,"axes":13,"tags":16,"task_code":30,"commit":31,"branch":32,"config_paths":33,"related_runs":36,"related_findings":39},"p3-kernel-share-post-s3","M1\u002Fv2 — post-S2\u002FS3 per-kernel share 再計測: backward_raster 33.9%→40.1% (M4\u002FA7 後)、radix 26.4%→12.0% (M4 の絶対削減を反映) → M3 GO 判定は不変。C2 残差 4.54s は driver latency \u002F CB gap に分解不能 (計装欠如、file:line 提案のみ)","C1: `submission = per_kernel` \u002F `forward_submission = per_stage` \u002F `pipelining = off` (radix_scan = gpu_hierarchical \u002F binning = resident は現 default のまま) で 12.5k Lego を 1 run。leaf label の gpu_ms 合計 141.716s は `gpu_busy_stats()` の union 141.716s と\u003Cstrong>誤差 0.3ms で一致\u003C\u002Fstrong> (per_kernel\u002Fper_stage は commit+wait 境界が kernel 境界と一致するため、chained 由来の二重計上が原理的に起きない)。\u003Cstrong>backward_raster (+project_back、bit 同値のため 1 行に統合) 33.86%\u003C\u002Fstrong> > radix 26.40% > adam 12.68% > rasterize 11.64% > ssim(+l1_combine) 11.80% > project(+emit+extract_off) 3.61%、refine\u002Fzero_grads は host 実コストがありながら **GPU 側 gpu_ms が 0** に落ちる (非ブロッキング harvest の帰属漏れ、既知の限界)。\u003Cstrong>M3 の GO 閾値 (≥25%) を 33.86% で超過 → per-splat backward 実装へ進む根拠が立った\u003C\u002Fstrong>。C2 は M0 (並行 doc 修正 c8864c8) が発見した会計訂正後の depth2 残差 sync-tax 内訳 \u003Cstrong>refine drain 6.26s (44%) \u002F encode(B) 3.41s (24%) \u002F 残差 4.54s (32%)\u003C\u002Fstrong> を出発点に、残差 4.54s のさらなる driver-latency \u002F CB間-gap 分解を試みたが、\u003Cstrong>`gputime.rs` は `kernelStartTime`\u002F`kernelEndTime` を bind しているだけで収集していない\u003C\u002Fstrong> (Collector は `GPUStartTime`\u002F`GPUEndTime` のペアのみ保持) ため、既存計装では分解不能と判明。file:line 付きで追加案を残す (実装はしていない)。","2026-09 ゼミ milestones · M1\u002FM7 · C1 per-kernel 再計測 (v1+v2) + C2 残差帰属","2026-08-30","stable","measurement","mixed",[14,15],1,3,[17,18,19,20,21,22,23,24,25,26,27,28,29],"m1","m7","seminar05-milestones","kernel-share","per-kernel-gpu-ms","backward-raster","m3-go-gate","residual-bubble","gputime","lego","post-s2-s3","v2","post-m4-a7","2026-09-seminar05-milestones M1 (C1 per-kernel 再計測 + C2 残差 bubble 帰属)","705e3f8","main",[34,35],"splat\u002Fconfigs\u002F2026-08-30-c1-12500-off-prof.toml","splat\u002Fconfigs\u002F2026-08-30-c1v2-12500-off-prof.toml",[37,38],"c1-12500-off-prof","c1v2-12500-off-prof",[40,41],"p2-counter-session","p2-s3-iteration-pipelining",{"summary":43,"rank":44,"verdict":45,"delta_psnr":46,"delta_wallclock":47},"M3 (per-splat backward, brush PR #401 型) の GO\u002FNO-GO 閾値「backward_raster share ≥ 25%」を判定した。post-S2\u002FS3 kernel (hierarchical radix scan \u002F resident binning) を submission=per_kernel\u002Fforward_submission=per_stage\u002Fpipelining=off (per-kernel breakdown が測れる唯一の regime) で 1 run 実測した結果 \u003Cstrong>backward_raster (+project_back 統合) share 33.86%\u003C\u002Fstrong> で \u003Cstrong>閾値を大きく超過 → M3 は GO\u003C\u002Fstrong>。\u003Cstrong>share × 0.25 (brush の -25% 主張をそのまま適用したナイーブな期待値) = 8.47%\u003C\u002Fstrong>。ただしこれは本 run の GPU busy (68.9%、production の 91.3% とは別 regime) に対する share であり、production (depth2 default) の wallclock に対する期待 Δ は \u003Cstrong>33.86% × 91.3% × 0.25 ≈ 7.7%\u003C\u002Fstrong> とみるほうが妥当 (kernel 自体の gpu_ms は submission wrapping にほぼ不変という counter-session の事後検証はあるが、n=1 点推定であることと合わせて上限値として扱う)。\u003Cstrong>pre-S2\u002FS3 (counter-session) との比較では share 構成はほぼ不変\u003C\u002Fstrong> (backward_raster 33.6%→33.86%、radix 26.3%→26.40%、rasterize 11.9%→11.64%、adam 13.8%→12.68%、ssim 10.0%→10.95%) — S2 のhierarchical scan は「radix の CB\u002Fwait 数」を畳んだだけで kernel 自体の GPU 時間配分は変えていない、という roadmap の当初の想定を実測で裏づけた。C2 は M0 の並行会計訂正 (encode(B) 4.66→3.41s、残差 3.28→4.54s、nested label 二重計上の是正) を踏まえ、\u003Cstrong>残差 4.54s (depth2 sync-tax の 32%) を driver 投入 latency と CB 間 gap に分解しようとしたが、既存計装 (`gputime.rs`) は `kernelStartTime`\u002F`kernelEndTime` を objc bind しているのみで収集しておらず、per-CB の生 interval 列も外部に露出していない\u003C\u002Fstrong> ため\u003Cstrong>分解不能\u003C\u002Fstrong>と判明した。file:line 付きの追加案を §C2 に残す (実装はしていない、GPU run はこれ以上起動していない)。","high","m3-go-backward-raster-33.9pct \u002F c2-instrumentation-gap-proposal-only","n=1: 36.087 dB (self-eval val mean, 100 views)。p2-s3 の off\u002Fdepth2 n=3 mean (36.185 \u002F 36.202 dB) の guard 内。本 run は submission=per_kernel\u002Fforward_submission=per_stage という別 regime なので PSNR の直接比較は非対象 (kernel は bit-exact のため理論上は同水準になるはず、というだけの参考値)","train elapsed 205.78s (n=1)。**production baseline (depth2 default, 151.70s) や S3 off baseline (185.21s) と直接比較しない** — per_kernel\u002Fper_stage submission は CB 数が既定の 15〜27\u002Fiter → 15 CB\u002Fiter 超 (最終 15,001 cb from iter1 window 相当) に増え、busy% が 68.9% まで下がる**測定専用 regime**であり、本 run の wallclock 自体に意味はない。意味があるのは kernel 単体の gpu_ms とその share のみ",[49,52,55,70,75,77,153,157,161,164,166,192,195,197,231,234,236,250,253,255,262,264,278,281,345,348,351,353,364,435,438,440,443,445],{"type":50,"text":51},"lead","p2-counter-session の per-kernel share 表 (backward_raster 33.6% > radix 26.3% > adam 13.8% > rasterize 11.9% > ssim 10.0%) は commit 56519c4 — \u003Cstrong>S2 (forward 1 CB 化 + hierarchical GPU scan) の実装 (414c633) より後、しかし default 採用 (3027e33) より前\u003C\u002Fstrong> — に撮られたデータで、config が `[backend] radix_scan` を明示していなかったため \u003Cstrong>当時のデフォルト (旧 flat scan) で計測されていた\u003C\u002Fstrong>。post-S2\u002FS3 (hierarchical scan + resident binning が defaultの現在) で撮り直すとどう動くかが M1 C1 の主題であり、その結果が M3 (per-splat backward) の着手可否を決める。",{"type":53,"text":54},"heading","0. 計測 regime の選択 — chained では per-kernel の GPU 時間が分離できない (逸脱の報告)",{"type":56,"items":57},"kv",[58,61,64,67],{"key":59,"value":60},"milestone 本文の指示","`2026-08-16-s3-12500-off-prof.toml` を複製、`pipelining = \"off\"` のまま run 1 本",{"key":62,"value":63},"そのまま使わなかった理由","同 config は `submission = \"chained\"` \u002F `forward_submission = \"chained\"` (現 default) を継承する。`timing.rs` のモジュール doc: 「Chained mode ではこれらの label は\u003Cstrong>encode コストのみ\u003C\u002Fstrong>を計り、実 GPU 時間は統合 CB の `ts_chain_commit_wait` に集約される (= per-CB timing に粒度が落ちる)。bench harness の per-kernel breakdown 表は `submission = \"per_kernel\"` で取得する運用とする」。実際 S2 の chained forward (`trainer.rs::encode_forward_chained`) は project→bin_chain(emit+radix+extract)→rasterize を 1 CB に纏め、\u003Cstrong>`ts_fwd_radix_sort` という個別 label 自体が経路から存在しない\u003C\u002Fstrong> (`ts_fwd_bin_chain` に統合済み)",{"key":65,"value":66},"採った regime","config を `submission = \"per_kernel\"` \u002F `forward_submission = \"per_stage\"` に明示上書き (他は off-prof.toml を継承: `radix_scan = \"gpu_hierarchical\"` \u002F `binning = \"resident\"` \u002F `backward = \"simd\"` \u002F `raster_backward_range = \"last_contributor\"` \u002F `pipelining = \"off\"`)。`validate()` は `forward_submission = chained` or `pipelining = depth2` のときだけ hard error を出すので、この組み合わせは合法 (`splat check` で確認済み)",{"key":68,"value":69},"「p2-counter-session と同じ読み方」の担保","counter-session の per-kernel 表も同じ `submission = per_kernel` で撮られている (`SubmissionKind::PerKernel` の doc comment: 「per-kernel host timing … は引き続きこの mode で取ること」)。radix_scan\u002Fbinning は現 default (post-S2) のまま据え置いたので、「S2\u002FS3 の kernel 実装を post-S2\u002FS3 の submission 粒度で見る」という当初の狙いは達成できている",{"type":71,"label":72,"variant":73,"text":74},"callout","この regime の busy%\u002Fwallclock は「busy 予算の再構成には使えない」","warning","本 run の GPU busy は \u003Cstrong>68.9%\u003C\u002Fstrong> (production depth2 default の 91.3% とは別物)、wallclock も 205.78s (production の 151.70s とは別物)。\u003Cstrong>submission=per_kernel\u002Fforward_submission=per_stage\u002Fpipelining=off という 3 重に非 production な regime\u003C\u002Fstrong>であり、以下の share 表と kernel 単体の gpu_ms\u002Fiter だけが意味を持つ。counter-session はこの点を「chained 12.498 vs per_kernel 12.874 ms\u002Fiter busy (差 3%)」で検証しており、\u003Cstrong>kernel 単体の gpu_ms は submission wrapping にほぼ不変\u003C\u002Fstrong>という事後検証があるため、share の値自体は production の kernel 内訳の近似として読んでよい。",{"type":53,"text":76},"1. C1 — per-kernel gpu_ms 表 (leaf のみ、二重計上を除去)",{"type":78,"columns":79,"align":84,"rows":87},"table",[80,81,82,83],"kernel (leaf label)","gpu_ms 総計 (12,500 iter)","gpu_ms\u002Fiter","share",[85,86,86,86],"left","right",[88,93,98,103,108,113,118,123,128,133,137,139,141,143,148],[89,90,91,92],"**`ts_backward_raster` (+ `ts_project_back`、bit 同値のため統合)**","47,991.156","**3.839**","**33.86%**",[94,95,96,97],"`ts_fwd_radix_sort`","37,416.557","2.993","26.40%",[99,100,101,102],"`ts_adam`","17,970.471","1.438","12.68%",[104,105,106,107],"`ts_fwd_rasterize`","16,494.460","1.320","11.64%",[109,110,111,112],"`ts_ssim_fwd_grad`","15,516.979","1.241","10.95%",[114,115,116,117],"`ts_fwd_project`","3,500.682","0.280","2.47%",[119,120,121,122],"`ts_fwd_emit_pairs`","1,473.654","0.118","1.04%",[124,125,126,127],"`ts_l1_combine_ssim`","1,205.594","0.096","0.85%",[129,130,131,132],"`ts_fwd_extract_off`","146.144","0.012","0.10%",[134,135,135,136],"`ts_refine` (121 tick、host 5.047s)","0.000","0.00%",[138,135,135,136],"`ts_refine_accumulate` (host 3.969s)",[140,135,135,136],"`ts_opacity_decay` (121 tick、host 0.127s)",[142,135,135,136],"`ts_zero_grads` (host 0.140s)",[144,145,146,147],"**leaf 合計**","**141,715.697**","**11.337**","**100%**",[149,150,151,152],"(参照) `gpu_busy_stats()` union","141,716.0 (141.716s)","11.337","—",{"type":71,"label":154,"variant":155,"text":156},"leaf 合計が union と 0.3ms 差で一致 — chained の二重計上が消えた直接証拠","success","counter-session の per_kernel 表は leaf 合計が union を \u003Cstrong>+5.4% 上回っていた\u003C\u002Fstrong> (非ブロッキング harvest が wait なし commit の CB を後続 label へ重複帰属)。本 run は \u003Cstrong>141.715697s (leaf 合計) vs 141.716s (union)\u003C\u002Fstrong> で \u003Cstrong>差 0.3ms (0.0002%)\u003C\u002Fstrong> — 実質完全一致。`per_stage` forward は各 stage が commit+wait 境界を持つため (`trainer.rs` の per-stage forward path、S2 以前と同じ構造)、非ブロッキング harvest の帰属漏れが起きる余地がほぼ無い。\u003Cstrong>「leaf 合計 ≠ union」問題は submission=per_kernel\u002Fforward_submission=per_stage では原理的に解消される\u003C\u002Fstrong> — 逆に言えば chained (production) でこの表を撮ろうとすると必ず起きる帰属誤差だということでもある。",{"type":71,"label":158,"variant":159,"text":160},"`ts_project_back` の二重計上 — counter-session と同一現象が今回も再現","info","`ts_project_back` (host 9.737s、gpu_ms **47,991.156** — `ts_backward_raster` と \u003Cstrong>bit 単位で同値\u003C\u002Fstrong>) は counter-session でも観測された「同一 CB 集合を指す 2 つの label」現象がそのまま再現している。上表では 1 行に統合し、host 列は参考として両者の合計 (54.924+9.737=64.661s) を別途 §2 で扱う。",{"type":71,"label":162,"variant":73,"text":163},"refine \u002F zero_grads の gpu_ms が 0 に落ちる理由 — host コストは実在する","`ts_refine` (121 tick、host 合計 5.047s = tick あたり 41.7ms) と `ts_zero_grads` (12,500 回、host 合計 0.140s) はいずれも \u003Cstrong>gpu_ms が 0.000\u003C\u002Fstrong> だが、host 時間は明確に非ゼロ (特に refine は 1 tick 41.7ms と重い)。これは \u003Cstrong>非ブロッキング harvest の帰属先が「その label の closure 内で完了した CB」に限られる\u003C\u002Fstrong>ため — refine tick 中に commit された GPU 側の実作業 (opacity decay 等の compute dispatch) が、tick の closure が終わる時点でまだ完了しておらず、\u003Cstrong>次の label (`ts_forward` 等) の harvest 時に回収されてそちらに計上される\u003C\u002Fstrong>典型例 (p2-s3 finding が `ts_refine_accumulate` の gpu 0→1,871.9 で報告したのと同じ機構)。つまり\u003Cstrong>本表の refine 行 (0.00%) は「refine の GPU コストが無い」ことを意味しない\u003C\u002Fstrong> — 実コストは backward_raster 等の行に混入して見えなくなっている。この limitation は counter-session の callout (「label は入れ子」「Σ label.gpu ≠ 全体 GPU busy」) の系であり、新規発見ではない。",{"type":53,"text":165},"2. M3 GO\u002FNO-GO 判定 — backward_raster share 33.86% ≥ 25% 閾値 → GO",{"type":78,"columns":167,"align":171,"rows":172},[168,169,170],"指標","値","根拠",[85,86,85],[173,176,180,184,188],[174,92,175],"backward_raster (+project_back) share","上表 (leaf 合計に対する比)",[177,178,179],"M3 GO 閾値 (milestones.md)","≥ 25%","docs\u002Fstrategy\u002F2026-09-seminar05-milestones.md M3 節",[181,182,183],"判定","**GO**","33.86% は閾値を 8.9pt 超過",[185,186,187],"ナイーブ期待 Δ = share × 0.25","**8.47%**","brush PR #401 の -25% 主張をそのまま backward_raster share に乗せた素朴な積 (milestone 本文が要求する形式)",[189,190,191],"busy%-調整後の期待 wallclock Δ","**≈7.7%**","33.86% × 91.3% (production depth2 の busy%) × 0.25。本 run の share は GPU busy に対する比率であり、production の wallclock に対する比率に変換するには busy% を掛ける必要がある (本 run 自身の busy% 68.9% は非 production regime なので使わない)",{"type":71,"label":193,"variant":159,"text":194},"8.47% と 7.7% の差 — 「share」がどの分母に対する比率かで変わる","milestone 本文は「backward_raster の share (%) と、それ × 0.25 の期待 wallclock Δ」を 1 行で求めており、素朴に計算すれば \u003Cstrong>33.86% × 0.25 = 8.47%\u003C\u002Fstrong> になる。ただしこれは\u003Cstrong>「GPU busy 時間のうち backward_raster が占める割合」\u003C\u002Fstrong>であって\u003Cstrong>「wallclock のうち backward_raster が占める割合」\u003C\u002Fstrong>ではない — production (depth2 default) は busy 91.3% \u002F sync-tax 8.7% なので、GPU busy の delta がそのまま wallclock の delta になるとしても、\u003Cstrong>wallclock に対する backward_raster の実効 share は 33.86% × 91.3% ≈ 30.9%\u003C\u002Fstrong> であり、期待 Δ は \u003Cstrong>30.9% × 0.25 ≈ 7.7%\u003C\u002Fstrong> のほうが production の数字としては妥当。\u003Cstrong>両方とも n=1 点推定・brush の -25% を無検証で借用した上限値\u003C\u002Fstrong>である点は変わらない — M3 実装後の実測 gate でしか確定しない。",{"type":53,"text":196},"3. pre-S2\u002FS3 (counter-session) との比較 — share 構成はほぼ不変",{"type":78,"columns":198,"align":203,"rows":204},[199,200,201,202],"kernel","counter-session (pre-S2\u002FS3, 旧 flat scan)","本 finding (post-S2\u002FS3, hierarchical scan)","Δ (pt)",[85,86,86,86],[205,210,214,218,222,226],[206,207,208,209],"backward_raster (+project_back)","33.6%","33.86%","+0.26",[211,212,97,213],"radix","26.3%","+0.10",[215,216,102,217],"adam","13.8%","-1.12",[219,220,107,221],"rasterize","11.9%","-0.26",[223,224,112,225],"ssim (`ts_ssim_fwd_grad`)","10.0%","+0.95",[227,228,229,230],"project + emit_pairs + extract_off","2.7+1.0+0.1=3.8%","2.47+1.04+0.10=3.61%","-0.19",{"type":71,"label":232,"variant":155,"text":233},"S2 の hierarchical scan は「radix の CB\u002Fwait 数」を畳んだだけ — kernel 時間配分は変えていない","radix の share は 26.3% → 26.40% と\u003Cstrong>実質不変\u003C\u002Fstrong>。roadmap v2 が S2 gate 時に明記していた「S2 (hierarchical scan) が狙うのは radix の \u003Cem>CB\u002Fwait 数\u003C\u002Fem> であって kernel 時間ではない」という注記どおりの結果であり、\u003Cstrong>実測でこの想定を裏づけた\u003C\u002Fstrong>。adam が -1.12pt 下がっているのは測定誤差 (n=1) の範囲内とみるのが妥当で、有意な変化と主張するには n=3 が要る。\u003Cstrong>全体として「backward_raster が最大単独ブロックで 1\u002F3 強を占める」という律速構造は S2\u002FS3 を経ても変わっていない\u003C\u002Fstrong> — これが M3 (per-splat backward) を優先する直接的な根拠になる。",{"type":53,"text":235},"4. C2 — 残差 bubble の帰属 (会計訂正の反映 + 計装限界の特定)",{"type":56,"items":237},[238,241,244,247],{"key":239,"value":240},"tasklist C2 が指す「4.54s」の出自 (判明)","本 M1 着手前は repo 内のどこにも 4.54s という値が見当たらず (p2-s3 finding の「残差」行は 3.28s\u002F23%)、milestone 起草時点の記憶違いかと疑っていた。\u003Cstrong>M1 実施中に並行して走っていた M0 (docs 修正、commit c8864c8) が roadmap v2 の encode(B) 会計を訂正\u003C\u002Fstrong>しており (`ts_backward_raster` の子 label `ts_raster_bwd_alloc`\u002F`_upload` を親と二重計上していた、D-4 の是正)、\u003Cstrong>encode(B) 4.66→3.41s \u002F 残差 3.28→4.54s\u003C\u002Fstrong> という修正後の値が確定した。tasklist の「4.54s」はこの\u003Cstrong>訂正後の値を先取りした表記\u003C\u002Fstrong>だったと分かる (訂正コミットは M1 と同日、M1 の作業中に main へ入った)",{"key":242,"value":243},"訂正後の depth2 残 sync-tax 内訳 (合計 14.206s、p2-s3 §5 + roadmap v2 訂正)","refine tick drain 6.26s (**44%**、`511f916` 適用済みで既にこれ以上は同施策で削れない) \u002F encode(B) 3.41s (**24%**、nested label 二重計上を除いた正しい値) \u002F **残差 4.54s (32%)**",{"key":245,"value":246},"C2 の狙い","残差 4.54s を「driver 投入 latency」(CPU が commit() してから GPU が実際に実行を開始するまでの遅延) と「CB 間 gap」(GPU タイムライン上で先行 CB の GPUEndTime と後続 CB の GPUStartTime の間に生じる純粋な空白) に分解する",{"key":248,"value":249},"**結論: 既存計装では分解不能**","`splat\u002Fcrates\u002Fsplat-metal\u002Fsrc\u002Fgputime.rs` は `CommandBufferGpuTime` trait で `kernel_start_time()` \u002F `kernel_end_time()` (`kernelStartTime`\u002F`kernelEndTime`、objc `msg_send!` で bind 済み、L67-79) を提供しているが、`collect()` (L216-244) は `cb.gpu_start_time()` \u002F `cb.gpu_end_time()` **だけ**を読んで `Collector.intervals: Vec\u003C(f64, f64)>` (L153-159) に積む — kernelStart\u002FEndTime は**どこにも収集されていない**。さらに `Collector.intervals` 自体が private で、`union_since()` (L265-273) \u002F `stats()` (L275-296) はいずれも union \u002F 集計値だけを返し、\u003Cstrong>個々の CB の生 (start, end) ペアを外部に露出する API が存在しない\u003C\u002Fstrong> — CB 間 gap (連続する 2 CB の interval の差) すら現状は計算できない",{"type":71,"label":251,"variant":159,"text":252},"C2 提案 (実装はしていない) — file:line 付き","① \u003Ccode>splat\u002Fcrates\u002Fsplat-metal\u002Fsrc\u002Fgputime.rs:153-159\u003C\u002Fcode> — \u003Ccode>Collector.intervals\u003C\u002Fcode> を \u003Ccode>Vec<(f64,f64)>\u003C\u002Fcode> (gpu start\u002Fend) から \u003Ccode>Vec<(f64,f64,f64,f64)>\u003C\u002Fcode> (kernel_start, kernel_end, gpu_start, gpu_end) に拡張。② 同ファイル \u003Ccode>collect()\u003C\u002Fcode> の \u003Ccode>let (s, e) = (cb.gpu_start_time(), cb.gpu_end_time());\u003C\u002Fcode> (L237) の直前後に \u003Ccode>let (ks, ke) = (cb.kernel_start_time(), cb.kernel_end_time());\u003C\u002Fcode> を足し、4 tuple を push。③ \u003Ccode>union_since()\u003C\u002Fcode> (L265) と同じ形の \u003Ccode>pub fn intervals_since(mark: usize) -> Vec<(f64,f64,f64,f64)>\u003C\u002Fcode> を追加してソート済み生 interval を label 単位で取り出せるようにする。④ \u003Ccode>splat-train-v1\u002Fsrc\u002Ftiming.rs\u003C\u002Fcode> に、④-a 連続 GPU interval 間の gap (\u003Ccode>gpu_start[i+1] - gpu_end[i]\u003C\u002Fcode>、= CB 間 gap) と ④-b 各 CB の \u003Ccode>gpu_start - kernel_end\u003C\u002Fcode> (= driver 投入 latency の近似、kernelEndTime は driver がコマンドの GPU 側実行可能形式への変換を終えた時刻) を集計する \u003Ccode>gpu_gap_report()\u003C\u002Fcode> を追加。⑤ 呼び出し箇所は \u003Ccode>splat-train-v1\u002Fsrc\u002Ftrain_loop.rs:802-803\u003C\u002Fcode> (既存の \u003Ccode>gpu_drain()\u003C\u002Fcode> → \u003Ccode>print_summary()\u003C\u002Fcode> の直後、最終 blocking drain 済みで全 CB が回収されている地点)。この 5 箇所を実装すれば、次回 depth2-prof run 1 本で残差 4.54s の分解が測れる見込み (追加コストはほぼゼロ — 既存 \u003Ccode>register()\u003C\u002Fcode>\u002F\u003Ccode>collect()\u003C\u002Fcode> 経路に相乗りするだけ)。",{"type":53,"text":254},"5. 規約 \u002F 次段への含意",{"type":256,"items":257},"list",[258,259,260,261],"**M3 (per-splat backward) は GO** — backward_raster share 33.86% ≥ 25% 閾値、期待 wallclock Δ は 7.7〜8.5% (n=1・brush 借用値の上限見積り、M3 実装後の gate で確定させる)","**M1 C1 の per-kernel breakdown は submission=per_kernel\u002Fforward_submission=per_stage でしか測れない** — chained (production) では individual kernel の GPU 時間が構造的に分離不能。今後この breakdown を再測るときは同じ規約を使うこと (本 finding に明記)","**C2 (残差 driver-latency\u002FCB-gap 分解) は計装追加が前提** — 上記 file:line 5 箇所を実装しない限り、Xcode capture を使わずに分解する経路は無い。tasklist が「Xcode 不要」と書いていたのは gputime.rs の kernelStartTime\u002FEndTime を使えば取れるはずという想定だったが、**bind されているだけで未配線**だったことが本 M1 で判明した","**tasklist の「4.54s」表記の出自を確定** — M0 (並行 doc 修正) による encode(B) 4.66→3.41s の会計訂正の結果であり、旧 finding (p2-s3) の「残差 3.28s」は誤りではなく\u003Cstrong>訂正前の値\u003C\u002Fstrong>。roadmap v2 は既に訂正済み (commit c8864c8)、本 finding が二次ソースとして参照する",{"type":53,"text":263},"6. v2 (M4\u002FA7 後、2026-09-seminar05-milestones M7) — 2026-08-30 追加計測",{"type":56,"items":265},[266,269,272,275],{"key":267,"value":268},"背景","本節 (v1、§0〜5) の計測後、M4 (A5 radix scatter simd_ballot、default flip、p3-radix-ballot) と A7 (refine 3-pass 削減、default flip、p3-refine-3pass) が同日中に採用・default flip された。両施策とも「post-S2\u002FS3 の kernel share がさらにどう動くか」を検証する対象になるため、M7 (最終スタック確定) の一部として同一手法で撮り直した",{"key":270,"value":271},"config","`splat\u002Fconfigs\u002F2026-08-30-c1v2-12500-off-prof.toml` (`2026-08-30-c1-12500-off-prof.toml` の複製。§0 と同じ理由で `submission = per_kernel` \u002F `forward_submission = per_stage` \u002F `pipelining = off` を明示、`radix_scan = gpu_hierarchical` \u002F `binning = resident` は現 default のまま。**`radix_scatter` \u002F `refine_scratch_persist` \u002F `refine_direct_write` は明示せず default に任せている** — これにより M4\u002FA7 の default flip が両方効いた状態が採れる)",{"key":273,"value":274},"flag 実測確認","run log の `[backend] BackendConfig { … }` 行で `radix_scatter: SimdBallot` \u002F `refine_scratch_persist: true` \u002F `refine_direct_write: true` を確認 (意図した post-M4\u002FA7 regime で走っていることの直接証拠)",{"key":276,"value":277},"run","1 run のみ (§0 と同じ GPU ルール遵守、n=3 化はしていない — 本節の share 値も n=1 の点推定)。commit a446f2c の release binary (M4\u002FA7\u002FM2 Tier1\u002FM5a 実装込みの main HEAD)。AC 電源、他 GPU 使用なし。wallclock 174.57s \u002F self-eval PSNR 36.201 dB (**§0 の v1 run 205.78s\u002F36.087dB や production baseline とは比較しない** — 本 regime は「busy 予算の再構成には使えない」測定専用 regime、という v1 §0 の警告がそのまま適用される)",{"type":71,"label":279,"variant":155,"text":280},"leaf sum が union と exact 一致 — v1 と同じ検算が v2 でも通る","leaf 9 label (backward_raster \u002F ssim_fwd_grad \u002F adam \u002F fwd_project \u002F fwd_emit_pairs \u002F fwd_radix_sort \u002F fwd_rasterize \u002F fwd_extract_off \u002F l1_combine_ssim、`ts_project_back` は `ts_backward_raster` と bit 同値の重複のため v1 と同様に 1 行へ統合) の gpu_ms 合計は \u003Cstrong>114,507.738ms = 114.508s\u003C\u002Fstrong> で、run 末尾の \u003Ccode>[gpu] busy 114.508s\u003C\u002Fcode> と\u003Cstrong>完全一致\u003C\u002Fstrong>。v2 run のバイナリには v1 に無かった新規 sub-label (\u003Ccode>ts_forward\u003C\u002Fcode> \u002F \u003Ccode>ts_raster_bwd_gpu\u003C\u002Fcode> \u002F \u003Ccode>ts_project_back_gpu\u003C\u002Fcode> \u002F \u003Ccode>ts_project_soa_gpu\u003C\u002Fcode> 等) が追加されているが、これらはいずれも host 計測目的の子スコープで gpu_ms は 0 に落ちるか (v1 の refine\u002Fzero_grads と同じ「非ブロッキング harvest が親スコープに帰属する」現象)、または上位 leaf の子要素の和と\u003Cstrong>完全一致\u003C\u002Fstrong>する集計ラベル (\u003Ccode>ts_forward\u003C\u002Fcode> の gpu_ms 34,977.613 = \u003Ccode>fwd_project + fwd_emit_pairs + fwd_radix_sort + fwd_rasterize + fwd_extract_off\u003C\u002Fcode> の和と bit 一致) であることを確認し、leaf 集合の選定から除外した (v1 の「leaf 判定は union との一致で検算する」規約をそのまま適用)。",{"type":78,"columns":282,"align":289,"rows":290},[80,283,284,285,286,287,288],"v1 gpu_ms (M1、M4\u002FA7 前)","v2 gpu_ms (M4\u002FA7 後)","abs Δ","v1 share","v2 share","share Δ (pt)",[85,86,86,86,86,86,86],[291,297,302,308,313,319,325,331,336,342],[292,90,293,294,208,295,296],"**backward_raster (+project_back)**","45,877.989","-4.40%","**40.07%**","+6.21",[215,100,298,299,102,300,301],"17,502.128","-2.61%","**15.28%**","+2.60",[303,105,304,305,107,306,307],"rasterize (`ts_fwd_rasterize`)","16,185.077","-1.88%","**14.13%**","+2.49",[223,110,309,310,112,311,312],"15,025.375","-3.17%","**13.12%**","+2.17",[314,95,315,316,97,317,318],"radix (`ts_fwd_radix_sort`)","13,749.681","**-63.25%**","**12.01%**","**-14.39**",[320,115,321,322,117,323,324],"project (`ts_fwd_project`)","3,391.138","-3.13%","2.96%","+0.49",[326,120,327,328,122,329,330],"emit_pairs (`ts_fwd_emit_pairs`)","1,511.105","+2.54%","1.32%","+0.28",[124,125,332,333,127,334,335],"1,124.633","-6.72%","0.98%","+0.13",[337,130,338,339,132,340,341],"extract_off (`ts_fwd_extract_off`)","140.612","-3.79%","0.12%","+0.02",[144,145,343,344,147,147,152],"**114,507.738**","**-19.20%**",{"type":71,"label":346,"variant":155,"text":347},"radix 単独 -63.25% は M4 gate の per_stage 実測 -63.7% と独立に一致 — cross-validation","本 v2 run (submission=per_kernel\u002Fforward_submission=per_stage) の radix 単独 gpu_ms 減少 \u003Cstrong>-63.25%\u003C\u002Fstrong> は、M4 の gate finding (p3-radix-ballot §4) が別の run で計測した「forward_submission=per_stage 単独計測での radix gpu_ms\u002Fcall -63.7%」と\u003Cstrong>独立した run・独立した計測断面で一致\u003C\u002Fstrong>する (両者とも `radix_scatter` flag 差の A\u002FB ではなく、v1(M4前)\u002Fv2(M4後) や M4 gate の off\u002Fon という異なる比較軸から同じ数字に収束している)。leaf 合計の総額縮小 \u003Cstrong>-19.20% (141.716s → 114.508s)\u003C\u002Fstrong> のほぼ全部が radix 単独の絶対削減 (37,416.6 → 13,749.7ms = -23,666.9ms) で説明でき、他 8 label の削減 (backward_raster -4.40%〜l1_combine_ssim -6.72%、絶対にして合計 ~2,470ms) は寄与として一桁小さい。\u003Cstrong>A7 (refine 3-pass 削減) は host 側の allocation\u002Fcopy を減らす施策であり、この per-kernel gpu_ms 表 (GPU 側 kernel 実行時間) には理論上ほぼ影響しないはず\u003C\u002Fstrong>という予想と、他 8 label の変化が誤差レベル (-1.9〜+2.5%、n=1 点推定のノイズ帯) に収まっていることは整合する。",{"type":71,"label":349,"variant":73,"text":350},"share が軒並み『上昇』しているのは分母 (radix) が縮んだため — 他 kernel が遅くなったわけではない","上表で backward_raster (33.86%→40.07%) \u002F adam (12.68%→15.28%) \u002F rasterize (11.64%→14.13%) \u002F ssim (10.95%→13.12%) は\u003Cstrong>share だけを見ると全て上昇している\u003C\u002Fstrong>が、これは分母 (leaf 合計) が radix の劇的な縮小で 19.20% 小さくなったことによる\u003Cstrong>相対効果\u003C\u002Fstrong>であり、\u003Cstrong>これら 4 kernel 自体の絶対 gpu_ms はすべて -1.88%〜-4.40% と、v1→v2 でむしろわずかに縮んでいる\u003C\u002Fstrong> (n=1 点推定のノイズ帯内で、A7\u002Fその他の間接効果か測定誤差かは切り分けられない)。\u003Cstrong>「share が上がった = 遅くなった」ではない\u003C\u002Fstrong> — 唯一の実質的な構造変化は radix の share が 26.40% → 12.01% (-14.39pt) に落ち、backward_raster が単独最大ブロックとしての優位をさらに拡大した (33.86%→40.07%、2 位の adam 15.28% との差が 21.2pt→24.8pt に拡大) ことのみである。",{"type":53,"text":352},"6.1 v3 (2026-08-31 追加、drums 切り分け用) — 同じ Lego scene で binary vintage だけを HEAD (a556b78) に進めて再計測",{"type":56,"items":354},[355,358,361],{"key":356,"value":357},"目的","`p3-kernel-share-drums` §2\u002F§4 が、Lego v2 (`a446f2c`) と drums (`3db33a8`) の間の binary vintage 差 (S4b `4405bb4` ssim_reduce=Gpu default flip、C2 計装 `9deb14a` 全 CB kernel timestamp 収集など 34 commit) が per-kernel gpu_ms を系統的に底上げしている疑いを報告した。scene を Lego に固定したまま同じ binary vintage 差だけを再現し、疑いを切り分ける",{"key":359,"value":360},"config \u002F run","`splat\u002Fconfigs\u002F2026-08-31-c1v3-12500-off-prof.toml` (本節の `2026-08-30-c1v2-12500-off-prof.toml` を run 名のみ `c1v3-12500-off-prof` に変更して複製、[backend] を含め設定は完全一致)。HEAD commit **a556b78835d8** の release binary (既存バイナリ、再ビルドなし)。1 run のみ (n=3 化はしていない)、AC 電源・他 GPU 使用なし・load1 1.90 を確認。train elapsed 174.71s (v2 174.57s とほぼ同一)、self-eval mean val PSNR 36.190dB (v2 36.201dB)、final splats 409,702 (v2 404,652)。leaf 9 label 合計 114,880.732ms が run 末尾 `[gpu] busy 114.881s` と誤差 0.268ms で一致 (v1\u002Fv2 と同じ検算)",{"key":362,"value":363},"詳細 finding","`docs\u002Ffindings\u002Fp3-kernel-share-drums.toml` §5「Lego 同 binary 再計測による切り分け」に v3 の leaf 表・判定を記載。本節にはサマリのみを転記する",{"type":78,"columns":365,"align":370,"rows":371},[80,366,367,368,287,369,288],"v2 ms\u002Fiter (a446f2c)","v3 ms\u002Fiter (a556b78, 同 Lego scene)","v3\u002Fv2 比","v3 share",[85,86,86,86,86,86,86],[372,379,386,393,400,407,414,419,426,430],[206,373,374,375,376,377,378],"3.670","3.693","1.006×","40.07%","40.18%","+0.11",[215,380,381,382,383,384,385],"1.400","1.416","1.011×","15.28%","15.40%","+0.12",[219,387,388,389,390,391,392],"1.295","1.293","0.999×","14.13%","14.07%","-0.06",[223,394,395,396,397,398,399],"1.202","1.194","0.993×","13.12%","12.99%","-0.13",[211,401,402,403,404,405,406],"1.100","1.103","1.003×","12.01%","12.00%","-0.01",[408,409,410,411,323,412,413],"project","0.271","0.274","1.012×","2.99%","+0.03",[415,416,416,417,334,334,418],"l1_combine_ssim","0.090","1.000×","0.00",[420,421,422,423,329,424,425],"emit_pairs","0.121","0.116","0.962×","1.27%","-0.05",[427,428,428,429,340,340,418],"extract_off","0.011","1.008×",[144,431,432,433,434,434,152],"**9.161**","**9.190**","**1.003×**","100%",{"type":71,"label":436,"variant":155,"text":437},"判定 (a) 確定 — 全 9 leaf が ±5% 以内、profile 経路の系統的底上げは棄却","同じ Lego scene・同じ [backend] regime で binary だけを `a446f2c`→`a556b78` (S4b + C2 計装 + それ以降の全 commit) に進めても、9 leaf すべてが v2 比 \u003Cstrong>0.962×〜1.012×\u003C\u002Fstrong> (leaf 合計 1.003×) に収まった — 最大逸脱は emit_pairs の -3.80%、次点は ssim (`ts_ssim_fwd_grad`) の -0.67% で、share Δ も全 kernel ±0.13pt 以内。\u003Cstrong>S4b (ssim_reduce=Gpu) と C2 計装 (全 CB kernel timestamp 収集) を含む binary vintage 差は per-kernel gpu_ms を系統的には底上げしていない\u003C\u002Fstrong> — `p3-kernel-share-drums` §2\u002F§4 が疑った「profile=on 経路の系統的な底上げ」仮説は本 run により\u003Cstrong>反証された\u003C\u002Fstrong>。drums で観測された 1.17〜1.93倍の増加 (ssim_fwd_grad +44.6% を含む) は binary vintage ではなく\u003Cstrong>drums scene 自体 (splat 数 1.85倍、画像内容差) に起因する\u003C\u002Fstrong>と判定する — 詳細は `p3-kernel-share-drums.toml` §5 参照。",{"type":53,"text":439},"7. v2 が M3 判定に与える示唆 (参考、M3 は既に per-splat backward 実装 → NO-GO で完結済み)",{"type":71,"label":441,"variant":159,"text":442},"M3 (per-splat backward) の GO 判定はそのまま — share はさらに上昇 (40.07% ≥ 25%)","M3 は本 finding v1 の GO 判定 (33.86% ≥ 25%) を受けて実装・gate まで完了しており (`p3-per-splat-backward` \u002F `p3-per-splat-backward-tg256`)、tg256 版が default (per_pixel) 比 +32.8% と大幅劣後で \u003Cstrong>NO-GO 確定\u003C\u002Fstrong>済みである。v2 の backward_raster share 40.07% は M3 実装当時 (33.86%) より \u003Cstrong>さらに大きい\u003C\u002Fstrong>ため、GO\u002FNO-GO の判定自体は変わらない (GO のまま) — ただし M3 の性能敗因は「256-thread TG の低 occupancy」という実装上の問題であり、share の大小とは無関係の敗因だったため、v2 の share 上昇は M3 の結論を覆さない。本節は記録のためだけに残す — \u003Cstrong>M3 系列の探索は打ち切り済みで、v2 を受けた再挑戦の計画は無い\u003C\u002Fstrong>。",{"type":53,"text":444},"8. C2 計装基盤 実装済み (2026-08-30、§4 の file:line 提案 5 箇所を実装)",{"type":56,"items":446},[447,450,453,456,459,462,465],{"key":448,"value":449},"commit","`9deb14a` (splat-metal\u002Fsrc\u002Fgputime.rs, splat-train-v1\u002Fsrc\u002Ftiming.rs, splat-train-v1\u002Fsrc\u002Ftrain_loop.rs)。worktree agent-a25c4092c2a352ba9 上で実装、main への merge は別途",{"key":451,"value":452},"実装内容","§4 の提案①〜⑤をすべて実装。`Collector.intervals` は `Vec\u003C(f64,f64)>` ではなく `Vec\u003CCbInterval>` (epoch, kernel_start, kernel_end, gpu_start, gpu_end) に拡張 — `union_seconds()` 自体のシグネチャは変えず、呼び出し側で `(gpu_start, gpu_end)` に投影してから渡す形にした (`union_seconds` は public\u002Ftest 参照されているため非破壊)。`intervals_since(mark)` で生 interval を露出。`timing::gpu_gap_report(n_bands)` \u002F `timing::print_gap_report()` を追加、`train_loop.rs` の各 iteration 先頭で `gpu_set_epoch(it)`、最終 blocking drain 直後 (`gpu_drain()`→`print_summary()` の次、実装当時の行番号は 823-828 — §4 提案が指した「802-803」から drift 済み) で `print_gap_report()` を呼ぶ",{"key":454,"value":455},"当初提案からの逸脱 (2 点)","(1) **epoch 追加**: §4 提案にはなかったが、`harvest()` が非ブロッキング swap_remove 回収のため `intervals` の格納順は完了順であって iteration 順ではないと気づき (advisor 指摘)、iteration 帯別集計が誤ってバンド化されるバグを避けるため `register()` 時点 (CB 生成 = iteration 順) の epoch を CB に焼き付ける仕組みを追加した。(2) **`gap_v\u002Flead` の 3 分解を 4 分解に変更**: §4 提案の ④-b は `gpu_start - kernel_end` (driver 投入 latency の近似) 1 本だけだったが、実装では `kernel_end - kernel_start` (drvproc) と `gpu_start - kernel_end` (handoff) を分けて出し、さらに `gpu_end[i-1] - kernel_start[i]` (host_lead、符号あり・正=host 先行\u002F良い overlap、負=host 遅れ→gap 直結) を追加した 4 分解にした — `commit()→kernelStart` (真の driver 投入 latency) は host 側の commit タイムスタンプ計装が必要で §4 提案 5 箇所のスコープ外のため、host_lead をその代替として位置づけている (詳細は `docs\u002Farchitecture\u002Fbackend-and-compiler-conventions.md` §4.1)",{"key":457,"value":458},"smoke 確認 (1000 iter, splat 数 6.9k, config は使い捨てのため未コミット)","`reliable=true dropped=0 kernel_invalid=0 sum\u002Funion=1.000000x host_ahead_frac=49.7%`。cb_gap mean 0.454ms (n=2000、p50 0.249ms、p90 0.988ms、max 3.504ms)、drvproc mean 0.038ms、handoff mean 0.974ms、host_lead mean 0.556ms (p50 **-0.192ms** — 中央値は host 遅れ側だが平均は正側に引っ張られる裾の長い分布)。**Σcb_gap = 0.908s vs sync-tax (全量) 0.917s → 99.0%** (`print_gap_report` の `reconcile:` 行、advisor review で追加)。**この 99.0% は「sync-tax 全量」に対する割合であり「残差 4.54s」の割合ではない** — 2 回目の advisor review で指摘: depth2 sync-tax には refine tick の blocking drain (§4: 6.26s\u002F44%) も含まれ、これも同じ `cb_gap` として計上される。本 smoke は `ts_refine` host 計 2.1ms (6 回) と refine コストが無視できる regime だったため「ほぼ全量」に見えただけで、12.5k (refine 125 回・計 6.26s 見込み) では **`cb_gap` は双峰分布になり、`mean × n` は refine tick という外れ値に引っ張られる** — 残差 4.54s 相当を見たいときは `mean` ではなく **`p50 × n`** (robust) を使うこと。恒等式 `cb_gap = -host_lead + drvproc + handoff` は個別 CB で exact に確認済み (単体 test `gap_report_identity_with_host_late`)。12.5k での分解値はまだ未計測 (次項)",{"key":460,"value":461},"12.5k full run で main が実行すべきコマンド","`pgrep -fl \"target\u002Frelease\u002Fsplat\"` が空であることを確認した上で `cd splat && .\u002Ftarget\u002Frelease\u002Fsplat train --config configs\u002F2026-08-30-c2-12500-depth2-prof.toml` ([backend] は `2026-08-16-s3-12500-depth2-prof.toml` と bit-exact、[experiment] メタデータのみ差し替え)。run 末尾の `=== C2 gap report ===` ブロックの `reconcile:` 行は sync-tax **全量** (§4: 14.206s 相当) との突き合わせ — 「残差 4.54s」を見るには `p50 × n` (`mean × n` ではなく) を使い、band 別 `max`\u002F`p90` が `refine.every` (=100) 周期で跳ねていれば refine tick の混入として除外して読むこと",{"key":463,"value":464},"reliable ゲートの blast radius (12.5k で false になった場合の読み方)","`dropped > 0` は GPU timeline に穴を空けるため `cb_gap` を含む**全列**を無効化する。`kernel_invalid > 0` は kernel timestamp だけが無効なので **`drvproc`\u002F`handoff`\u002F`host_lead` の 3 列だけ**を縮小させる — `cb_gap` (と `reconcile:` 行) は `GPUStart`\u002F`GPUEnd` だけに依存するため**無影響**。よって 12.5k (~25000 CB、smoke の ~10 倍) で `kernel_invalid > 0` が出て `reliable=false` になっても、`dropped == 0` である限り `cb_gap`\u002F`reconcile:` は捨てずに読んでよい",{"key":466,"value":467},"未解決点","(1) **実測済 → `p3-c2-bubble-attribution`** (2026-08-30、M4+A7 default 込みの main HEAD で 12.5k full run。reliable=true dropped=0 kernel_invalid=0、残差=通常境界 7.2〜8.1s \u002F refine tick drain 3.0〜3.8s とブラケット分解、host-late 支配・handoff は定常帯で headroom 薄いと判明)。(2) `dropped`\u002F`kernel_invalid` が smoke では 0 だったが、12.5k (400k splats 規模、より長い run) で HW-3 相当の 0\u002F逆転 timestamp が出るかは未確認 (出た場合の読み方は上記) — 実測 run でも `dropped=0 kernel_invalid=0` だったため杞憂に終わった。(3) `commit()→kernelStart` の真の driver 投入 latency は依然として計装されていない (意図的なスコープ外、host_lead が代替) — 必要になった場合は per-`.commit()`-call-site の instrumentation が別途要る。(4) 12.5k run の最初の band が `epoch_lo == 1` になっているか確認すること — `CURRENT_EPOCH` は 0 始まりのため、`enable()` 後 最初の `gpu_set_epoch(1)` より前に登録された CB があると epoch 0 に落ちて band 境界がずれる (smoke では `[1, 250]` で clean だったが、setup 部分の CB 数が config によって変わりうる) — 実測 run でも `[1, 3125]` で clean、band n 合計 25000 と一致し drift なしを確認済み",[469,479],{"id":37,"title":37,"subtitle":470,"date":9,"workspace":471,"tags":472,"verdict":474,"psnr":475,"psnr_unit":-1,"wallclock":476,"splats":477,"summary_url":478,"detail_path":478},"M1 C1: per-kernel gpu_ms 再計測 (submission=per_kernel \u002F forward_submission=per_stage \u002F pipelining=off、post-S2\u002FS3 kernel)","splat",[5,17,473,26],"gpu-gate","partial",36.08714294433594,"3m 25s",408006,"\u002Fruns\u002Fc1-12500-off-prof\u002F",{"id":38,"title":38,"subtitle":480,"date":9,"workspace":471,"tags":481,"verdict":474,"psnr":482,"psnr_unit":-1,"wallclock":483,"splats":484,"summary_url":485,"detail_path":485},"M7: per-kernel gpu_ms 再々計測 v2 (submission=per_kernel \u002F forward_submission=per_stage \u002F pipelining=off、M4 radix simd_ballot + A7 refine 3-pass 後の kernel)",[5,18,473,26,28],36.20126724243164,"2m 54s",404652,"\u002Fruns\u002Fc1v2-12500-off-prof\u002F",[487,520],{"id":41,"title":488,"date":489,"status":10,"polarity":490,"category":491,"axes":492,"tags":493,"task_code":503,"related_runs":504,"delta_psnr":515,"delta_wallclock":516,"rank":44,"verdict":517,"impact_summary":518,"detail_path":519},"S3 iteration pipelining depth 2 — 12.5k -18.1% \u002F busy 78 → 91% (default flip)","2026-08-17","positive","experiment",[14,15],[494,495,496,497,498,499,500,501,26,502],"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)",[505,506,507,508,509,510,511,512,513,514],"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",{"id":40,"title":521,"date":522,"status":10,"polarity":12,"category":491,"axes":523,"tags":524,"task_code":535,"related_runs":536,"delta_psnr":540,"delta_wallclock":541,"rank":44,"verdict":542,"impact_summary":543,"detail_path":544},"P2 counter session — default スタックの GPU busy% は 68〜69% で確定、H1 (bubble) 単独で W 比 0.70 を説明。H3 (DVFS) は棄却、卒論の「エネルギー 0.7-0.8× で勝つ」は不成立 (GPU energy 0.90×・package energy 1.06×)","2026-08-16",[14,15],[525,498,526,527,528,529,530,531,532,533,534],"counter-session","ioreport","power","energy","dvfs","p-state","msplat","m4-max","thesis-ready","negative","2026-08 1× 工程表 v2 — AC 復帰後 計測 queue #1",[537,538,539],"counter-12500-prof","counter-12500-noprof-r1","counter-12500-noprof-r2","本 session の 12.5k n=3 self-eval (premultiplied convention) mean 36.174 dB (36.187 \u002F 36.130 \u002F 36.204)、profile=true 1 本 36.262 dB。msplat 30K native val (white) n=4 mean 36.539 dB。**convention 依存のため直接比較しない** (p2-msplat-parity-lego の cross-eval 表を参照)","12.5k profile=false n=3 mean **216.12s** (219.35 \u002F 222.71 \u002F 206.31) — W2 gate の 219.51s と同水準 (日内 drift 内)。msplat 30K n=4 mean **169.77s** (176.09 \u002F 161.37 \u002F 173.93 \u002F 167.68)。等価 gap = **1.273×**","busy-68to69pct-H1-only-H3-refuted-energy-claim-withdrawn","1× 工程表 v2 が「AC 復帰後 queue #1」に置いていた counter session を実施し、3 問すべてを実測で閉じた。\u003Cstrong>(1) busy% 論争は 68〜69% で決着\u003C\u002Fstrong> — bench (final 68.9% \u002F iter5000 67.5%、n=3、cb_dropped=0・overlap 1.00×) と 12.5k full run の補正値 (148.169s busy ÷ 同日 profile=false wallclock 216.12s = 68.6%) が一致。\u003Cstrong>(2) H1\u002FH2\u002FH3 の verdict は「H1 単独で説明・H2 null・H3 棄却」\u003C\u002Fstrong>。W 比 0.704 ≈ busy 比 0.689 なので activity factor の差 (H2) を持ち出す必要がなく、P-state residency は本実装が P15 に 97.6〜98.0% (bench) 居座る一方、msplat の方が電力上限で P10〜P14 に落ちる — \u003Cstrong>DVFS で損をしているのは msplat であって本実装ではない\u003C\u002Fstrong>。\u003Cstrong>(3) 卒論 positive の撤回\u003C\u002Fstrong>: roadmap v2 が期待した「エネルギー 0.7-0.8× = W\u002FPSNR 効率で勝つ」は\u003Cstrong>不成立\u003C\u002Fstrong>。W が 0.70× でも wallclock が 1.273× 長いので、完走までの GPU energy は \u003Cstrong>0.897×\u003C\u002Fstrong> (10% 得) に留まり、CPU を含む package energy では \u003Cstrong>1.062×\u003C\u002Fstrong> (6% 損) に反転する。energy 0.75× を達成するには W 比 0.573× が必要で、実測 0.704× は energy 等価点 (0.764×) の外側。\u003Cstrong>結論: 卒論 §5 で電力効率を主張軸にはできない。正しい主張は「同じ package 電力枠でより長く回る = 熱設計に優しい」ではなく、単純に『S2\u002FS3 で bubble を潰せば W も energy も改善する余地が 31% 残っている』という engineering debt の定量化。\u003C\u002Fstrong>","\u002Ffindings\u002Fp2-counter-session\u002F",1790227327655]