drums (998k splats @30k, in-window 749k @12.5k) per-kernel share 実測 — share 構造は Lego とほぼ不変 (backward_raster 40.09% vs 40.07%)、絶対 ms/iter 差は binary vintage (S4b+C2) で汚染

drums (nerf_synthetic, 998k splats @30k 収束時 — Lego 30k の約 2.5倍、p1-axis1-phase-g-pareto-landscape §2) は本日の全最適化判断の根拠になった Lego per-kernel share (p3-kernel-share-post-s3 §6 v2) と splat 数の regime が大きく異なる。share 構造が splat 数に対して不変か — つまり Lego で優先した施策の順位が drums でも成り立つか — を 1 run 実測で判定する。

0. 計測 regime — c1v2 (Lego) と同一の逸脱・同一の理由

base config

`runs/multiscene-drums-30k/config.toml` (drums, G.3-alone 30k recipe) — [data]/[output]/[trainer]/[refine]/[adam] を継承

[backend] の出自

`2026-08-30-c1v2-12500-off-prof.toml` (Lego, M4/A7 後の per-kernel share 計測 config) の [backend] 節をそのまま移植: `submission = per_kernel` / `forward_submission = per_stage` / `pipelining = off` / `profile = true` / `binning = resident` / `raster_backward_range = last_contributor` / `radix_scan = gpu_hierarchical`

変更点

`[trainer] max_steps` を drums base の 30000 から **12500** に変更 (Lego c1v2 と同じ measurement window に揃える — 「drums 12.5k」)。`[refine] stop_iter` は drums base の 15000 のまま (15000 > 12500 なので measurement window 全域で refine が active、c1v2 の stop_iter=12500=max_steps と実質同じ状態)

run 実行

`splat check` で config 検証後、nohup + disown で background 起動 (DONE sentinel は run 側では書かれないため呼び出し側の shell wrapper で `echo done > *.DONE` を追加)。foreground `until` loop で能動待機、249.77s で完了 (exit=0)

flag 実測確認

run log の `[backend] BackendConfig { … }` 行で `radix_scatter: SimdBallot` / `refine_scratch_persist: true` / `refine_direct_write: true` / `ssim_reduce: Gpu` / `submission: PerKernel` / `forward_submission: PerStage` / `pipelining: Off` / `binning: Resident` を確認 (意図した regime で走っていることの直接証拠)

1. drums per-kernel gpu_ms 表 (leaf のみ、二重計上を除去)

leaf 判定の検算

9 leaf label (backward_raster / adam / fwd_rasterize / ssim_fwd_grad / fwd_radix_sort / fwd_project / fwd_emit_pairs / l1_combine_ssim / fwd_extract_off) の gpu_ms 合計 **170,414.242ms = 170.414242s** が、run 末尾の `[gpu] busy 170.414s` と**誤差 0.24ms (0.00014%) で一致** — c1v2 v2 と同じ検算が drums でも通る

ts_forward は集計 label (leaf から除外)

`ts_forward` (gpu_ms 51,751.594) = `fwd_project(4,921.986) + fwd_emit_pairs(1,763.565) + fwd_radix_sort(19,382.967) + fwd_rasterize(25,457.227) + fwd_extract_off(225.849)` の和と**bit 一致**。c1v2 v2 §6 の callout と同じ現象 (host 計測目的の子スコープ)

ts_project_back の二重計上

`ts_project_back` (gpu_ms 68,320.800) は `ts_backward_raster` (同 68,320.800) と bit 同値。c1v2/counter-session と同一現象、1 行に統合

0 に落ちる label

`ts_raster_bwd_gpu` / `ts_project_back_gpu` / `ts_project_soa_gpu` / `ts_refine_accumulate` / `ts_refine` / `ts_opacity_decay` / `ts_zero_grads` / 各 `*_alloc`/`*_upload`/`*_readback` は gpu_ms 0.000 (非ブロッキング harvest が親 label に帰属する既知の限界、p3-kernel-share-post-s3 §1 と同一機構)。leaf 集合から除外

2. Lego v2 との並記 — share 構造はほぼ不変、ms/iter は全 kernel が 1.17〜1.93倍

3. in-window splat 数 — 「2.5倍」は 30k 収束時の数字、12.5k 時点では 1.85倍

drums final splats @12,500 iter

**748,708** (result.toml, `[curve.splats]` — iter1: 5,207 → iter12,500: 748,708、末尾でも +30/iter で**まだ急成長中**、収束していない)

Lego v2 final splats @12,500 iter

**404,652** (`runs/c1v2-12500-off-prof/result.toml`、末尾は +1.44/iter でほぼ plateau)

in-window ratio

748,708 / 404,652 = **1.850倍** (タスク記述の「2.5倍」は drums 30k 収束時の 998k splats/Lego 30k baseline との比較であり、本 run の 12.5k window の実際の splat 数比とは異なる — 訂正)

