[{"data":1,"prerenderedAt":371},["ShallowReactive",2],{"finding:p3-forward-adam-audit":3,"finding-runs:p3-forward-adam-audit":181,"finding-related:p3-forward-adam-audit":182},{"meta":4,"impact":38,"sections":44},{"id":5,"title":6,"subtitle":7,"eyebrow":8,"date":9,"status":10,"category":11,"polarity":12,"axes":13,"tags":15,"task_code":25,"commit":26,"branch":27,"config_paths":28,"related_runs":29,"related_findings":30},"p3-forward-adam-audit","rasterize forward + adam kernel 監査 — forward は帯域到達率 ~9% (ALU-bound)、adam は ~90〜93% (帯域飽和済み)、bit-exact 候補はいずれも harness 分解能未満で段 2 省略","backward_raster 監査 (p3-backward-audit) に続き、per-kernel share v2 で 2・3 位の \u003Ccode>render_splats_f32\u003C\u002Fcode> (14.13%) と \u003Ccode>adam_step\u003C\u002Fcode> (15.28%) を監査した。forward は 5 観点 (a)〜(e)、adam は 3 観点 (f)〜(h) で候補を列挙し、特に adam の「帯域床 65.6% で閉鎖済み」という既存の closure 根拠を自前の byte-accounting で初めて検証した。\u003Cstrong>forward の実効帯域到達率は 410GB\u002Fs (この M4 Max、14-core CPU\u002F32-core GPU 構成の公称値) 比でわずか ~8.5〜8.7% — ALU\u002Flatency-bound であり float4 化や出力 packing のような帯域削減系候補は原理的に低 payoff\u003C\u002Fstrong>。\u003Cstrong>adam は同じ 410GB\u002Fs 比で ~90〜93% — ほぼ飽和しており pow hoist\u002Ff16 のような ALU 側最適化は元から無意味 (最終 N ではなく平均 N を使わないと 117% という物理的に不可能な値が出る罠を本 finding で明示)\u003C\u002Fstrong>。旧 tasklist が引用する「adam 帯域床 65.6%」の出典は追跡できず、同一数値が p2-counter-session の非 production per_kernel regime run の GPU busy% 列に存在することのみ確認した (誤用と断定はしないが、今後この数値を adam 固有の帯域到達率として引用するのは避けるべき)。bit-exact-class で安全性を確認できた候補は forward の threadgroup barrier 1 本削減のみだが、forward が ALU-bound という上記の結論と自己整合的に、期待 Δ は harness 分解能 (M2 Tier1 -1.11% 判定不能・M5a -0.055% null が示す ~1% の床) 未満と判断し、\u003Cstrong>実装 (段 2) はしなかった\u003C\u002Fstrong>。","rasterize forward + adam kernel 監査 · 帯域床の自前検証","2026-08-30","stable","experiment","negative",[14],1,[16,17,18,19,20,21,22,23,24],"rasterize-forward","adam","kernel-audit","bandwidth-floor","occupancy","fast-math","harness-floor","lego","no-implementation","p3-forward-adam-audit (段1: 監査 \u002F 段2: 候補 \u003C1% のため省略)","439123f8e38b","worktree-agent-aa4e9b55ce8b8681f",[],[],[31,32,33,34,35,36,37],"p3-backward-audit","p3-kernel-share-post-s3","p3-final-stack","p3-radix-ballot","p3-ssim-float4","p3-tier1-bit-exact","p2-counter-session",{"summary":39,"rank":40,"verdict":41,"delta_psnr":42,"delta_wallclock":43},"per-kernel share v2 で 2・3 位の rasterize forward (14.13%) と adam (15.28%) を監査した。forward は 5 候補 ((a) simd 早期終了 (b) barrier 数 (c) 出力 packing (d) conic\u002Fcolor の float4 化 (e) occupancy)、adam は 3 候補 ((f) 帯域床の再計算 (g) buffer\u002Fdispatch 数 (h) visible-only skip) を列挙した。\u003Cstrong>本 finding の核は (f)\u002F(d)\u002F(c) の判断根拠になる byte-accounting を自前で初めて行ったこと\u003C\u002Fstrong>: adam は 1 splat あたり 59 element (means3+log_scales3+rot_quats4+raw_opacities1+sh_coeffs 16×3=48) × 28 byte\u002Felement (read: grad+m+v+param 16B、write: m+v+param 12B) = 1,652 byte\u002Fsplat を動かす。M7 final-stack (r2-r4) の平均 splat 数 321,637 (trapezoid 積分による自前算出値、p3-final-stack) を使うと 1 iter あたり 531.3MB、per-kernel share v2 の `ts_adam` 1.400ms\u002Fiter (v1 1.438ms\u002Fiter) と組み合わせると実効帯域 \u003Cstrong>369.5〜379.5 GB\u002Fs = この M4 Max (14-core CPU\u002F32-core GPU、410GB\u002Fs 公称、Apple 公式値で確認済み) 比 \u003Cstrong>90.1〜92.6%\u003C\u002Fstrong> — ほぼ飽和\u003C\u002Fstrong>。**この計算で「平均 N」ではなく「最終 N (407,028)」を使うと 480.3GB\u002Fs = 117% という物理的に不可能な値が出る** — gpu_ms\u002Fiter は 12,500 iter 全体の平均であり、splat 数は 0→407k に増える過程の平均 (321,637) と対応させないと過大評価になる、という罠を本 finding で明示した (自己検算)。forward は同じ手法で Splat2D 36B\u002Fpair の staging read (avg pairs ≈765,900、407,267-splat checkpoint の実測 969,838 pair を平均 splat 数比でスケールした概算) + 出力 3 buffer 24B\u002Fpixel (640,000 px 固定) ≈ 46.0MB\u002Fiter を `ts_fwd_rasterize` 1.295〜1.320ms\u002Fiter と組み合わせると実効帯域 \u003Cstrong>34.9〜35.5 GB\u002Fs = 410GB\u002Fs 比わずか \u003Cstrong>8.5〜8.7%\u003C\u002Fstrong>\u003C\u002Fstrong> (pairs 概算が 10 倍近くずれても帯域律速には転じない、桁のオーダーとして頑健)。この非対称 (adam は帯域飽和、forward は帯域 1 割未満) が両 kernel の残余候補の見立てを直接決める: adam は (h) visible-only skip 以外に理論上削る余地がなく、forward は (c)\u002F(d) のような帯域削減系候補が原理的に低 payoff で、ALU\u002Foccupancy 側の余地を探すしかない。旧 \u003Ccode>2026-08-next-phase-tasklist.md:46\u003C\u002Fcode> の「adam 帯域床 65.6%」の出典を `docs\u002Fstrategy\u002Fraw\u002F*.json` で検索したが adam 固有の帯域算出は見つからず、同一の 65.6% は `p2-counter-session.toml` の \u003Cstrong>非 production per_kernel regime run の GPU busy% 列\u003C\u002Fstrong>にのみ存在する (`2026-09-seminar05-milestones.md:19` 自身がこの規模の同数値を「使えない」と注記している) — 誤用と断定する証拠はないが、今後 adam の帯域到達率として引用するのは避け、本 finding の 90〜93% を正とすべき。forward の (a) は backward の W1a (simd_any による reduction\u002Fatomic emit の skip) と構造が異なる: forward は per-splat の reduction\u002Fatomic を持たず、per-thread `!done` 条件による loop 早期脱出がハードウェアの execution mask 収束と等価な効果を既に持つため、明示的な `simd_all(done)` 追加は原理的に redundant (期待 Δ ≈0)。(b) は `num_done_atomic` の読み手が loop 先頭の 1 箇所のみ (`grep -rn num_done` で確認) であることを利用し、初期化直後の 2 本目の barrier (rasterize.metal:106) を安全に削除できる (bit-exact、単調増加のため未同期時は過小評価のみで正しさに影響しない) — ただし forward が ALU-bound という上記結論と整合的に期待 Δ は harness 分解能未満と判断した。(c) 出力 packing は f16 storage 禁忌 + backward が final_T を f32 精度で必要とするため機会なし。(d) conic\u002Fcolor の float4\u002FSoA 化は forward が帯域 1 割未満という結果から低 payoff、producer (project.rs) にも触れる高工数で見合わない。(e) occupancy\u002Fregister は backward 監査と同じツール限界 (Xcode GPU Frame Capture 相当が本環境に無い) で直接観測不能、TG memory 使用量 (9,220B\u002F32,768B) からは非律速と推測されるに留まる。AIR level では `-ffast-math` 相当の `air.fast_exp.f32` が既に使われていることを確認した (`shader_fast_math` の default が `true` = MTLCompileOptions default であるため) — 「fast exp に切り替える」候補は既に default で実施済みであり追加の余地なし。**結論: bit-exact-class で harness 分解能を超える候補は forward・adam いずれにも残っていない。段 2 (実装) は task 記載の \u003C1% 省略条件に該当するため実施しなかった**。","medium","forward-alu-bound-9pct-attainment \u002F adam-bandwidth-saturated-90-93pct \u002F no-bit-exact-candidate-clears-harness-floor \u002F stage2-skipped","N\u002FA (実装なし、GPU run 未実施)","N\u002FA (実装なし)。段 1 の byte-accounting のみが本 finding の実測的内容 — 既存の per-kernel share v2 の gpu_ms\u002Fiter (`ts_fwd_rasterize` 1.295〜1.320ms\u002Fiter、`ts_adam` 1.400〜1.438ms\u002Fiter、p3-kernel-share-post-s3 §6) と avg splat 数 (321,637、p3-final-stack) を組み合わせた事後計算。",[45,48,51,69,71,85,87,98,100,158,163,165,172,174],{"type":46,"text":47},"lead","backward_raster 監査 (p3-backward-audit、M8 atomic emit lane 分散を実装するも NO-GO) に続き、per-kernel share v2 (p3-kernel-share-post-s3 §6: backward_raster 40.07% > adam 15.28% > rasterize 14.13% > ssim 13.12% > radix 12.01%) で 2・3 位の \u003Ccode>splat\u002Fshaders\u002Fforward\u002Frasterize.metal::render_splats_f32\u003C\u002Fcode> と \u003Ccode>splat\u002Fshaders\u002Fopt\u002Fadam.metal::adam_step\u003C\u002Fcode> を監査した。task 指定の観点 (a)〜(h) を検討し、特に (f) 「adam 12.7% が帯域床なら visible-only 以外の削減余地は理論上ない」を実際に検算することを主眼に置いた。",{"type":49,"text":50},"heading","1. 監査 — rasterize forward (a)〜(e)",{"type":52,"items":53},"kv",[54,57,60,63,66],{"key":55,"value":56},"(a) tile 単位 simd_any による loop 早期打ち切り (backward W1a と同型か)","**該当なし — 構造が異なるため W1a は forward には移植できない**。backward の W1a `simd_any(contrib)` は「全 lane が寄与ゼロの iteration で 9 回の `simd_sum`+atomic emit をまとめて省略する」ためのもの — \u003Cem>省略できる高コストな操作 (reduction\u002Fatomic)\u003C\u002Fem> が前提にある。forward の per-splat 本体は reduction も atomic emit も持たない (`pix_out`\u002F`T` は thread-local register のみ)。forward が既に持つ早期終了は 2 層: (1) per-thread `!done` 条件による loop 自体の早期脱出 (`for (t=0; !done && t\u003Cremaining; t++)`) — GPU の execution mask 収束により、simd group 内の全 lane が done になれば hardware がその simd group の残り iteration を自然にスキップする (`simd_all(done)` を明示的に追加しても原理的に redundant)。(2) `num_done_atomic` によるタイル全体 (256 thread) 単位の outer batch loop 打ち切り。**候補として成立しない (N\u002FA)**",{"key":58,"value":59},"(b) threadgroup staging 幅と barrier 数","**bit-exact な 1 barrier 削減を発見・安全性確認済み、ただし期待 Δ は harness 分解能未満と判断**。現行は tile 開始時に barrier 2 本 (①`num_done_atomic` の 0 初期化を全 lane に可視化、②全 lane の `done` 由来 `atomic_fetch_add` を loop 先頭の `atomic_load` (rasterize.metal:117) より前に可視化) + batch ごとに barrier 2 本 (staging read の前後)。`grep -rn num_done splat\u002Fshaders\u002F splat\u002Fcrates\u002F` で `num_done_atomic` の読み手が rasterize.metal:117 (loop 先頭の early-break 判定) の 1 箇所のみであることを確認した — この読み出しは\u003Cstrong>単調増加のカウンタに対する近似判定\u003C\u002Fstrong> (early-break の可否だけに影響、`pix_out`\u002F`T`\u002F`stop_idx` などの出力値には一切影響しない) なので、②の barrier を削除しても最悪ケースは「その回の early-break を 1 batch 分だけ逃す」だけで \u003Cstrong>正しさは不変 (bit-exact)\u003C\u002Fstrong>。ただし forward は (f)\u002F(d) と同じ byte-accounting の帰結として ALU\u002Flatency-bound (帯域到達率 ~9%、§2 参照) であり、barrier 自体が bottleneck である証拠はない — 削除できる barrier は 1 tile あたり典型 6 本中 1 本 (avg pairs\u002Ftile ≈306 → batch 数 2、2(init)+2×2(batch)=6 → 5、-16.7%) で、これが wallclock に翻訳される保証はなく harness 分解能 (~1%) を超える可能性は低いと判断した",{"key":61,"value":62},"(c) 出力 (rendered\u002Ffinal_T\u002Flast_contributor) の書き込み帯域","**候補として成立しない (禁忌+精度制約の二重ブロック)**。task 冒頭の禁忌リストが f16 storage\u002Fforward を明示的に禁止しており、`rendered` の quantize は不可。`final_T`\u002F`last_contributor` は backward の勾配式 (`rasterize_backwards.metal` 冒頭の論証) が f32 精度をそのまま要求するため精度を落とせない。3 buffer 個別書き込み (24B\u002Fpixel、640,000px = 15.36MB\u002Fiter、image size 不変なので毎 iter 固定) を 1 struct にまとめても総 byte 数は不変、$2 の帰結 (forward は帯域 1 割未満) からもこの経路の削減は wallclock にほぼ効かない",{"key":64,"value":65},"(d) conic\u002Fcolor の load 幅 (float4 化)","**低 payoff と判断、候補から実質除外**。§2 の byte-accounting で forward の実効帯域到達率が公称 410GB\u002Fs の \u003Cstrong>~8.5〜8.7%\u003C\u002Fstrong> と判明した — backward audit (d) の broadcast-read 論証 (L1 が既に broadcast 済み) と同型の帰結だが、forward の staging read は per-tile-visit の gather read (broadcast ではない) という点で backward とは性質が違う。それでも「そもそも帯域の 1 割も使っていない」以上、36B→float4 aligned 化で削れる byte 数がどうであれ wallclock 改善には直結しない (律速は ALU\u002Flatency 側)。producer (`project.rs`) と consumer (forward kernel) 双方に触る高工数でもあり、期待 Δ\u002F工数比が悪い",{"key":67,"value":68},"(e) occupancy (register 数)","**ツール限界、追加候補立てられず — backward 監査と同じ結論**。この (headless) 環境には Xcode GPU Frame Capture 相当のツールがなく、on-device register 割り当て (driver JIT) を直接観測できない (p3-backward-audit §1(e) と同じ限界)。静的に確認できたのは TG memory 使用量のみ: `local_batch[256]` (Splat2D 36B×256=9,216B) + `atomic_uint` (4B) = 9,220B、Apple GPU の TG memory 上限 (通常 32KB) の 28% — TG memory 律速の可能性は低いと推測できるが、register spill は別問題で観測手段がない。副次的に AIR level (`xcrun -sdk macosx metal -O3 -std=metal3.1 -ffast-math -S`) で `exp()` が既に `air.fast_exp.f32` (近似 intrinsic) に lowering されていることを確認した — これは `-ffast-math` を明示した本コマンドの結果だが、`splat-metal::Device::compile` は `MTLCompileOptions.fastMathEnabled` を `shader_fast_math` (device.rs、**default = true**、Metal API 自体の default でもある) から設定しており、production 既定のビルドで\u003Cstrong>既に\u003C\u002Fstrong> fast exp が使われている。つまり「exp を fast path に切り替える」という誰もが次に思いつく候補は\u003Cstrong>既に default で実施済み\u003C\u002Fstrong>であり、追加の余地はない (これも記録する価値のある closure)",{"type":49,"text":70},"2. adam の帯域床 — 自前 byte-accounting による再計算",{"type":52,"items":72},[73,76,79,82],{"key":74,"value":75},"(f) 帯域床の再計算","**再計算完了、~90〜93% 到達 (ほぼ飽和) — 旧「65.6%」は出典不明、今後は本値を正とする**。1 splat あたりの adam element 数: means 3 + log_scales 3 + rot_quats 4 + raw_opacities 1 + sh_coeffs (`max_coeffs`=16、`sh_degree=3`、`num_sh_coeffs`=`(d+1)^2`) × 3 = 48 → \u003Cstrong>計 59 element\u002Fsplat\u003C\u002Fstrong> (`sh_progressive` (init=0\u002Fmax=3\u002Funlock_interval=1000) は active SH degree を段階解放するだけで、`adam.rs::encode_step`\u002F`step_buf` は常に `param.max_coeffs` 全体を dispatch するため sh_coeffs の element 数はこれで不変であることを adam.rs 読解で確認済み)。1 element あたりの byte 数: read (grad 4B + m 4B + v 4B + param 4B = 16B) + write (m 4B + v 4B + param 4B = 12B) = \u003Cstrong>28B\u002Felement\u003C\u002Fstrong> → \u003Cstrong>1,652 B\u002Fsplat\u003C\u002Fstrong>。\u003Cstrong>平均 splat 数 321,637\u003C\u002Fstrong> (p3-final-stack、M7 final-stack r2-r4 の trapezoid 積分による自前算出値、旧 322k 推定と 0.1% 差で一致) を使うと \u003Cstrong>531.3 MB\u002Fiter\u003C\u002Fstrong>。per-kernel share v2 (`p3-kernel-share-post-s3` §6) の `ts_adam` gpu_ms\u002Fiter (v1 1.438ms、M4\u002FA7 前 \u002F v2 1.400ms、M4\u002FA7 後 — いずれも adam 自体は M4 (radix)\u002FA7 (refine) に触れられていないので近い値のはず、という予想どおり) と組み合わせると実効帯域 \u003Cstrong>369.5〜379.5 GB\u002Fs\u003C\u002Fstrong>。この Mac の実機仕様 (`system_profiler`: Apple M4 Max、14-core CPU\u002F32-core GPU、36GB — WebSearch で Apple 公式値 410GB\u002Fs と確認、上位 16-core\u002F40-core 構成の 546GB\u002Fs とは別) を分母にすると \u003Cstrong>到達率 90.1〜92.6%\u003C\u002Fstrong>。**この計算には「gpu_ms\u002Fiter が 12,500 iter 全体の平均値である以上、splat 数も同じ平均 (321,637) を使わねばならず、最終 splat 数 (407,028、同じく p3-final-stack) を使ってはいけない」という罠がある** — 実際に最終 N で計算すると 672.4MB\u002Fiter ÷ 1.400ms = 480.3GB\u002Fs = \u003Cstrong>117%\u003C\u002Fstrong> という物理的に不可能な値が出る (これ自体が「最終 N を使うと過大評価になる」ことの直接証拠)。90〜93% という到達率は「pow hoist\u002Ff16 のような ALU 側最適化に意味のある headroom はない」という既存の closure 判断を裏づける — ただし §で述べる通り、その closure が引用してきた具体的な数値「65.6%」自体の出典は本監査では確認できなかった",{"key":77,"value":78},"旧「65.6%」の出典調査","`docs\u002Fstrategy\u002F2026-08-next-phase-tasklist.md:46` (「adam の pow hoist\u002Ff16 (帯域床 65.6% + grad 1e-14 の FTZ で数値的に閉鎖)」) と `docs\u002Fstrategy\u002F2026-09-seminar05-milestones.md:188` (「adam 13.8% は帯域床 65.6% で閉鎖済み」) が同じ 65.6% を引用しているが、`grep -rn adam docs\u002Fstrategy\u002Fraw\u002F*.json | grep -iE '帯域|bandwidth|GB\u002Fs|床'` (4 軸再監査の生ログ) では adam 固有の帯域算出は 1 件もヒットしなかった。一方 `docs\u002Ffindings\u002Fp2-counter-session.toml:264` の per-kernel 表に \u003Ccode>[\"iter5000 \u002F per_kernel\", \"17.869\", \"65.6%\", ...]\u003C\u002Fcode> という行があり、この列は adam 個別ではなく\u003Cstrong>その run 全体の GPU busy%\u003C\u002Fstrong> (非 production な `per_kernel` submission regime) である。`2026-09-seminar05-milestones.md:19` 自身も「c1v2 run の 65.6% は per_kernel\u002Fper_stage の非 production 測定専用 regime の値であり使えない」と明記しており、これは \u003Cstrong>adam の帯域到達率とは無関係な、別の run の GPU busy% を指している可能性が高い数値\u003C\u002Fstrong>である。同一の数値が 2 つの異なる意味 (「ある run 全体の GPU busy%」と「adam kernel 固有の帯域到達率」) で引用されている状態であり、\u003Cstrong>誤用と断定できる証拠はない (出典ログが既に失われている可能性がある) が、今後は §(f) で自前導出した 90〜93% を adam の帯域到達率として引用すべきで、65.6% を再利用しないことを推奨する\u003C\u002Fstrong>",{"key":80,"value":81},"(g) buffer 数 \u002F dispatch 数","**既に対応済み — 追加候補なし**。`adam.rs::encode_step` (W2 Stage A) が 5 param group を 1 command buffer \u002F 1 encoder \u002F 5 dispatch に統合済み (task 記載の「5 CB→1 済み」を `chained_step_matches_per_kernel_byte_exact` test の存在で再確認)。5 dispatch を 1 dispatch に melt する (SoA flatten + offset table) 案も検討したが、各 group の grad tensor が別 buffer object であり同一 dispatch に混在させるには indirect buffer \u002F offset table 経由の間接参照が要る (= ArgBuffer 系、task 禁忌 !31 に抵触するリスクが高い構造) — 却下。5 dispatch 自体の launch overhead は n が数十万〜百万要素あるため相対的に無視できる規模と推測され、削っても bandwidth-bound kernel の wallclock には効かない (§(f) の帰結と整合)",{"key":83,"value":84},"(h) grad=0 splat の visible-only skip (非 bit-exact、候補のみ)","task 指定どおり **非 bit-exact のため段 2 実装対象外、候補としてのみ記録**。`2026-09-seminar05-milestones.md` M6 (J2 ユーザー判断待ち) が同じ着想を「visible-only Adam (gsplat `sparse_grad` 相当)」として既に spec 化しており、本監査はこれを追認するに留まる。§(f) の byte-accounting から言えること: adam が到達率 90〜93% で帯域飽和している以上、\u003Cstrong>bytes を減らす\u003C\u002Fstrong> (h) 以外に理論的な削減手段はない (pow hoist 等の ALU 側最適化は帯域の影で完全に隠れる)。期待 Δ の上限は「不可視 splat の割合 × adam share (15.28%)」— 具体的な不可視割合は本 session では計測していない (visibility mask 自体の生成コストとのトレードオフも未評価)。J2 の判断が下りるまで実装しない",{"type":49,"text":86},"3. rasterize forward の帯域到達率 — 詳細計算",{"type":52,"items":88},[89,92,95],{"key":90,"value":91},"staging read","`splats[sorted_idx[batch_start+lid]]` は tile ごとに visible (splat, tile) pair を 1 回ずつ 36B (Splat2D = 9 float) 読む gather read。407,267-splat checkpoint での実測 pair 数は 969,838 (`splat bench --parity` 実測、p3-radix-ballot §0 の \u003Ccode>sorted_idx\u003C\u002Fcode> 記述より)。avg splat 数 (321,637) \u002F final splat 数 (407,267) ≈ 0.7898 を線形スケールした概算 avg pairs ≈ \u003Cstrong>765,900\u003C\u002Fstrong> (pair 数は splat の footprint に比例し splat 数に厳密比例しないため、この概算は\u003Cstrong>桁のオーダーとしてのみ\u003C\u002Fstrong>信頼できる — ただし後述のとおり結論の頑健性はこの誤差に依存しない)。staging read ≈ 765,900×36B = 27.57MB、加えて `sorted_idx` 自体の読み出し 765,900×4B = 3.06MB",{"key":93,"value":94},"output write","`out` (float4, 16B) + `final_T_out` (float, 4B) + `last_contrib_out` (u32, 4B) = 24B\u002Fpixel、800×800 = 640,000 pixel は image size 不変で毎 iter 固定 → 15.36MB\u002Fiter",{"key":96,"value":97},"合計と到達率","46.0MB\u002Fiter (概算) ÷ `ts_fwd_rasterize` gpu_ms\u002Fiter (v1 1.320ms \u002F v2 1.295ms、p3-kernel-share-post-s3 §6) = \u003Cstrong>34.9〜35.5 GB\u002Fs\u003C\u002Fstrong> → 410GB\u002Fs 比 \u003Cstrong>8.5〜8.7%\u003C\u002Fstrong>。avg pairs の概算誤差がたとえ数倍あっても (仮に 10 倍過小評価だったとしても 85〜87% にしかならず帯域飽和の adam と同水準に達する可能性はゼロではないが)、969,838 という実測 pair 数 (final checkpoint) をそのまま使っても staging read は 34.9MB (÷46.0MB 全体の 76%) にしかならず、10 倍の過小評価は物理的にありえない (avg splat 数が avg pairs の下限を規定する — avg splats 321,637 で avg pairs が final の 969,838 を\u003Cstrong>超える\u003C\u002Fstrong>ことはまず無い) ため、\u003Cstrong>「forward は ALU\u002Flatency-bound であり帯域律速ではない」という結論は概算の誤差に対して頑健\u003C\u002Fstrong>と判断した",{"type":49,"text":99},"4. 候補表 (上位 5 件 + 既存の敗退\u002F禁忌の参考枠)",{"type":101,"columns":102,"align":109,"rows":111},"table",[103,104,105,106,107,108],"候補","kernel \u002F 観点","期待 Δ","bit-exact 性","工数","既知の敗因・禁忌との衝突",[110,110,110,110,110,110],"left",[112,119,126,133,139,146,152],[113,114,115,116,117,118],"forward: `num_done_atomic` 初期化直後の barrier 1 本削除","(b)","harness 分解能未満 (forward は ALU-bound、帯域到達率 8.5〜8.7% で barrier 律速ではないと自己整合的に判断)","**bit-exact** (読み手が loop 先頭 1 箇所のみ、単調増加カウンタの過小評価は正しさに無関係、`grep -rn num_done` で確認)","低 (shader 2 kernel + 1 行削除)","衝突なし、ただし期待 Δ が小さく実装優先度は低い",[120,121,122,123,124,125],"adam: visible-only skip (M6\u002F(h))","(h)","不明 (不可視 splat 割合 × adam share 15.28% が理論上限、未計測)","**非 bit-exact** (moment decay semantics 変化)","中","J2 ユーザー判断待ち、task 指定で段 2 対象外",[127,128,129,130,131,132],"forward: conic\u002Fcolor float4\u002FSoA 化","(d)","低 (帯域到達率 8.5〜8.7% — 帯域削減系の payoff が原理的に薄い)","bit-exact (理論上)","高 (producer project.rs + consumer 両方)","backward audit (d) の broadcast-read 論証と同型の低 payoff 判定、producer 変更の高工数",[134,135,136,137,137,138],"forward: 出力 packing (f16 \u002F struct 統合)","(c)","無し (禁忌 + 精度制約の二重ブロック)","N\u002FA","**f16 storage\u002Fforward 禁忌に抵触**、final_T\u002Flast_contributor は backward が f32 精度を要求",[140,141,142,143,144,145],"forward: simd_all(done) による inner loop 早期打ち切り","(a)","≈0 (execution mask 収束と原理的に redundant)","bit-exact (実装しても no-op)","低","backward W1a は reduction\u002Fatomic emit を持つが forward には無い — 構造的に成立しない候補",[147,148,149,137,150,151],"(参考) forward: fast exp への切替","(e)","既に default で実施済み (AIR で `air.fast_exp.f32` 確認、`shader_fast_math` default=true)","—","候補として提案する意味がない (closure として記録)",[153,154,155,156,150,157],"(参考) adam: pow hoist (bc1\u002Fbc2 の per-thread 重複計算)","(f)","既知: 帯域飽和 (90〜93%) の影に隠れ wallclock 効果ほぼ無し","bit-inexact の可能性 (CPU pow vs GPU pow の bit 差)","**tasklist 既存の禁忌に整合、本監査の byte-accounting でも再確認**",{"type":159,"label":160,"variant":161,"text":162},"callout","forward は帯域到達率 ~9% (ALU-bound)、adam は ~90〜93% (帯域飽和) — 正反対の律速構造","warning","本 finding の実測的な核心は「bit-exact 候補が見つからなかった」ことそのものより、\u003Cstrong>forward と adam が正反対の律速構造を持つことを自前の byte-accounting で初めて定量化した\u003C\u002Fstrong>ことにある。adam は 1 thread = 1 element の純粋な elementwise kernel で reuse が一切なく (memory-bound の教科書的な形)、410GB\u002Fs 公称帯域の 90〜93% まで到達している — \u003Cstrong>これ以上速くする手段は理論上 bytes を減らすこと (h、visible-only skip、非 bit-exact) しかない\u003C\u002Fstrong>。forward は per-splat の ALU 演算 (sigma 計算 + `exp` + 分岐) が中心で、staging read はほとんどが threadgroup memory 内の broadcast\u002Freuse で吸収され、device memory への実際のトラフィックは合計しても 46MB\u002Fiter 程度 (帯域の 1 割未満) — \u003Cstrong>帯域を減らす方向の候補 ((c)\u002F(d)) はどれだけ効率化しても wallclock にはほぼ効かない\u003C\u002Fstrong>ことが、backward audit のような「候補を実装してから regression が判明する」のではなく\u003Cstrong>実装前の計算で\u003C\u002Fstrong>示せた。M2 Tier1 (Δ -1.11%、判定不能) と M5a (SSIM float4_rcp、Δ -0.055%、null) が確立した harness 分解能 (~1%) を踏まえると、本監査で見つかった唯一の bit-exact 候補 (forward の barrier 1 本削減) もこの床を超える見込みが薄く、\u003Cstrong>段 2 (実装) は task 記載の「候補が全て \u003C1% なら省略」に従って実施しなかった\u003C\u002Fstrong>。",{"type":49,"text":164},"5. 段 2 (実装) を省略した判断根拠",{"type":166,"items":167},"list",[168,169,170,171],"task 指定条件: 「候補が全て \u003C1% なら段 2 は省略し、その旨を finding に書く」— 本監査は forward 5 候補・adam 3 候補いずれについても、bit-exact-class かつ期待 Δ が harness 分解能 (~1%) を明確に超えるものを 1 件も見つけられなかった","forward の唯一の bit-exact 候補 (barrier 1 本削除、§1(b)) は安全性を確認済みだが、forward 自体が ALU\u002Flatency-bound (帯域到達率 8.5〜8.7%、§3) という自己整合的な理由により、barrier 数を削っても wallclock 改善が harness 分解能を超える可能性は低いと判断した — 実装コストは低い (shader 2 箇所の行削除) ため、将来 harness 分解能が向上した場合や他の ALU 側施策との合算 gate で再検討する価値は残る","adam は §2(f) の再計算で帯域到達率 90〜93% (ほぼ飽和) と確認でき、bit-exact な候補は理論上存在しない (bytes を減らす (h) は非 bit-exact で J2 判断待ち) ことを実測的に裏づけた — これは『pow hoist\u002Ff16 は閉鎖済み』という既存判断を、出典不明だった「65.6%」の代わりに自前の数値で裏づけ直したことに相当する","GPU run は本監査を通じて 1 度も起動していない (byte-accounting は既存の per-kernel share v2 \u002F p3-final-stack の実測値の再利用のみ、AIR 確認は `xcrun metal` のオフラインコンパイルのみ) — `pgrep -fl \"target\u002Frelease\u002Fsplat\"` の空確認は当初想定していたが、GPU run を起動しなかったため不要だった",{"type":49,"text":173},"6. 未解決点・次段への引き継ぎ",{"type":166,"items":175},[176,177,178,179,180],"**forward の avg pairs 概算 (765,900) は 1 点の final checkpoint (407,267 splats → 969,838 pairs) を平均 splat 数比でスケールした概算であり、pair 数は splat footprint (densification で split されるほど個々の footprint は縮む) に比例するため splat 数への線形スケールは正確ではない** — ただし §3 で示した通り、結論 (ALU-bound、帯域到達率 1 割未満) はこの誤差に対して頑健 (10 倍近い過小評価がない限り帯域飽和には届かない)。正確な avg pairs を得るには 12.5k run 全体を通した `ts_fwd_emit_pairs` の出力サイズ trajectory を記録する計装が要る (本 session では未実施)","**forward の register spill \u002F occupancy は本環境では直接観測できない** (backward audit §1(e) と同じ限界、Xcode GPU Frame Capture 相当のツールが無い) — GUI 環境がある session であれば `render_splats_f32` の実際の register 使用数を見て (e) を再監査する価値がある","**adam の byte-accounting は 2 つの異なる run から数値を合成している** (avg splat 数 321,637 は M7 final-stack r2-r4、gpu_ms\u002Fiter 1.400\u002F1.438ms は c1v2\u002Fc1 の per_kernel\u002Fper_stage 非 production run) — 両 run は同じ `[refine]` hyperparameter で走らせているため densification trajectory は近いはずだが、同一 run で両方を計測する追試 (12.5k 1 run で `ts_adam` gpu_ms trajectory と splat 数 trajectory を両方ログする) を行えば 90〜93% という到達率レンジをより狭い区間に絞れる","**「65.6%」の出典は本監査で追跡しきれなかった** — `docs\u002Fstrategy\u002Fraw\u002F*.json` (4 軸再監査の生ログ) に adam 固有の帯域算出が見当たらず、`p2-counter-session.toml` の非 production run GPU busy% と同一数値であることのみ確認できた。誤用と断定する証拠 (例えば当該 tasklist 行を書いた session の生ログや commit メッセージ) は本 session の探索範囲では見つからず、断定は避けた — 次段で `git log -p -- docs\u002Fstrategy\u002F2026-08-next-phase-tasklist.md` などで当該行の追加 commit を辿れば出典が確定できる可能性がある","**adam (h) visible-only skip の期待 Δ 上限が未計測** — 不可視 splat の割合 (view frustum + tile 非交差) を実際に計測すれば M6 着手時の優先度判断に使える具体的な数字が出せる (GPU run 不要、既存 checkpoint + visibility mask 計算のみで可能)",[],[183,203,230,253,278,305,346],{"id":31,"title":184,"date":9,"status":10,"polarity":12,"category":11,"axes":185,"tags":186,"task_code":196,"related_runs":197,"delta_psnr":198,"delta_wallclock":199,"rank":40,"verdict":200,"impact_summary":201,"detail_path":202},"backward_raster kernel 監査 — per-pixel 構造保持の残余候補 6 件、atomic emit lane 分散 (M8) を実装するも 3\u002F3 pair で小さい regression (NO-GO)",[14],[187,18,188,189,190,191,192,193,23,194,195],"backward-raster","atomic-float","simd-sum","parity","self-noise","backend-config","regression","per-pixel","m8","p3-backward-audit (段1: 監査 \u002F 段2: M8 atomic emit lane 分散の実装+gate screen)",[],"N\u002FA (bench replay は 1 checkpoint に対する forward+backward+adam 反復であり学習軌道ではない。12.5k gate は regression 判明のため未実施)","**whole-iteration replay bench 3 pair 交互 (実 checkpoint 408,469 splats、800×800、iters=50×repeats=3、pipelining=off、production regime = submission\u002Fforward_submission ともに chained、`configs\u002F2026-08-30-bwd1-bench-{off,on}.toml`)**: median ms\u002Fiter off→on = 13.564→13.731 (+1.23%) \u002F 13.600→13.812 (+1.56%) \u002F 13.595→13.753 (+1.16%)、平均 13.586→13.765ms\u002Fiter = **+1.32%**。GPU busy ms\u002Fiter 平均 10.752→10.969 = **+2.02%**、sync-tax はほぼ不変 (2.83ms\u002Fiter 前後、3 pair とも)。σ は各 repeat 内 n=3 で 0.03〜1.19%。**backward kernel 単体 (`ts_backward_raster` gpu_ms、per_kernel\u002Fper_stage 計測 regime、`configs\u002F2026-08-30-bwd1-bench-{off,on}-perkernel.toml`、150 call = 3 repeats×50 iters)**: off **4.2016 ms\u002Fcall** → on **4.3670 ms\u002Fcall** = **+3.94%**。この regime の wallclock (off 15.191ms\u002Fiter, GPU busy 69.0% \u002F on 15.361ms\u002Fiter, busy 69.4%) は non-production 専用 (busy が低く比較に使えない、上記 production regime の値が主) だが、`ts_backward_raster` gpu_ms は kernel 単体の直接計測として有効。","m8-atomic-spread-correct-but-slower-not-recommended-for-default \u002F audit-finds-no-headroom-above-harness-floor","backward_raster (per-kernel share v2 で 40.07%、単独最大) を per-pixel 構造を保ったまま削る候補を 6 件監査した (段 1)。すでに勝者化済みの施策 (SIMD group reduction \u002F W1a warp sparse skip+exp-skip \u002F last_contributor 早期終了) と禁忌リスト (Tg staging、f16、SIMD prefix、reduction) を除くと、残る候補はいずれも大きい Δ を期待できず、harness の実測分解能 (~1%、M2 Tier1 が -1.11% を「判定不能」、M5a が -0.055% を「null」と判定した床) 前後に収まる可能性が高いという見立てになった。最有力候補として選んだのは \u003Cstrong>M8: `rasterize_backwards_simd` の 9 atomic emit を lane 0 の 1 lane だけでなく lane 0..8 の 9 lane に分散発行する\u003C\u002Fstrong>変更 — `simd_sum` が 9 成分の合計を全 32 lane に broadcast する性質を使い、emit する (address, value) の集合を一切変えずに発行 lane だけ変える (新しい算術を持ち込まない「弱い意味で bit-exact」な変更)。`BackendConfig.raster_backward_atomic` (`lane_zero` default \u002F `spread_lanes`) で flag-gate し、専用 PSO は現行 default combo (`Simd` + `LastContributor` + `WarpAny`) にのみ追加した (他 combo は validate warning 付きで silent fallback、既存の `raster_backward_sparse` と同じ規約)。**正しさ**: 24-splat 合成 tile の単一 pixel fixture で bit 一致 (新規 test 2 本、`backward_atomic_spread_byte_equality_single_pixel` \u002F `_parity_simd`)、実 checkpoint (12500 iter 生成、408,469 splats、PSNR 36.202 dB) での `splat bench --parity` は候補比較が FAIL することがあるが、**同じ config を自分自身と比較する self-check でも全く同じ頻度・同じ max_abs_diff (通常時 5.245e-5 \u002F 稀に 1.469e-4) で FAIL\u002FPASS する**ことを確認し、これが M8 固有の誤差でないことを実証した (発生機序自体は atomic 順序 self-noise \u002F `sorted_idx` tie-order 非決定性のどちらとも確定できておらず、§4 callout に切り分けの詳細を記す)。**性能 (whole-iteration)**: 短時間 replay bench (12.5k 相当 checkpoint、iters=50×repeats=3、pipelining=off、production regime = submission\u002Fforward_submission ともに `chained`) を off\u002Fon 交互 3 pair 実施したところ、**3\u002F3 pair で on が遅い**(median ms\u002Fiter: 13.564→13.731 \u002F 13.600→13.812 \u002F 13.595→13.753、平均 13.586→13.765 = **+1.32%**、GPU busy 平均 10.752→10.969 ms\u002Fiter = **+2.02%**)。**性能 (backward kernel 単体 gpu_ms)**: production regime では `ts_backward_raster` の `gpu_ms` が非ブロッキング harvest の帰属漏れで 0 に落ちる (既知の限界、`docs\u002Farchitecture\u002Fbackend-and-compiler-conventions.md` §4) ため、p3-kernel-share-post-s3 C1 と同じ `submission=per_kernel`\u002F`forward_submission=per_stage` regime で同一 checkpoint を計測した。**`ts_backward_raster` gpu_ms\u002Fcall: off 4.2016ms → on 4.3670ms = +3.94%** (150 call = 3 repeats × 50 iters、両 arm とも n=3 の repeat 内 σ ≤0.4%) — whole-iteration の +1.32%\u002F+2.02% が「kernel 自体が遅くなったこと」に直接帰属できることを、share からの推論ではなく実測で確認した。advisor が指摘していた「lane 0 の 9 atomic は既にハードウェアがパイプライン化している可能性があり、spread の win は nil かもしれない」という懸念が的中し、むしろ select chain のオーバーヘッドがわずかに上回った形の **小さいが一貫した regression**。**NO-GO、default は `lane_zero` のまま変更しない**。12.5k full gate 用 config 6 本は `splat check` で deserialize 確認済みだが、bench screen の時点で明確な regression のため実行しなかった。`cargo build --release` + `cargo test --workspace --release` (全 175 test、新規 2 本含む) は全 pass、default 動作 (既存挙動) は無変更。","\u002Ffindings\u002Fp3-backward-audit\u002F",{"id":33,"title":204,"date":9,"status":10,"polarity":205,"category":11,"axes":206,"tags":208,"task_code":217,"related_runs":218,"delta_psnr":224,"delta_wallclock":225,"rank":226,"verdict":227,"impact_summary":228,"detail_path":229},"M7 最終スタック確定 — 12.5k 124.39s (独立 n=3)、msplat 等価 gap 0.927×→0.755×、throughput 1.135×負け→0.926× (msplat 側 avg splats 借用値 ±8% 未満なら逆転)","positive",[14,207],3,[209,210,211,212,213,214,23,215,216],"m7","seminar05-milestones","final-stack","msplat-parity","pareto-v3","throughput-parity","gpu-gate","independent-remeasurement","2026-09-seminar05-milestones M7 (最終スタック確定 + msplat 等価再比較 + Pareto v3)",[219,220,221,222,223],"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×負けから逆転)","high","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":32,"title":231,"date":9,"status":10,"polarity":232,"category":233,"axes":234,"tags":235,"task_code":245,"related_runs":246,"delta_psnr":248,"delta_wallclock":249,"rank":226,"verdict":250,"impact_summary":251,"detail_path":252},"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 提案のみ)","mixed","measurement",[14,207],[236,209,210,237,238,187,239,240,241,23,242,243,244],"m1","kernel-share","per-kernel-gpu-ms","m3-go-gate","residual-bubble","gputime","post-s2-s3","v2","post-m4-a7","2026-09-seminar05-milestones M1 (C1 per-kernel 再計測 + C2 残差 bubble 帰属)",[247,223],"c1-12500-off-prof","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 のみ","m3-go-backward-raster-33.9pct \u002F c2-instrumentation-gap-proposal-only","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 はこれ以上起動していない)。","\u002Ffindings\u002Fp3-kernel-share-post-s3\u002F",{"id":34,"title":254,"date":9,"status":10,"polarity":205,"category":11,"axes":255,"tags":256,"task_code":265,"related_runs":266,"delta_psnr":273,"delta_wallclock":274,"rank":226,"verdict":275,"impact_summary":276,"detail_path":277},"M4\u002FA5 radix_scatter simd_ballot 2段化 — 12.5k gate 採用、-14.9%、default flip",[14,207],[257,258,259,260,261,262,23,215,263,264],"m4","a5","radix-scatter","simd-ballot","tile-bin","sort-parity","adopted","default-flip","2026-09-seminar05-milestones — M4 (A5 radix scatter simd_ballot)",[267,268,269,270,271,272],"m4-12500-off-r1","m4-12500-on-r1","m4-12500-off-r2","m4-12500-on-r2","m4-12500-off-r3","m4-12500-on-r3","12.5k 同一 session 交互 A\u002FB n=3: on **36.143 dB** (36.15227 \u002F 36.05730 \u002F 36.21933) vs off **36.121 dB** (36.19775 \u002F 36.01755 \u002F 36.14695) = **+0.022 dB**。task 指定 guard (on mean ≥ off mean − 0.05 dB) に **pass** (+0.022 > -0.05)。config header の絶対 guard (36.202 ± 0.1 dB、帯 [36.102, 36.302]) にも on\u002Foff とも **pass**。final splats は on 408,084 (408,408 \u002F 409,074 \u002F 406,770) \u002F off 409,363 (408,928 \u002F 411,049 \u002F 408,113) で on が -0.31% 少ない (既存 atomic 非決定性 chaos の範囲内、方向は一貫していない)。sort parity は `tile_offsets` で byte-exact だが、同じ parity report は `sorted_idx` の 0.217% (2105\u002F969838) に既知の tie-order 非決定性を記録しており、これが rasterize 順序ひいては atomic 加算順序に伝播するため end-to-end の PSNR は parity だけでは pin されない — したがって観測された小さい非方向性の PSNR 散らばりは想定内であり、M2 Tier1 gate (p3-tier1-bit-exact) が観測したような系統的分離は見られない","12.5k full run 同一 session 交互 A\u002FB n=3: **off 149.883s (σ 0.591%) → on 127.530s (σ 0.794%) = -14.914%**。3 pair 個別 Δ は -14.72% (r1) \u002F -15.15% (r2) \u002F -14.87% (r3) とレンジ 0.43 pt の高い一貫性。有意閾値 max(2σ_off,1%) = 1.182%、実測 Δ は**その 12.6 倍**。σ 非対称比 1.34× (off\u003Con) は汚染の典型署名とされる 3× を大きく下回り、on 側が GPU 律速でむしろ host jitter に鈍いという機構と整合する。replay bench (p3-radix-ballot 旧版、production default stack、n=3、GPU 専有未確認) の -12.9%〜-13.3% という directional 参考値とも整合し (12.5k full run のほうがやや大きい -14.9%、407k 固定 checkpoint 断面と 12.5k 平均 pair 数分布の違いで説明可能)、forward_submission=per_stage での radix 単独 gpu_ms -63.7% とも方向・大きさの両方で整合する","adopted-default-flip-radix-scatter-simd-ballot","tasklist A5 (radix は帯域 36% の latency 律速と算術証明済み) の実装検証。既存 O(lid) 逐次 threadgroup memory scan を simdgroup ballot 2 段化に置換し、BackendConfig `radix_scatter` の enum variant `simd_ballot` として追加、**2026-08-30 M4 GPU gate で default に採用**。sort parity は unit test 3 本 (境界サイズ 0\u002F1\u002F255\u002F256\u002F257\u002F1234\u002F100000、ties 多発 n=5000、3 種の radix_scan 実装すべて) と本番規模 (407,267 splats) `splat bench --parity` の両方で bit exact PASS。**12.5k Lego 同一 session 交互 A\u002FB n=3 (off-r1→on-r1→off-r2→on-r2→off-r3→on-r3、独立 10s load sampler で汚染監視、binary sha256 は series 前後で不変) で train elapsed 149.883 → 127.530s = -14.9%**、3 pair 個別 (-14.72% \u002F -15.15% \u002F -14.87%) が高い一貫性を示し、有意閾値 max(2σ_off,1%)=1.18% の **12.6 倍**という大差で通過。σ は off 0.59% \u002F on 0.79% (非対称比 1.34×、汚染の署名である 3× を大きく下回る)。**PSNR guard も pass** (on mean 36.143 dB ≥ off mean 36.121 dB − 0.05 dB、Δ +0.022 dB、両 arm とも config header の絶対 guard 36.202±0.1 dB にも収まる)。final splats は on 408,084 \u002F off 409,363 で -0.31% (既存 atomic 非決定性 chaos の範囲内)。session 開始時の ambient load 18.86〜22.8 (Spotlight `mediaanalysisd`\u002F`mds_stores` 再インデックス、reboot 後) という p2-s3 が破棄基準にした汚染クラスの中で実施したが、同一 session 交互設計と 3 pair の高い一貫性 (レンジ 0.43 pt) がこれを吸収したことを §0 で示す。**結論: 採用。`RadixScatterKind::default()` を `SimdBallot` に flip、`cargo test --workspace --release` 全 pass**。","\u002Ffindings\u002Fp3-radix-ballot\u002F",{"id":35,"title":279,"date":9,"status":10,"polarity":12,"category":11,"axes":280,"tags":281,"task_code":289,"related_runs":290,"delta_psnr":299,"delta_wallclock":300,"rank":301,"verdict":302,"impact_summary":303,"detail_path":304},"M5a A6 SSIM float4 化 — stage1 (float4) は byte-exact 確認済み・PSNR riskゼロ、stage2 (float4_rcp) は 12.5k gate で PSNR guard 抵触・不採用",[14,207],[282,210,283,284,285,21,286,215,287,288,23],"m5a","ssim","float4","reciprocal-sharing","bit-exact","rejected","psnr-guard-fail","2026-09-seminar05-milestones M5a (A6 SSIM float4 化、3ch 単一 walk)",[291,292,293,294,295,296,297,298],"m5a-12500-off-r1 (contaminated, discarded, re-run once)","m5a-12500-on-r1 (contaminated, discarded, re-run once)","m5a-12500-off-r1 (redo, used)","m5a-12500-on-r1 (redo, used)","m5a-12500-off-r2","m5a-12500-on-r2","m5a-12500-off-r3","m5a-12500-on-r3","12.5k 同一 session 交互 A\u002FB n=3 (1 pair 再実行後): on **36.1327 dB** (36.156 \u002F 36.170 \u002F 36.072) vs off **36.2133 dB** (36.256 \u002F 36.204 \u002F 36.180) = **Δ -0.081 dB**。task 指定 guard (on mean ≥ off mean − 0.05 dB) に **fail** (-0.081 \u003C -0.05)。3 pair とも on\u003Coff で完全分離、方向一致。on-r3 (36.072 dB) は config header の絶対 guard 帯 [36.102, 36.302] の下限を割り込む唯一の値","12.5k full run 同一 session 交互 A\u002FB n=3 (r1 は汚染疑いで 1 回再実行): **off mean 126.954s (σ 1.264%) → on mean 126.884s (σ 4.314%) = Δ -0.055%**。有意閾値 max(2σ_off,1%) = 2.528%、実測 Δ はこれに遠く届かない **null 結果**。3 pair 個別 Δ は +3.62% (r1, redo) \u002F -2.24% (r2) \u002F -1.61% (r3) と符号が一致しない。σ 非対称比 3.41× (on>off) は p3-tier1-bit-exact の汚染署名域に近いが、r1 は既に 1 回再実行済みのため追加再実行はしていない (§4 参照、PSNR guard が既に不採用を決定づけているため追加の GPU 消費は不要と判断)","low","rejected-psnr-guard-float4rcp-null-wallclock-float4-standalone-untested","SSIM の walk 方式を選べる BackendConfig `[backend] ssim_walk` (`per_channel` default \u002F `float4` \u002F `float4_rcp`) を実装し、shader (`ssim_forward_float4`, `ssim_backward_rcp`) と Rust 配線 (`SsimEvaluator`, `Trainer`, `apply_backend_config`, result.toml item) を完結させた。\u003Cstrong>stage 1 (float4 化 forward) は K=7\u002FK=11 の単体 test + 本番規模 (407,267 splats) `splat bench --parity` の両方で byte-exact\u003C\u002Fstrong> — PSNR risk がゼロの再挑戦候補として残す。\u003Cstrong>stage 2 (逆数共有 backward) の REL_TOL は実測ベースで 2e-4 に確定\u003C\u002Fstrong> (K=7 max_rel=8.4519e-5 \u002F K=11 6.3679e-5、旧 2-divide 実装の 8.28e-5 とほぼ同水準 — fast math 近似逆数の精度floorが支配的で除算回数削減の理論的優位はほぼ観測できなかった)。3-way replay bench (`submission=per_kernel` で ssim label を分離) では float4_rcp の ssim label gpu_ms が per_channel 比 -20.8% (758.92→601.06ms\u002F600calls) と明確に縮小したが、\u003Cstrong>12.5k Lego 同一 session 交互 A\u002FB n=3 gate (「採用候補の最終形 = float4_rcp」を一括計測) では PSNR guard に抵触し不採用\u003C\u002Fstrong>: on mean 36.1327 dB (36.156\u002F36.170\u002F36.072) vs off mean 36.2133 dB (36.256\u002F36.204\u002F36.180)、Δ -0.081 dB は guard 閾値 -0.05 dB を超過、3 pair 全てで on\u003Coff の完全分離という系統的な質低下だった。wallclock は Δ -0.055% (off mean 126.954s → on mean 126.884s) で有意閾値 max(2σ_off,1%)=2.53% に届かず null。§5 で示す通り、ssim の budget share (11.80%、p3-kernel-share-post-s3) と isolated-label 効果 (-20.8%) から予測される wallclock 寄与は ~-2.5% で、この gate の解像度限界とほぼ同水準だった — milestone の期待 delta (-4〜6%) はこの意味で楽観的すぎた。config.rs \u002F ssim.rs の `SsimWalkKind::default()` は `PerChannel` のまま変更していない。","\u002Ffindings\u002Fp3-ssim-float4\u002F",{"id":36,"title":306,"date":9,"status":10,"polarity":12,"category":11,"axes":307,"tags":308,"task_code":321,"related_runs":322,"delta_psnr":341,"delta_wallclock":342,"rank":40,"verdict":343,"impact_summary":344,"detail_path":345},"M2 Tier1 (A1-A4 bit-exact) 12.5k gate v1+v2 — 棄却維持 (v1: Δ-5.0%だが2σ未達+PSNR guard抵触 \u002F v2 n=5 radix ballot上: PSNR分離は反証、wallclockは効果量≤1%で判定不能)",[14,207],[309,310,311,312,313,314,215,23,287,315,316,317,318,319,320],"m2","tier1","ssim-clear","raster-grad-clear","backward-uniform","lazy-c3-scratch","atomic-nondeterminism","psnr-guard","v2-regate","n5","radix-ballot-baseline","contamination-retry","2026-09 第 5 回ゼミ milestones — M2 Tier1 (A1-A4)",[323,324,325,326,327,328,329,330,331,332,333,334,335,336,337,338,339,340],"t1-12500-off-r1","t1-12500-on-r1","t1-12500-off-r2","t1-12500-on-r2","t1-12500-off-r3","t1-12500-on-r3","t1v2-12500-off-r1 (CONTAMINATED, discarded)","t1v2-12500-on-r1 (CONTAMINATED, discarded)","t1v2-12500-off-r2","t1v2-12500-on-r2","t1v2-12500-off-r3","t1v2-12500-on-r3","t1v2-12500-off-r4","t1v2-12500-on-r4","t1v2-12500-off-r5","t1v2-12500-on-r5","t1v2-12500-off-r6 (retry replacing r1)","t1v2-12500-on-r6 (retry replacing r1)","v1 (n=3): on **36.140 dB** (36.165\u002F36.097\u002F36.157) vs off **36.205 dB** (36.201\u002F36.195\u002F36.219) = **-0.065 dB**、n=3 全 pair で on \u003C off の完全分離、task 指定 guard (on mean ≥ off mean - 0.05 dB) に **抵触**。config header の絶対 guard (36.202 ± 0.1 dB) では両 arm とも帯内で pass — 2 guard の定義差は本文 §1 参照。final splats は on 407,775 \u002F off 408,721 (-0.23%)。\u003Cbr>\u003Cstrong>v2 (n=5、r1→r6 置換後)\u003C\u002Fstrong>: on **36.1982 dB** (36.218\u002F36.159\u002F36.196\u002F36.221\u002F36.197) vs off **36.1704 dB** (36.112\u002F36.220\u002F36.102\u002F36.237\u002F36.181) = **+0.0278 dB**、guard に **pass**。5 pair の符号は on>off (r1,r3,r5) \u002F on<off (r2,r4) の**混在**で系統性なし — off 側の散らばり (36.102-36.237) が on 側 (36.159-36.221) より大きく、v1 の系統分離とは対照的。v2 の結果は「PSNR 散らばりは atomic 非決定性の床であり flag 由来ではない」という読みを支持し、v1 の「静かな壊れ」仮説を反証する","v1 (n=3) mean (train elapsed, internal timer): **155.40 → 147.64s = -4.99%**、σ off 2.56% \u002F on 0.55% (比 4.66×)、有意閾値 max(2σ_off,1%) = 5.11%、実測 Δ は**閾値の 97.7%、0.12 pt 差で未達**。\u003Cbr>\u003Cstrong>v2 (n=5、新 baseline 127.4s 上、r1→r6 置換後)\u003C\u002Fstrong>: off **127.386s** (σ 0.527%) → on **125.972s** (σ 0.956%) = **-1.11%**、有意閾値 max(2σ_off,1%) = 1.054%、実測 Δ は**閾値の 105%、0.06 pt 差で形式上通過**。ただし感度分析 3 通り (汚染 r1 込み生データ Δ-0.30%\u002F不通過、r1→r6 置換後 n=5 Δ-1.11%\u002F通過、両試行を n=6 として残す Δ-0.15%\u002F不通過) のうち\u003Cstrong>通過するのは 1 通りのみ\u003C\u002Fstrong>で判定が 1 点の去就に依存する。σ 非対称は v1 が off 側 4.66× だったのに対し v2 は on 側 (n=5 で 1.81×、r1 の両試行を含む n=6 で見ると **5.40×**) と\u003Cstrong>逆転しており、両 gate とも分散構造が clean ではない\u003C\u002Fstrong>。v1 (-7.76s) と v2 (-1.41s) の絶対削減量が 5.5× 食い違う点は、A1-A4 が host 側 memset\u002Falloc 除去 (per-iter 削減量はほぼ一定のはず) である以上、\u003Cstrong>v1 の -4.99% は off arm の汚染 (σ2.56%) で膨らんでいた可能性が高く、真の効果量は ~1% 前後 = 本 harness の n=5 分解能未満\u003C\u002Fstrong>という解釈と整合する","rejected-v2-wallclock-inconclusive-psnr-guard-resolved","M2 Tier1 の 4 flag (A1 SSIM memset 除去 \u002F A2 work_grad blit 化 \u002F A3 backward uniform set_bytes 化 \u002F A4 lazy C3 scratch) を全 ON\u002F全 OFF の 2 arm にまとめ gate した。\u003Cstrong>v1 (n=3, 旧 baseline)\u003C\u002Fstrong>: train elapsed (internal timer) off 155.40s (σ 2.56%) → on 147.64s (σ 0.55%) = -4.99%、3 pair 全てで on が速い一貫した方向を示したが有意閾値 max(2σ\u003Csub>off\u003C\u002Fsub>, 1%) = 5.11% を 0.12 pt 差で下回り不通過。同時に PSNR は on 側で完全分離 (mean Δ -0.065 dB) し task 指定 guard に抵触した。\u003Cstrong>v2 (n=5, 2026-08-30 M4 radix ballot 採用後の新 baseline 127.4s 上で再 gate)\u003C\u002Fstrong>: PSNR は mean **+0.028 dB**、5 pair 中 on>off 3 \u002F on<off 2 の符号混在で \u003Cstrong>v1 の系統分離は再現せず、「A1\u002FA2 chained path の静かな壊れ」仮説は反証\u003C\u002Fstrong>された。wallclock は r1 pair の load 汚染 (on-r1 走行中に load1 が 9.09 まで spike) を検知し 1 回だけ再実行 (r6 で置換、元 log は `*-CONTAMINATED-*` として保存) した後の値で Δ **-1.11%**、有意閾値 1.05% を 0.06 pt 差で形式上通過する。しかし①汚染 r1 を生のまま使うと Δ-0.30% (不通過)、②両方の r1 試行を n=6 として残すと Δ-0.15% (不通過) と\u003Cstrong>1 点の去就で判定が反転する脆い pass\u003C\u002Fstrong>であり、さらに③置換先の r6 自身が事前登録した再実行条件 (自 arm 他値から3σ超) を独立 load 証拠の裏付けなしに 10.3σ で踏む (条件だけでは停止しない除外連鎖になる設計上の欠陥が判明)。advisor レビューの指摘により、0.06pt の脆い pass を根拠に default flip して M7 最終スタック・卒論数値の土台にするのは不適切と判断し、\u003Cstrong>棄却を維持\u003C\u002Fstrong>した (根拠は v1 の「PSNR guard 抵触」から v2 の「wallclock 効果量 ≤1% で本 harness (n=5) の分解能未満、判定不能」に変わった)。両 gate とも `cargo test --workspace` (A1 sentinel probe \u002F A2+A3 4 組合せ parity \u002F A4 self-heal 含む) は全 pass — 実装レベルの correctness bug は一貫して否定的。\u003Cstrong>結論: 棄却維持、4 flag の default は変更しない、config.rs は一切触らない\u003C\u002Fstrong>。","\u002Ffindings\u002Fp3-tier1-bit-exact\u002F",{"id":37,"title":347,"date":348,"status":10,"polarity":232,"category":11,"axes":349,"tags":350,"task_code":361,"related_runs":362,"delta_psnr":366,"delta_wallclock":367,"rank":226,"verdict":368,"impact_summary":369,"detail_path":370},"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,207],[351,352,353,354,355,356,357,358,359,360,12],"counter-session","gpu-busy","ioreport","power","energy","dvfs","p-state","msplat","m4-max","thesis-ready","2026-08 1× 工程表 v2 — AC 復帰後 計測 queue #1",[363,364,365],"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]