capacity cap の影響

`capacity = 1,000,000` — drums 748,708 / Lego 404,652 とも上限未到達、cap による頭打ちはこの window では発生していない

4. 規約 / 次段への含意

• **Lego で優先付けした施策の相対順位は drums (splat 数 1.85倍) でも share 構造上は維持される** — backward_raster が単独最大 (40%強) で最優先、adam/rasterize が次点 (15%前後)、radix/ssim が僅差の 3位 (11-13%) という構造に Δ≤1.5pt しか動きがなく、Lego で棄却した施策 (M3 per-splat backward 系、A7 refine 3-pass 等) が drums で急に有効化する可能性は share 構造だけからは示唆されない — ただし splat 数比例で絶対 gpu_ms/iter 自体は増えている (adam 1.511×、radix 1.410×) ため、絶対 wallclock 削減効果 (ms 単位) は drums の方が大きい可能性がある。
• **A7 refine / sparse Adam の不可視率仮説は本 run では検証不能** — refine tick の gpu_ms は本 regime でも 0.000 に落ちる (非ブロッキング harvest の既知の限界、§1) ため、drums で refine コストが Lego と比べて相対的に重くなっているかどうかは per-kernel share 表からは読めない。host 時間 (ts_refine 総 host time) を drums/Lego で比較する追加解析、または C2 計装 (§8 実装済み) を使った refine tick 専用の gap 分解が必要。
• **次ラウンドで per-kernel share を再測る際は Lego 側も同一 binary (HEAD) で撮り直すこと** — 本 finding は Lego v2 (a446f2c) と drums (3db33a8) の binary vintage が 34 commit 分ずれており、ssim/l1_combine_ssim 等で系統的な底上げ (S4b + C2 計装) が疑われる。scene 間の絶対 ms/iter 比較を厳密に行う場合は、両 scene を同一 commit の release binary で 1 セッション内に測り直す必要がある (share の相対構造比較は本 finding のままで妥当)。**2026-08-31 追記: この切り分けは §5 で実施済み — 判定 (a)、疑いは取り下げ。**

5. Lego 同 binary 再計測による切り分け (2026-08-31 追記) — 判定 (a): drums の差は scene 由来、profile 経路の系統的退行ではない

目的

§2/§4 で疑った「S4b (`4405bb4`, ssim_reduce=Gpu default flip) / C2 計装 (`9deb14a`, 全 CB に kernel_start/end timestamp 収集を追加) による profile=on 経路の系統的な底上げ」が、Lego v2 (`a446f2c`) → drums (`3db33a8`) 間の binary vintage 差 (34 commit) に起因するのか、それとも drums scene 自体 (splat 数 1.85倍、画像内容差) に起因するのかを、<strong>scene を Lego に固定したまま同じ binary vintage 差だけを再現</strong>して切り分ける

事前条件確認

`pmset -g batt`: AC 接続・100% 充電確認。`pgrep -fl "target/release/splat"`: 空 (実行中の splat process なし)。`uptime`: load1 2.43→(60秒待機後) 1.90 と < 4 を確認

config

`splat/configs/2026-08-31-c1v3-12500-off-prof.toml` — `2026-08-30-c1v2-12500-off-prof.toml` (§0/§6 で Lego v2 に使った config) を run 名のみ `c1v2-12500-off-prof` → `c1v3-12500-off-prof` に置換して複製 (`[experiment].name` と `[output].run_dir` の 2 行のみ差分、[backend] を含むそれ以外は完全一致)

binary

現行 main HEAD **`a556b78835d8`** (2026-08-31) の release binary をそのまま使用 (再ビルドなし)。比較対象の Lego v2 (`a446f2c`) との間には S4b (`4405bb4`) / C2 計装 (`9deb14a`) を含む多数の commit が入っており、drums finding §2 が疑った binary vintage 差そのものを再現している。drums run 自体の `3db33a8` よりもさらに新しい HEAD だが、`git merge-base --is-ancestor {3db33a802265,4405bb4,9deb14a} a556b78` を実行しいずれも exit 0 (祖先) であることを確認済み — drums run に効いていた commit 集合 (S4b/C2 含む) はすべて `a556b78` に部分集合として含まれる。加えて run log の `[backend] BackendConfig { …, ssim_reduce: Gpu, … }` (S4b の default flip が実際に効いている直接証拠) と、末尾の `=== C2 gap report ===` ブロック (C2 計装が実際に active であり値を出力している直接証拠) の 2 点を実測で確認しており、ancestry 論証より強い経験的証拠として §0 の「flag 実測確認」に記載済み

run 実行

`splat check` で config 検証後、nohup + disown で background 起動 (呼び出し側 shell wrapper で完了時に `*.DONE` sentinel を書く)。foreground `until`-loop で能動待機 (15秒間隔ポーリング)、**174.71s** で完了 (exit=0)

flag 実測確認

run log の `[backend] BackendConfig { … }` 行で `radix_scatter: SimdBallot` / `refine_scratch_persist: true` / `refine_direct_write: true` / `ssim_reduce: Gpu` / `submission: PerKernel` / `forward_submission: PerStage` / `pipelining: Off` / `binning: Resident` / `profile: true` を確認 (v2/drums と同じ regime で走っていることの直接証拠)。ログ末尾に C2 gap report (`=== C2 gap report (CB 間 driver-latency / scheduling 分解) ===`) が出力されており、profile=on 経路で C2 計装が実際に active であることも確認済み

結果サマリ

train elapsed **174.71s** (v2 174.57s とほぼ同一)、self-eval mean val PSNR **36.190dB** (v2 36.201dB)、final splats **409,702** (v2 404,652、ほぼ同水準)。`[gpu] busy 114.881s / wall 174.623s = 65.8%` (v2 は busy 114.508s / wall 174.57s = 65.6%、ほぼ同一)

leaf 検算

leaf 9 label (backward_raster(+project_back)/adam/fwd_rasterize/ssim_fwd_grad/fwd_radix_sort/fwd_project/l1_combine_ssim/fwd_emit_pairs/fwd_extract_off) の gpu_ms 合計 **114,880.732ms = 114.880732s** が run 末尾 `[gpu] busy 114.881s` と<strong>誤差 0.268ms (0.00023%) で一致</strong> — v1/v2/drums と同じ検算がここでも通る。`ts_forward` (gpu_ms 34,978.817) = `fwd_project(3,430.628) + fwd_emit_pairs(1,453.624) + fwd_radix_sort(13,788.972) + fwd_rasterize(16,163.920) + fwd_extract_off(141.674)` の和と一致 (集計 label、leaf から除外)。`ts_project_back` (46,157.186) は `ts_backward_raster` (同 46,157.186) と bit 同値 (v1/v2/drums と同じ二重計上、1 行に統合)

• **判定 (a) — drums finding §2/§4 の「profile=on 経路の系統的な底上げ」疑いは取り下げ**。同一 Lego scene・同一 backend regime で binary vintage 差 (S4b + C2 計装含む) のみを再現しても全 9 leaf が ±5% 以内に収まったため、S4b/C2 が per-kernel gpu_ms を系統的に底上げしている証拠はない。
• **drums の絶対 ms/iter 差 (1.17〜1.93倍) は binary vintage (S4b/C2) 由来ではないと確定** — §4 の「絶対値比較は汚染されている」という留保は撤回してよい。本 run が確定させたのは「vintage 由来ではない」ことのみであり、残る主因は drums scene 自体 (splat 数、画像内容、tile occupancy 等) と推定されるが、「scene のどの性質が主因か」の内訳、および drums run 固有の測定環境 (thermal 等、n=1・対照なし) の寄与は本 finding のスコープ外で未分離のまま (§3 で in-window splat 比 1.85倍を報告済みだが、それだけで 9 kernel 一様 1.17〜1.93倍を説明できるかは検証していない)。
• **§1 の drums per-kernel share 表・§2 の share 構造比較 (backward_raster 40.09% vs 40.07% 等) はそのまま有効** — 本追記は絶対 ms/iter 比較の解釈のみを訂正するものであり、share の相対構造比較の結論 (splat 数 1.85倍でも share 構造はほぼ不変) には影響しない。

この finding が観測された / 言及している実験 run。

• c1-drums-12500-off-profdrums (998k splats) per-kernel gpu_ms share 計測。Lego v2 (p3-kernel-share-post-s3 §6) の測定 regime を drums dataset で再現し、splat 数 regime の違いが share 構造に影響するかを判定するPSNR 24.52 dBWallclock 4m 9sverdict partial
• c1v2-12500-off-profM7: per-kernel gpu_ms 再々計測 v2 (submission=per_kernel / forward_submission=per_stage / pipelining=off、M4 radix simd_ballot + A7 refine 3-pass 後の kernel)PSNR 36.20 dBWallclock 2m 54sverdict partial
• c1v3-12500-off-profM7: per-kernel gpu_ms 再々計測 v2 (submission=per_kernel / forward_submission=per_stage / pipelining=off、M4 radix simd_ballot + A7 refine 3-pass 後の kernel)PSNR 36.19 dBWallclock 2m 54sverdict partial

• mixedM1/v2 — post-S2/S3 per-kernel share 再計測: backward_raster 33.9%→40.1% (M4/A7 後)、radix 26.4%→12.0% (M4 の絶対削減を反映) → M3 GO 判定は不変。C2 残差 4.54s は driver latency / CB gap に分解不能 (計装欠如、file:line 提案のみ)2026-08-30
• positivePhase G omnibus — 速度改善 4 candidate × 8 scene の Pareto landscape 確定、**G.3 alone 30k = universal quality improvement** (+0.107 dB / +10% wall)2026-05-26