eee
This commit is contained in:
parent
0be5ce3ce3
commit
178cac581c
28 changed files with 1695 additions and 2746 deletions
28
docs/CLEANUP.md
Normal file
28
docs/CLEANUP.md
Normal file
|
|
@ -0,0 +1,28 @@
|
|||
# BLA・監査整理（2026-09-05）
|
||||
|
||||
BLAの計算経路、テーブル構築Worker、キャッシュ、GPU probe、shadow比較、canary適用、遅延コンパイル、タイマー、状態表示、切替APIを除去した。
|
||||
|
||||
比較専用のDirect／Deep active-list実験と内部点判定実験、未使用の全画面Deep候補、重複した統計シェーダーも削除した。描画完了後に比較計算を開始する処理や、URLから自動監査を起動する処理は残していない。
|
||||
|
||||
既存の変更に含まれていたfrontierの本番有効化は維持した。通常のDirect、FAST perturbation、Accurate DS、Deep perturbation、未脱出画素の継続計算、数値UNKNOWNの補修、世代キャンセル、GPU処理量制限、完成画像の履歴保持は維持している。Strictは数値判定の設定として利用できる。
|
||||
|
||||
詳細な世代別計測と検証APIは `?test` を指定した場合だけ有効になる。描画時間に応じて処理を分割するための計測と、GPUエラーの報告は通常時も維持する。
|
||||
|
||||
旧版別のハッシュ、保存済みベンチマーク、複数の昇格ゲート、重複したPython／JavaScript静的監査は廃止した。検証は `tests/regression.mjs` と `tests/browser_smoke.mjs` にまとめ、現行シェーダーのハッシュだけを保持する。過去の計画・結果はGit履歴から参照できる。
|
||||
|
||||
## 回帰テスト
|
||||
|
||||
- アプリとシェーダー生成のJavaScript構文。
|
||||
- 維持した23本のGPUシェーダーが整理前と完全一致。
|
||||
- Direct／FAST拡張／Accurate DS／Deepの選択と、引数削除後のフレーム振り分け。
|
||||
- 数値エラーと反復上限画素の分類、既存のGPU strip処理量制限。
|
||||
- 3種類のWorkerによる参照軌道生成・数値補修。
|
||||
- 通常起動で検証APIが公開されず、テスト起動で利用できること。
|
||||
|
||||
## 実GPU確認
|
||||
|
||||
独立した一時プロファイルのEdgeをheadlessモード、320×240で実行。初期表示、深部FAST、Accurate DS、Deepで数値UNKNOWNゼロ、GPUエラーなし、描画完了を確認した。初期表示ではパン往復のmeta／smoothハッシュ一致、通常／2倍サンプリングの出力タイルも確認した。同じSeahorse座標のFASTとDeepでも最終meta／smoothハッシュが一致した。
|
||||
|
||||
深部FAST（Seahorse、span 3.4e-13、初期512反復）は継続計算で32768反復まで進み、最終描画に約36.7秒かかった。比較前後の同一条件ベンチマークではないため、速度改善率は主張しない。BLAとは別の継続計算・数値補修の負荷は残っている。
|
||||
|
||||
2026-09-06追記：上の「数値UNKNOWNゼロ」は当時のカウンター値であり、全画素の終端誤差検査や厳密な分類の証明ではない。その後のコード精査で、継続経路の目標終端検査と処理量上限に不足を確認した。[改善案](PERFORMANCE_PLAN.md)と[実装設計](PERFORMANCE_IMPLEMENTATION.md)に修正方針・テストの不足範囲を記載した。過去の測定値自体は変更していない。
|
||||
69
docs/IMPLEMENTATION_RESULTS.md
Normal file
69
docs/IMPLEMENTATION_RESULTS.md
Normal file
|
|
@ -0,0 +1,69 @@
|
|||
# 軽量化の実装と確認結果
|
||||
|
||||
更新日：2026-09-06。対象：[index.html](../index.html)。[改善案](PERFORMANCE_PLAN.md) と [実装設計](PERFORMANCE_IMPLEMENTATION.md) に基づく変更。
|
||||
|
||||
この文書は軽量化実装時点の記録。以後の色相・時間表示の修正と正確モードの削除は[ビューワー修正](VIEWER_FIXES.md)を参照。
|
||||
|
||||
## 実装した処理
|
||||
|
||||
| 計画 | 変更 | 確認方法 |
|
||||
| --- | --- | --- |
|
||||
| A：判定と上限 | 目標の最後の更新後に脱出・誤差・参照範囲を確認する。正常な未脱出は実到達反復数を記録して継続キューへ残す。Direct DSも未脱出をreason 6へ統一した | 実GPUの目標境界・誤差超過・参照末尾テスト |
|
||||
| A：分割 | DSの適応バッチを毎回400万pixel-iterationsへ制限。幅1行でも上限を超える場合は横に分割する。PNGの重いタイルも分割する | 幅320～3840、350～150000反復の上限・全画素被覆テスト |
|
||||
| B：同期 | 継続を1～4 passずつ適応投入し、最後の件数コピーをmapする。直前の全queue待ちは省く | 0・1・63・64・65件、奇数／偶数pass、次目標への再投入 |
|
||||
| B：CPU補修 | 比較済みの高精度結果を次の比較へ使う。最大8軌道を5軌道にする。1～2 Workerへ画素数・反復数・精度に応じて小分けに投入し、完成した結果をまとめてGPUへ渡す | 実Workerの軌道呼び出し数と採用条件を確認 |
|
||||
| C：状態保持 | 数値補修で正常画素を再初期化しない。metaだけ回復した画素を別に保持し、それらだけ次目標で再計算する。Deepの初期計算も同じ継続stateを作る | キューの保持・コンパクトslot・描画回帰テスト |
|
||||
| C：参照 | 同一の原点・実精度の軌道をWorkerで末尾延長する。基準軌道と高精度検証軌道は独立したBigInt終端を持つ。GPU側も容量内では末尾だけ転送する | 延長結果と独立再生成のbyte一致、精度変更時のID分離 |
|
||||
| D：失敗転送 | 既存のGPU histogram／prefix／scatterをタイル補修へ使う。CPU補修へ渡す際も失敗indexのみ読み戻す | タイル内のindex集合をGPU出力と厳密比較 |
|
||||
| D：結果反映 | CPU結果をGPU scatterで反映する。書き込み前に描画世代を確認し、GPU側でも現在のmetaが数値失敗であることを確認する | 古い世代の拒否、確定画素・反復待ち画素の保持 |
|
||||
| E：内点 | 主カージオイドと周期2円に矩形全体が入ることをBigIntの整数区間で確認し、該当タイルを継続対象から除く | 256 bitの境界内外・境界をまたぐ矩形、実軸のGPU描画 |
|
||||
| E：優先順位 | 大きく重い継続ラウンドでは既存境界を先に進め、残りも同じ目標まで必ず進める | 実コントローラーのテストで両グループの目標到達・index全件保持を確認 |
|
||||
| E：反復予算 | 「反復上限」で画素精度から独立した有限予算を指定できる。自動設定では従来の停止方針を維持する。指定値はURLと表示履歴へ保存する | 初期反復512／4096から指定4096への到達、未脱出全画素のmeta、PNGの予算一致 |
|
||||
| E：表示とメモリ | 現在の画素格子の暫定結果を公開する。完成履歴へは入れない。疎な候補はコンパクトslot、密な候補は32 byteのstateを使う | 暫定PNG拒否、キャンセル、slotと画素indexの一致 |
|
||||
|
||||
## 数値・品質の扱い
|
||||
|
||||
数値故障、有限反復での未脱出、証明できた内点を区別する。誤差guardを緩めたり、未確定画素を周囲の色で埋めて成功件数へ算入したりしない。
|
||||
|
||||
既定の「自動」では、従来の最低反復予算と安定ラウンド判定を維持した。「反復上限」を指定すると、その有限予算まで必要な全画素を処理して終了する。優先順位は表示順を変えるもので、低優先度の画素を省くものではない。`pixelBits × 256` や安定2回を内点証明とは扱わず、結果には有限予算の方針を記録する。一般周期成分の包含証明や新しい近似加速器は、元の計画どおり研究候補として残している。
|
||||
|
||||
参照が実際に脱出した場合や採用精度が変わった場合は、同じstateを無条件には使えない。その場合の再初期化と、少数の補修による不要な全体再初期化は別に扱う。
|
||||
|
||||
初期描画用の参照と補修用の参照を分離し、同一のテスト入力では繰り返し描画・FAST／Deepのmetaとsmoothのbyte一致を確認した。独立BigIntサンプルでは脱出分類・脱出反復数を厳密比較し、f32の再構成とlog2を含むsmoothは8 ULP以内を確認する。このサンプル検査を全画素の数学的証明とはしない。
|
||||
|
||||
主参照のCPUキャッシュは8 MiB、局所参照は2 Worker×2 MiBを基本上限とし、上限より大きな単独参照は1本だけ保持する。GPU参照は最大3種類。activeの密なstateは32 byte/画素、疎なslotは40 byte/候補とindex対応表を持ち、後者が実際に小さくなる場合だけ使う。密なframeでは既存の画素数上限とdeviceのbinding上限を使い、タイルごとに生存stateを捨てる方式は採らない。
|
||||
|
||||
通常の同一解像度PNGは補修済みのframeをコピーする。別解像度・複数sample出力は独立したタイル計算であり、残った未確定sample数を従来どおり出力メタデータへ記録する。任意の出力解像度・座標の数値失敗0は保証していない。
|
||||
|
||||
## 検証
|
||||
|
||||
検証用Edgeは専用プロファイル、1インスタンス・1タブで直列実行する。常時監査は追加せず、検証APIと詳細計測は `?test` のみ。
|
||||
|
||||
```sh
|
||||
node tests/regression.mjs
|
||||
node tests/browser_smoke.mjs 9333 all
|
||||
```
|
||||
|
||||
CPUテスト：構文、シェーダー固定値、ルーティング、分割の被覆と上限、Workerの参照延長・精度再利用、内点区間、古い世代の拒否。
|
||||
|
||||
GPUテスト：終端判定、queueの全index、コンパクトstate、scatterの対象保護、6つの描画座標、独立BigIntサンプル、パン往復、補修中のキャンセル、PNGの符号化と復号。
|
||||
|
||||
最終版で全回帰テストが通過した。640×480の実画面で「反復上限」を4096へ変更し、URLへの保存と再読み込み後の復元も確認した。検証終了後、専用Edgeとそのプロファイルを終了・削除し、残存Edgeプロセスがないことを確認した。
|
||||
|
||||
## 測定結果
|
||||
|
||||
Intel Gen-9の実GPU、Edge、320×240、標準負荷、自動の反復上限。Seahorseは `re=-0.743643887037151, im=0.13182590420533, span=3.4e-13`、初期512反復。各ケースを1回ウォームアップした後、同じタブで3回測定した。
|
||||
|
||||
| ケース | 3回の完成時間 (ms) | 中央値 (ms) | 暫定表示までの中央値 (ms) | 最終反復 | 数値失敗 | 未脱出 |
|
||||
| --- | --- | --- | --- | --- | --- | --- |
|
||||
| 初期表示 | 211.2 / 214.4 / 205.0 | 211.2 | 9.8 | 4096 | 0 | 1174 |
|
||||
| Seahorse FAST | 12002.7 / 11637.2 / 11577.7 | 11637.2 | 55.9 | 32768 | 0 | 1 |
|
||||
| Seahorse Deep | 11828.2 / 11164.0 / 11153.8 | 11164.0 | 84.7 | 32768 | 0 | 1 |
|
||||
|
||||
Seahorseでは最終的に残った1画素も32768反復へ到達しており、数値故障とは別の未脱出である。3回とも数値bufferのhashが一致した。FAST／Deep間でも一致した。
|
||||
|
||||
FASTの継続バッチは64～65回、主な数値readbackは約4.00 MB、CPU補修は3618軌道。Deepは64～65回、約4.31 MB、3618軌道。仕事量の集計は入口件数×chunkの上界であり、早期脱出を差し引いた実反復数ではない。初期化157185画素には参照原点を変更した際の再初期化を含む。最終active workspaceは疎な1候補用48 byteだが、これは描画中の最大使用量やframe全体のメモリではない。
|
||||
|
||||
[前回記録](CLEANUP.md)のFAST約36.7秒・Deep約41.3秒に対し、今回の同じ解像度・座標の中央値は約11.6秒・11.2秒だった。ただし今回は終端判定と補修も修正しており、旧版との数学的処理条件を完全に固定した速度比較ではない。全座標で同じ倍率の高速化を約束する値ではなく、p95も算出していない。
|
||||
|
||||
回帰用の実軸と既知の黒領域は64×48で確認した。独立サンプルはSeahorse FAST／Deep・実軸・黒領域の各12画素。PNGは320×240の全画素を復号比較し、不一致0だった。処理中の操作で古いCPU補修が新しいframeを上書きせず、暫定frameが完成PNGへ入らないことも確認した。
|
||||
|
|
@ -1,579 +0,0 @@
|
|||
# マンデルブロ集合ビューアー最適化計画
|
||||
|
||||
対象baseline: `index.html` v24.2.55 (`24.2.55-no-black-hole-async-recovery`)
|
||||
|
||||
実装版: `index.html` v24.3.0 (`24.3.0-optimized-unknown-pipeline`)
|
||||
|
||||
作成日: 2026-08-25
|
||||
|
||||
## 本番昇格状況（2026-08-25）
|
||||
|
||||
`PIXEL_FRONTIER_PRODUCTION=true` とし、pixel-convergent frontier を既定経路へ昇格した。ブラウザー操作機能を取得できず実機WebGPUゲートは実行できなかったが、保存済みコミット `83b874c` を復旧点として、ユーザー判断により未検証リスクを受容して本番化した。active-list engine は Accurate の初期全面描画には使わず、初期描画は bounded strip の既存 Deep kernel、active-list は operation-limit 画素の継続計算だけに限定する。
|
||||
|
||||
| 条件 | 状態 | 根拠 / 残作業 |
|
||||
| --- | --- | --- |
|
||||
| JavaScript 構文、worker 構文、kernel hash | 合格 | `tests/optimization_regression.mjs` |
|
||||
| 1 dispatch の上限 4,000,000 pixel-iterations | 静的合格 | 初期 Deep、sparse DS、frontier の各契約を回帰テストで固定 |
|
||||
| Accurate 初期描画が active-list production path を使わない | 静的合格 | `computeFrame()` は bounded `computePerturbFrameTiled()` を使用 |
|
||||
| UNKNOWN を色で隠さず対象画素を計算する | 静的合格 | operation-limit 全 index を continuation queue に投入。色置換や倍率しきい値は不使用 |
|
||||
| 早すぎる安定判定の防止 | 候補実装済み | 画素幅から連続的に求めた最低反復数へ到達する前は、2 round 安定でも終了しない |
|
||||
| exact escape iteration / class mismatch = 0 | 本番後確認 | Browser接続が利用可能になった時点で corpus と高精度 oracle を実行する |
|
||||
| final numeric UNKNOWN = 0 | 本番後確認 | reset、seahorse、real-axis、報告座標で確認する |
|
||||
| WGSL error / uncaptured error / device loss = 0 | 本番後確認 | Windows D3D12 実機で確認する |
|
||||
| p50 / p95 性能基準 | 本番後確認 | 同一セッション A/B を採取し、特に 10^14 付近の初回表示を確認する |
|
||||
| 通常操作で黒領域が出現・消失しない | 本番後確認 | 同一近傍の pan / zoom / round-trip hash を確認する |
|
||||
|
||||
`pixelFrontierIterationFloor()` は zoom 倍率で描画方式を切り替えない。`span / canvasWidth` が表す1画素のスケールから最低反復予算を連続的に算出する。これは「少し拡大しただけで未計算領域を黒として確定する」問題を抑えるための下限であり、数学的な集合所属証明ではない。今回はBrowser接続を利用できないため実機ゲートを昇格前条件から本番後確認へ移した。
|
||||
|
||||
本番判定は `tests/production_gate.mjs` に固定した。候補段階では `node tests/production_gate.mjs <artifact> preflight`、本番フラグを有効化した後は同じコーパスを再実行して `node tests/production_gate.mjs <artifact> production` を通す。artifact は同一adapterで採取したbaseline/candidateの対応、異なる2 adapter以上、全12 correctness case、全6 performance caseを各10計測run、3 interaction caseを含まなければ合格しない。10^5と10^8はFAST/Accurateの両方、10^14は800×600でFAST p50 1000 ms・p95 1500 ms未満、Accurate p50 1500 ms・p95 2000 ms未満を追加の絶対条件とする。
|
||||
|
||||
## 追加修正: 10^14付近の速度とWindows GPU停止
|
||||
|
||||
実機ログで、Accurate Deepの長い単一dispatchがWindowsのGPU監視時間を超え、`DXGI_ERROR_DEVICE_HUNG`を発生させていたことを確認した。`powerPreference`の警告は原因ではない。
|
||||
|
||||
- Accurate DeepのActive-list本番化は、正常版との分類経路差になるため撤回する。正確モードはv24.2.55と同じDeep perturbation式へ戻し、1 stripを最大4,000,000 pixel-iterationsへ縮小することでTDRを回避する。
|
||||
- Deep/Direct-DS補修はより重い演算なので、1 dispatch相当を最大4,000,000 pixel-iterationsへ制限する。疎Deep補修がこの上限を超える場合も補修を省略せず、2次元タイルのbounded scanですべての数値UNKNOWNを処理する。
|
||||
- state/二重queueは最大64 MiBのband workspaceとして再利用し、adapterのbuffer/binding上限を超えない。band間で出力座標を保持するためqueue indexはband-local、meta/smooth indexはframe-globalとする。
|
||||
- device loss直後のadapter再作成を1.2秒遅延し、D3D12復旧前の連続した`Device failed at creation`を避ける。
|
||||
- FASTの最終フレームから無条件Deep補修を外す。数値UNKNOWNが実際に残った場合だけ局所reference補修と画素精度BigInt補修を同期実行し、数値UNKNOWNが0になるまで新しいframeを公開しない。通常FASTはDeepを待たず、未計算frameも表示しない。
|
||||
- 履歴のない深部FASTでは、短いreferenceのpreviewがfinalへ再利用できず二重計算になっていたため、最終品質を1回だけ生成する。既存のstable historyがある操作では従来どおり再投影を即時previewとして使う。
|
||||
- 倍率による描画方式の固定閾値は設けない。必要精度を `span / canvasWidth`（複素平面上の1画素幅）から算出し、参照軌道は画素精度+40 guard bit、任意精度補修は同じ精度と+32 bitの二重計算が一致した場合だけ採用する。画素より細かい座標情報は計算しない。数値UNKNOWNは件数上限で打ち切らず、bounded chunkですべて補修してから完成扱いにする。色で未計算を隠す処理や10^100切替は使用しない。
|
||||
|
||||
### 根本解決: pixel-convergent frontier
|
||||
|
||||
黒領域の膨張には、座標精度不足とは別に「反復上限まで脱出しなかった点を、そのまま集合内部と同じ黒で表示する」問題がある。倍率ごとの固定反復数や固定切替では解決しないため、最終形は次の画素収束方式とする。
|
||||
|
||||
1. 初回passは現在のadaptive反復数まで全画素を計算する。
|
||||
2. `operation-limit` 画素のうち、8近傍に `escaped` がある画素だけをGPU上でfrontier queueへcompactする。黒領域の奥を再計算しない。
|
||||
3. frontier画素は保存したperturbation stateからbounded chunkで継続し、新たに脱出した画素だけを更新する。その近傍を次のfrontierへ追加する。
|
||||
4. analytic cardioid/bulbまたは検証済み周期性で内部と証明できた画素はfrontierから除外する。単に反復上限へ達しただけの画素は「証明済み内部」へ昇格しない。
|
||||
5. 変化した境界のHausdorff距離が1画素未満になり、数値UNKNOWNが0になった時だけframeを完成・history commitする。これにより画素以下の境界情報は追跡しない。
|
||||
6. 1 dispatchは既存のpixel-iteration予算内に分割し、操作が入ればgeneration tokenで即時中止する。同一viewの反復延長ではreference/state/queueを再利用し、iteration 0からやり直さない。
|
||||
|
||||
現在の実装では、この前提となる画素幅基準precision、全残存数値UNKNOWNのbounded補修、未完成frameのpublish禁止までを本番経路へ入れた。frontier continuationは既存のshadow active-listを、実機zero-tolerance corpusとWindows TDR試験に通した後で本番へ昇格する。これが反復上限由来の過大な黒を、全画面高反復の速度低下なしに除く本命経路である。
|
||||
- adaptive反復数の64単位上方丸め、BLA既定OFF、同一viewだけのreference再利用は維持する。したがって操作順による黒領域の揺れを抑える決定性は維持し、反復数・誤差guard・分類式は削減しない。
|
||||
|
||||
## 実装状況（2026-08-25）
|
||||
|
||||
この計画のうち、数値品質を維持したまま静的・モデル検証できる項目をv24.3.0へ実装した。
|
||||
|
||||
- generationごとにprimary/final/numeric-quiescent/history-commit、submit/sync差分、UNKNOWN数を最大64件記録し、テストhookへprimary/final/numeric-complete待機とmeta/smooth SHA-256取得を追加する。
|
||||
- Accurate seedを最大24反復で終了し、未採用画素をreason 1〜5のUNKNOWNとしてDSへ渡す。
|
||||
- DSと高精度・高速参照workerで更新後平方を次反復へ引き継ぐ。
|
||||
- Direct、Accurate、FAST、Deep、BLAで共通のUNKNOWN post-statsを使い、理由0、1〜5、6を同じ規則で集計する。
|
||||
- Deep補正をbucket、prefix、scatter、indirect dispatchの疎queueへ接続し、queue不変条件が崩れた時だけbounded full scanへ戻す。
|
||||
- Accurate seed後はUNKNOWN indexだけをcompactし、時間予算に合わせたDirect-DS queue sliceで処理する。selected/enqueued/dispatch/processedまたは範囲不変条件が崩れた場合だけ従来の全画面guard走査へ戻す。
|
||||
- failure mapをGPU上で空間タイル集計し、全画面metadata readbackを局所補修ループから除去する。局所referenceは3 workerで並列準備する。
|
||||
- failure密度によるFAST→Deep直接昇格、同一viewの検証済みreference再利用、final reference prefetch、BLA table cacheを追加する。近傍viewへのreference流用は黒領域の操作順依存を生じ得るため撤回した。
|
||||
- previewの確定済みescape・解析的内点を同一referenceのfinalで再利用し、UNKNOWNだけを再計算する。
|
||||
- GPU先行投入を24 ms（直近入力）/40 ms（idle）の予測時間予算で制限する。
|
||||
- 初期pipelineをDirect、color、present、UNKNOWN stats、実軸対称copyへ縮小し、Accurate、FAST拡張、Deep、補正、AAを遅延コンパイルする。
|
||||
- 最後に残ったreason 1〜5だけをview精度+128 bitと+192 bitで再計算し、両者のescape反復とf32 smoothが一致した結果だけを採用する。
|
||||
- 中心虚部が厳密に0の通常画面では、共役対称性により上半分だけを計算して下半分へmetadata/smoothを複製する。
|
||||
- BLAはoperation削減率だけでなく、直近baseline、table build、probeを含む推定net時間が5%以上改善する場合だけ有効化する。
|
||||
- BLAの不安全分岐は0反復目restartではなく最後の正確checkpointからFAST recurrenceを再開する。
|
||||
- exportはadapter limitに応じた256/512 px tileと2〜3個のstaging workspaceを使い、GPU/readbackを重ねる。PNGのrow順は維持し、UI yieldは24 ms経過時だけ行う。
|
||||
- UNKNOWN/queue statsはframe単位の3-buffer readback ringへ移し、安定buffer/textureのbind groupをcacheする。
|
||||
- stable historyは全画面copyを廃止し、3枚のcolor textureをfront/back/history/spareとして役割回転する。
|
||||
- Direct/Deepのactive-list continuation、indirect compaction、FAST/Deepの証明付き内点判定候補をshadow-onlyで追加した。Deep continuationも品質回帰の切り分けを優先して本番採用を撤回した。内点候補は外向き丸めのf32区間演算を使い、候補indexだけを画素精度+40/+72 bit oracleで確認する。
|
||||
- 操作ごとに黒領域が揺れる問題への安定化として、adaptive反復数を品質を下げない64反復単位の上方丸めにし、近傍view間の参照軌道流用を廃止した。FASTで数値UNKNOWNが発生した場合は、同一viewの局所referenceと画素精度BigInt補修を完了してから表示し、未完成frameをpresent/commitしない。
|
||||
|
||||
`tests/optimization_regression.mjs` は、2本のscript構文、36 string/kernel hash、旧新BigInt軌道2,000例、旧新DS軌道600例、Direct active chunk分割1,000例、任意精度worker構文を検査する。この環境ではブラウザ接続とWebGPU adapterを利用できなかったため、実GPU WGSL compile、画面hash、KPI実測は未実施である。
|
||||
|
||||
`tests/OPTIMIZATION_BENCHMARK.json` のBigInt worker modelでは、240点、700反復、192〜320 bit、7 runの中央値が201.5509 msから115.3558 msになり、42.77%短縮した。この値は参照軌道の平方再利用だけを測るもので、ブラウザや実GPUのend-to-end改善率ではない。
|
||||
|
||||
BLA replayコードは保持しているが、実測時間で数値backendが揺れることを防ぐためproduction既定値をOFFに戻し、明示的なテストopt-inだけを許可する。export ring、readback/bind cache、history role rotationはproduction経路へ接続済みである。Active-listと証明付き内点判定は`productionEligible:false`のshadow-onlyへ戻し、本番Deepは正常版の式を小さなstripで実行する。
|
||||
|
||||
### 要件別の実装証拠
|
||||
|
||||
| 計画項目 | 現在の実装 | 検証証拠 |
|
||||
| --- | --- | --- |
|
||||
| P0-1 seed打切り | `DIRECT_ACCURATE_SEED_WGSL` が24反復でreason 2へ移行 | kernel hash、source invariant |
|
||||
| P0-2 平方再利用 | Direct DS、Deep/Fast reference worker、独立verifyで更新後平方を保持 | BigInt 2,000例、DS 600例の旧新全state一致 |
|
||||
| P0-3 計測 | generation別primary/final/numeric-quiescent/history、submit/sync、UNKNOWN理由を記録 | `waitForPrimary/Final/NumericComplete`、`fieldHashes`、`gpuDiagnostics` |
|
||||
| P1-1 疎queue | Deep bucket/prefix/scatter/indirectとAccurate Direct-DS compact queue | selected/enqueued/dispatch/processed不変条件、異常時full scan |
|
||||
| P1-2 補修routing | failure密度によるFAST→Deep、GPU reason tile map、局所reference | source invariant、reason別post-stats |
|
||||
| P1-3 実体cache | reference prefix/checkpoint、BLA table、同一pending requestを再利用 | key/coalescing/cancel source invariant |
|
||||
| P1-4 preview再利用 | 同一view/referenceのknown pixelを保持しUNKNOWNだけfinal再計算 | `unknownOnly` とreference key guard |
|
||||
| P1-5 時間予算 | 24/40 ms予測budget、adaptive strip/burst、queued DS slice | scheduler source invariant |
|
||||
| P2-1 failure map | GPU tile集計、3 workerのlocal reference並列準備 | recovery経路に全画面meta readbackなし |
|
||||
| P2-2 BLA replay | 最後の正確anchorからbaseline recurrenceを再開。production既定OFF、明示opt-inのみ | 7 fallback分岐、zero restartなし、kernel hash |
|
||||
| P2-3 固定費 | lazy pipeline、3-buffer stats readback、bind cache、history role rotation | 1,000回のtexture role model、source invariant |
|
||||
| P2-4 export | 256/512 tile、2〜3 staging slot、ordered `allSettled`、24 ms yield | export構造回帰、SS1/SS2 smoke hook |
|
||||
| P2-5 任意精度 | reason 1〜5を画素精度+40/+72 bitで評価して一致時のみpatch。全残存画素をbounded chunkで処理 | worker構文、受理条件source invariant |
|
||||
| P3-1 active-list | Direct/Deep state、二重queue、indirect compaction、preview→final resume | Direct chunk 1,000例、GPU zero-tolerance shadow hook |
|
||||
| P3-2 証明付きskip | 厳密実軸対称copy、外向きf32区間によるcardioid/bulb候補 | 画素精度+40/+72 bit oracle shadow、`productionEligible:false` |
|
||||
|
||||
`tests/optimization_webgpu_corpus.mjs` は上表の実GPU証拠を収集するdriverである。7 correctness case、4 performance scenario、SS1/SS2 exportに加え、近接2 viewと同一view再訪からなるinteraction stability sequenceを定義する。WGSL error、uncaptured error、device loss、coverage UNKNOWN、最終numeric UNKNOWN、history commit、field hash、Direct/Deep active mismatch、内点oracle mismatchをzero-toleranceで検査し、同一view再訪時のmeta/smooth hash一致も必須とする。numeric recoveryが完了しないcaseも即失敗とする。
|
||||
|
||||
## 結論
|
||||
|
||||
品質を落とさずに改善できる可能性が高い順序は、次のとおりである。これはprofile前の期待順位であり、Milestone 0のbaseline実測で入れ替える。
|
||||
|
||||
1. Accurate の f32 seed を24反復で終了させる。現在は「24未満の脱出だけを採用」するにもかかわらず、未採用ピクセルを `maxIter` または脱出まで計算し、その後DSで0反復目から再計算している。
|
||||
2. Accurate DSとBigInt参照軌道の反復内で重複計算している更新後の平方を次反復へ引き継ぐ。
|
||||
3. すでに存在する Deep UNKNOWN のbucket/queue/indirect補正を本番経路へ接続し、全画面DS補正走査をやめる。
|
||||
4. previewで確定した脱出・解析的内点と、同一prefixの参照軌道をfinalへ引き継ぎ、同じピクセルを0反復目から二度計算しない。
|
||||
5. 参照軌道とBLA tableを実際の参照点でキャッシュする。同一viewの反復数増加では再利用または延長できるが、近接pan/zoomへの流用は同一view再訪hash gateを通過するまで行わない。
|
||||
6. 数値未確定の位置特定を全画面GPU→CPU readbackからGPU側tile集計へ移し、reason別にDS、軌道延長、局所referenceを選ぶ。
|
||||
7. GPUへ先行投入する仕事を「strip本数」ではなく予測GPU時間で制限し、キャンセル済みビューの無駄計算を抑える。
|
||||
8. 長期的には、一定反復ごとのactive-pixel compactionへ移行し、preview継続、分岐発散削減、細粒度キャンセルを同時に実現する。
|
||||
|
||||
最初の3項目は、最終的に実行する数値式を変えず、明白な重複または空振り計算だけを減らせる。特に1項目は小さな変更で高い効果が見込まれるため最初に検証するが、実効果は解析的内点、24反復未満の脱出、DS対象ピクセルの比率に依存する。
|
||||
|
||||
この文書は実装監査に基づく提案であり、ここに記載した性能効果はまだ実GPUで測定した結果ではない。既存の386.9 ms削減値もworker modelであり、canvasを含む実端末フレーム時間ではない。
|
||||
|
||||
## 目標と非目標
|
||||
|
||||
目標は次の3点である。
|
||||
|
||||
- 最終フレームに残る数値未確定ピクセルを最小化する。
|
||||
- 入力から新規画像、最終品質、数値補修完了までの時間と、PNG生成時間を短縮する。
|
||||
- v24.2.55の解像度、`maxIter`、サンプリング位置、色、数値安全弁を維持し、既知ピクセルをUNKNOWNへ退行させない。
|
||||
|
||||
速度のためにDPR、反復数、AA sample数、誤差判定の安全余裕を下げることは対象外とする。また、本ビューアーのexport metadataは現在も `membershipCertified:false` であるため、本計画の「品質不変」は数学的な集合所属証明ではなく、現行baselineとの同等性と高精度oracleに対する非退行を意味する。
|
||||
|
||||
## 用語と計測単位
|
||||
|
||||
コード上には「計算放棄」という正式な状態名がない。曖昧な集計を避けるため、本計画では次のように分ける。
|
||||
|
||||
| 区分 | metadata reason | 本計画での扱い |
|
||||
| --- | ---: | --- |
|
||||
| 未書込・coverage hole | 0 | バグ検知指標。最終値は必ず0 |
|
||||
| 数値未確定 | 1〜5 | 「計算放棄ピクセル」の主指標 |
|
||||
| 反復上限到達 | 6 | 数値故障ではない。失敗率へ加算しない |
|
||||
| キャンセル済みビューの計算 | metadata外 | GPUへ投入済みだがpublishされない無駄仕事として別集計 |
|
||||
| 重複計算 | metadata外 | preview→final、seed→DS、primary→recoveryで同じピクセルを再反復した仕事 |
|
||||
|
||||
reason 1〜5は `error-bound`、`escape-uncertain`、`reference-end`、`rebase-gap`、`range` であり、現行の `numericalFailureCount()` と同じ定義である（`index.html:2023-2025`）。reason 6は `maxIter` まで脱出しなかったピクセルで、COLOR passでは不透明な黒になる。数値未確定とは区別する。
|
||||
|
||||
ピクセル数だけでは、1反復で失敗したピクセルと12000反復後に捨てたピクセルを区別できない。主な性能指標には必ず「pixel-iterationsまたは実際のkernel steps」も併記する。
|
||||
|
||||
## 現行パイプライン
|
||||
|
||||
```text
|
||||
入力
|
||||
├─ 操作中: stable historyを再投影
|
||||
└─ 操作確定
|
||||
├─ backend選択
|
||||
│ ├─ FAST direct f32 → COLOR → PRESENT
|
||||
│ ├─ FAST perturbation / optional BLA
|
||||
│ │ └─ coverage repair + COLOR → stats readback
|
||||
│ │ └─ background recovery予約 → 一次PRESENT
|
||||
│ │ └─ 60 ms後にlocal refs
|
||||
│ │ └─ 残存時full Deep + DS + local refs → recolor
|
||||
│ ├─ Accurate direct: f32 seed → guarded DS → COLOR → PRESENT
|
||||
│ └─ Accurate Deep: perturbation → stats readback
|
||||
│ └─ 条件成立時full-screen guarded DS → local refs
|
||||
│ └─ COLOR → PRESENT
|
||||
└─ intended contract: 数値未確定が0の時だけstable historyへcommit
|
||||
```
|
||||
|
||||
品質面では、未完成frontをhistoryへ昇格させず、通常のpan/zoomでは透明な数値未確定部分を直前のstable frameで補うことが意図された契約である。ただし現行Accurate hybridには未確定を0件と仮定する例外があり、後述の共通post-statsで修正する。最適化後は全backendでこの契約を満たす。
|
||||
|
||||
## 実装監査で確認した主要ボトルネック
|
||||
|
||||
### 1. Accurate seedが「安価なseed」になっていない
|
||||
|
||||
`DIRECT_ACCURATE_SEED_WGSL` は脱出反復が24未満のピクセルだけを採用するが、loop自体は `maxIter` まで継続する（`index.html:191-200`）。その後、UNKNOWNピクセルはDSで反復0から再計算される（`index.html:1944-1964`）。
|
||||
|
||||
したがって、解析的に証明できない内点は f32で `maxIter` 回、さらにDSで `maxIter` 回計算される。遅く脱出する境界ピクセルも、f32の脱出まで計算した後にDSで再計算される。既存fuzz契約は「f32 escape iteration < 24」のみを採用するため、seedは24反復に達した時点でUNKNOWNとして終了しても最終DS結果は変わらない（`tests/ACCURATE_SEED_FUZZ.json`）。
|
||||
|
||||
### 2. 疎なDS補正用GPU queueが存在するが未使用
|
||||
|
||||
8 bucketのhistogram、prefix、scatter、indirect dispatch、およびqueued DS kernelはすでに実装されている（`index.html:416-800`）。pipelineとencoder helperも起動時に作成される（`index.html:1820-1827`, `1841-1842`, `1863-1867`）。
|
||||
|
||||
一方、本番の `correctUnknownFrame()` は全画面をrow stripでdispatchし、各strip後に同期する（`index.html:1994-2000`）。shader内で既知ピクセルはearly returnするが、全ピクセル分のinvocation、buffer read、分岐とsubmit/waitは残る。「sparse correction」という名前の判定も、実際には全画面走査を呼んでいる。
|
||||
|
||||
### 3. previewとfinalが同じ仕事を繰り返す
|
||||
|
||||
historyがないFAST viewではpreviewとfinalの2段階を使う（`index.html:1445-1453`）。しかしfinalではmeta/smoothをclearし、全ピクセルを0反復目から再計算する（`index.html:1897-1939`）。参照軌道cache keyにも `iter` が入るため、previewとfinalで軌道も再構築される（`index.html:1490`, `1513`）。
|
||||
|
||||
previewで既に脱出したピクセルと解析的に証明された内点は、`maxIter` を増やしても結果が変わらない。同じ参照軌道prefixと同じ数値式を使える場合、これらをfinalで再計算する必要はない。
|
||||
|
||||
### 4. 局所補修が全画面readbackと直列処理を繰り返す
|
||||
|
||||
`recoverNumericalUnknownTiles()` は各roundでmeta全体をGPUからCPUへ読み戻し、main threadで全画素を走査してtileを作る。最後にも再読込する（`index.html:1986`, `2031-2034`）。その後は、1 tileごとにreference build、GPU correction、stats readbackを順番に待つ。
|
||||
|
||||
また「広域failureならfull Deepが安い」とする `shouldPromoteFastToDeep()` が定義されているが、呼ばれていない（`index.html:2026-2028`）。実際のFAST background recoveryはfailure密度にかかわらずlocal recoveryから開始し、残ればfull Deepで画面全体を上書きする（`index.html:2050-2073`）。広域failureでは最初のlocal処理が無駄になる。
|
||||
|
||||
### 5. 参照軌道とBLA tableの再利用範囲が狭い
|
||||
|
||||
Deep/FAST referenceの再利用は同じ `iter` と完全に同じ `span` を要求する（`index.html:2089-2090`）。しかし参照軌道そのものは参照点 `c_ref` に依存し、表示spanには依存しない。参照点が新viewの有効範囲にあり、精度と長さが足りれば、既存の誤差guardを保ったままzoom後にも利用できる。
|
||||
|
||||
BLA tableも参照軌道から作るが、build keyはview座標・寸法込みであり、近接viewでも再構築される（`index.html:1598`, `1674-1679`, `2110-2114`）。さらに `BlaShadowService.cancelPending()` はPromiseを破棄するだけでworkerをterminateしない。同期的な旧viewのtable build中は、新viewの要求がworker queueで待たされる（`index.html:1594-1600`）。
|
||||
|
||||
### 6. キャンセルはpublishを止めるが、投入済みGPU仕事は止めない
|
||||
|
||||
token checkにより古い結果のpublishは防いでいるが、WebGPU queueへsubmit済みのcommand bufferはキャンセルできない。現行はDeep 2本、FAST 4本、BLA 8本をまとめて投入してから待つ（`index.html:1897-1925`）。目標strip時間はDeep 18 ms、FAST 22 msであるため、BLAでは理論上かなり長い旧view仕事がqueueに残り得る。
|
||||
|
||||
`cancelRender()` はJS状態とworker要求を止めるが、GPU queueをpreemptしない（`index.html:2094`）。新viewのcommandは旧viewの仕事の後ろへ並ぶため、無駄計算と入力後latencyの両方に影響する。
|
||||
|
||||
### 7. 初期化、bind group、history copy、exportに固定費がある
|
||||
|
||||
- 初期化では初期FAST表示に不要なAccurate、Deep、queue、AA pipelineまで一括compileする（`index.html:1811-1834`）。
|
||||
- stripごとに同じresource構成のbind groupを作り直す（`index.html:1857-1868`）。
|
||||
- stable history更新はfront texture全体をcopyする（`index.html:1982`）。
|
||||
- exportは単一readback workspaceでtileを完全直列処理し、各row band後に必ず `requestAnimationFrame` を待つ（`index.html:2276-2289`）。
|
||||
|
||||
これらは数値品質に触れずに削減できる固定費である。
|
||||
|
||||
### 8. backend間でUNKNOWN集計が一致していない
|
||||
|
||||
Directはreason 6をmetadataへ書くがstatsを集計しない。より重要なのは、Accurate hybridのDS kernelが `REASON_RANGE` を出し得る一方、orchestrationは完了後に `state.unresolved=0` と無条件設定する点である（`index.html:248`, `2131-2133`）。この場合、数値未確定を見逃してincomplete frameをhistoryへcommitする可能性がある。
|
||||
|
||||
全backendの最終color前に共通post-statsを通し、reason 0、reason 1〜5、reason 6をmetadata実体から集計する。これは最適化効果を測る前提であると同時に、品質契約の穴を塞ぐ変更でもある。
|
||||
|
||||
## 期待優先順位付き最適化案
|
||||
|
||||
| 期待順位 | 案 | 数値未確定 | 生成時間への期待 | キャンセル無駄 | 品質リスク |
|
||||
| ---: | --- | --- | --- | --- | --- |
|
||||
| P0 | Accurate seedを24反復で終了 | 同じ | 大（view依存） | 削減 | 低 |
|
||||
| P0 | DS/BigIntの更新後平方を再利用 | 同じ | 中〜大 | 削減 | 低 |
|
||||
| P0 | 計測契約とbaselineを固定 | 判定可能にする | 判定可能にする | 判定可能にする | 低 |
|
||||
| P1 | UNKNOWN統計をpost-pass化 | 同じ | interior-heavyで削減 | 削減 | 低 |
|
||||
| P1 | 既存の疎queueでDS補正 | 同じか減少 | 大 | 削減 | 低〜中 |
|
||||
| P1 | failure密度・reason別routing | 減少 | 大 | 削減 | 低 |
|
||||
| P1 | reference/BLA cache・延長・同一view再利用 | 減少 | 大 | 削減 | 低〜中 |
|
||||
| P1 | preview確定結果をfinalで再利用 | 同じ | 大 | 削減 | 低〜中 |
|
||||
| P1 | in-flight GPU時間を動的制限 | 同じ | 操作時に改善 | 大きく削減 | 低 |
|
||||
| P2 | GPU failure mapと並列local refs | 減少 | 大 | 削減 | 中 |
|
||||
| P2 | BLA checkpoint replayとnet-time gate | 同じ | BLA viewで改善 | 削減 | 中 |
|
||||
| P2 | pipeline/export/resource固定費削減 | 同じ | cold load/export改善 | 小幅削減 | 低 |
|
||||
| P2 | 残存UNKNOWNだけ任意精度fallback | 最終値を0へ | 少数時のみ有利 | 同じ | 中 |
|
||||
| P3 | active-pixel continuation/compaction | 同じか減少 | hard viewで最大 | 大きく削減 | 高 |
|
||||
| P3 | 証明付き内点判定・対称性 | 同じ | 対象viewで改善 | 削減 | 中〜高 |
|
||||
|
||||
### P0-1. Accurate seedを `lateThreshold` で打ち切る
|
||||
|
||||
`DIRECT_ACCURATE_SEED_WGSL` の各pixelは次のどちらかだけを行う。
|
||||
|
||||
- cardioid/period-2 bulbを解析的に証明できれば確定する。
|
||||
- 最大24回だけf32反復し、24未満で安全に脱出した場合だけ確定する。それ以外は直ちにUNKNOWNとする。
|
||||
|
||||
DS passは現在と同じくUNKNOWNを0反復目から計算する。このため最終meta/smoothは現行と同じで、seed側の24回を超える仕事だけが消える。打切りmetadataは後段queueが選べるreason 1〜5（例えば `REASON_ESCAPE_UNCERTAIN`）にし、reason 6やzero sentinelとは区別する。まず単独feature flagで実装し、既存60,000 fuzz、full-frame meta/smooth hash、strip-order testを通す。
|
||||
|
||||
### P0-2. DSとBigInt軌道で更新後の平方を再利用する
|
||||
|
||||
`DIRECT_DS_CORRECT_WGSL` は、各反復の更新前に `zr²`、`zi²`、`zr*zi` を計算し、更新直後の脱出判定で新しい `zr²` と `zi²` を再計算する。次のloop先頭では同じ新しい平方をもう一度計算する（`index.html:240-246`）。更新後の2平方をstateとして次反復へ渡せば、DS乗算は概ね5回/反復から3回/反復になり、個々の `ds_mul` の入力と演算順は変わらない。
|
||||
|
||||
Deep/Fast reference workerの `orbit()`、`orbitEscape()`、`verify()` にも、座標更新用と直後のmag用で同じBigInt平方を二度作る箇所がある（`index.html:1479-1483`, `1503-1506`）。丸め済みの更新後平方を次反復へ持ち越す。各変更は旧/新の軌道配列、脱出反復、meta/smoothをbit比較する。
|
||||
|
||||
### P0-3. 先に計測を直す
|
||||
|
||||
現行の `setView()` は `dirty || rendering` が終わるまでしか待たず、`refinePending` とbackground numeric recoveryを待たない（`index.html:2303`）。`lastRender` だけを比較すると、preview完了と最終補修完了を取り違える。
|
||||
|
||||
テストhookへ次を追加する。
|
||||
|
||||
- `waitForPrimary()`、`waitForFinal()`、`waitForNumericComplete()`。
|
||||
- generationごとのphase時刻: reference、BLA build/probe、primary、coverage+color、stats readback、DS、local refs、full Deep、recolor、history commit。
|
||||
- reason 0、reason 1〜5の内訳、reason 6をprimary/DS/local/finalの各時点で保存。
|
||||
- 全backendを共通post-statsへ通し、Accurate hybridで `unresolved=0` を仮定しない。
|
||||
- kernel steps: direct、perturbation、DS、BLA、replay、およびキャンセルされたgenerationのsteps。
|
||||
- submit、sync wait、readback回数・bytes・時間、reference/BLA cache hit。
|
||||
- adapter/browser/実ピクセル数/effective DPR/実効 `maxIter`。
|
||||
|
||||
`timestamp-query` が利用可能なadapterではGPU timestampを使い、利用できない場合はwall clockと明記する。累積runtime counterではなく、各generationの差分を記録する。
|
||||
|
||||
### P1-1. Deep/Accurate補正を既存の疎queueへ接続する
|
||||
|
||||
推奨フローは次のとおりである。
|
||||
|
||||
1. primary Deepはpixelごとのglobal atomicを避けるpost-stats variantを使う。
|
||||
2. histogram passでreason 1〜5だけを8個の開始反復bucketへ集計する。
|
||||
3. prefixとscatterでUNKNOWN index queueを作る。
|
||||
4. `dispatchWorkgroupsIndirect` でqueued `correct_pixel()` だけを実行する。
|
||||
5. queue overflow、invalid index、stale entryが1件でもあれば現行full-scanへfallbackする。
|
||||
|
||||
histogram/prefix/scatter基盤はAccurate f32 seed後のDSにも使う。ただし既存queued kernelはDeep referenceを読むperturbation版 `correct_pixel()` であり、絶対座標を使う `DIRECT_DS_CORRECT_WGSL` へそのまま接続してはならない。Direct-DSの数値式をそのまま持つ別のqueued kernelを作る。seedで確定したピクセルはqueueに入らず、DS invocation自体を発生させない。bucket順により、同じ程度の反復で終わるlaneが隣接し、SIMD divergenceも減る。
|
||||
|
||||
queue構築は全画面を軽く走査するため、UNKNOWNが非常に多い場合はfull-scanの方が速い可能性がある。adapter別の実測から密度crossoverを決め、queue/full-scanを選ぶ。各backendで元kernelと同じper-pixel arithmeticとoutput semanticsを保ち、出力差を許容しない。
|
||||
|
||||
同時に、primary hot loopからpixel単位のglobal atomic統計を外す。現在はFAST/Deep/BLAのUNKNOWN 1 pixelにつき最大2回、同じcounterへatomic addする（`index.html:268-270`, `339-347`, `1335-1339`）。特にreason 6が多いinterior-heavy viewでは、長い反復の最後に競合が集中する。Deepにはatomicを除いた `DEEP_PERTURB_POSTSTATS_WGSL` とworkgroup集約histogramが既にあるため、まずこれを接続し、FAST/BLAにも同型のpost-pass集計を用意する。meta/smoothは変更しない。
|
||||
|
||||
### P1-2. failure密度とreasonで補修経路を選ぶ
|
||||
|
||||
一次statsを得た直後に次のroutingを行う。
|
||||
|
||||
- failureが `max(60000, 8% of pixels)` 以上なら、既存 `shouldPromoteFastToDeep()` を使ってlocal-firstを省き、full Deepへ直行する。
|
||||
- `error-bound` / `escape-uncertain` はまずqueued DSを使う。
|
||||
- `reference-end` は「cache prefixが要求iterより短い」場合と「reference自身が脱出して `refLen=escape` になった」場合を分ける。前者だけ同一軌道を延長し、後者は原則として非脱出またはより長く安定する新referenceを選ぶ。脱出後の軌道を無条件に延長しない。
|
||||
- `range` / `rebase-gap` は失敗領域に近いlocal referenceを優先する。
|
||||
- reason 0は数値補修へ混ぜず、coverage契約だけで処理する。
|
||||
|
||||
各経路で `recovered / attempted` とmsを記録し、近接viewでは前回の成功経路をpriorとして使う。ただし結果が残る場合は現在と同じDeep/DS/local fallbackを最後まで保持する。
|
||||
|
||||
### P1-3. 参照軌道とBLA tableを実体ベースで再利用する
|
||||
|
||||
reference cache keyを「要求view」から次の実体へ変更する。
|
||||
|
||||
- 実際に選択された `referenceRe/referenceIm`。
|
||||
- precision bits。
|
||||
- orbitの最長計算済み長さ。
|
||||
- kernel format/version。
|
||||
|
||||
短い `iter` 要求にはprefixを返し、長い要求にはworker内に保持したBigInt状態から延長する。preview→finalで同じ軌道を作り直さない。
|
||||
|
||||
参照点選択でも二重計算を避ける。現在は `orbitEscape()` で候補を評価した後、選ばれた非中心候補を `orbit()` でもう一度0から計算する。候補評価時の最良軌道を保持すれば、選択軌道の再走査を省ける。
|
||||
|
||||
一方、Deepの独立 `verify()` は通常modeでも外さない。新規orbitは従来どおり検証し、検証済みimmutable orbitをcacheから再利用する時だけ検証結果も再利用する。第一pass中のhashだけへ置き換える案は独立guardの弱体化になるため、別実装の同等以上の検証器を用意できるまで採用しない。
|
||||
|
||||
再利用判定では `newSpan === oldSpan` を必須にせず、参照点が新view内または安全margin内にあること、精度が十分なこと、orbit長が足りることを確認する。Deepの誤差bound、reference-end、checkpoint検証は残す。guardが不利と判断した場合だけ新しい参照点を作る。
|
||||
|
||||
BLA tableは `reference buffer/hash + refLen + safety + table format version` でcacheする。viewごとに必要なのはtable再構築ではなく、pixel分布に対する採用probeだけである。旧view buildのキャンセルは、ReferenceServiceと同様のworker terminate/recreate、またはchunk化した協調キャンセルで実際のCPU仕事も止める。
|
||||
|
||||
### P1-4. previewの確定結果をfinalへ引き継ぐ
|
||||
|
||||
最初の段階ではorbit stateを保存せず、次だけを再利用する。
|
||||
|
||||
- `FIELD_ESCAPED`: finalの `maxIter` を増やしても最初の脱出反復とsmooth値は変わらない。
|
||||
- `FIELD_INTERIOR_PROVEN`: classとsmoothは変わらないが、packed iteration部はpreviewの `maxIter` になっている。final前の軽量patch passで `pack_meta(finalIter, FIELD_INTERIOR_PROVEN)` へ更新してから再利用する。
|
||||
- previewのreason 6: finalで再計算が必要。
|
||||
- 数値未確定reason 1〜5: finalまたは補修で再計算が必要。
|
||||
|
||||
Directはfinal kernelへ `unknownOnly` を加えるだけで実現できる。perturbationでは、previewとfinalが同じ最終長referenceのprefix、同じ参照点、同じpixel latticeを使う場合だけ既知pixelを再利用する。条件が1つでも違えば現行full recomputeへ戻す。
|
||||
|
||||
次段階では、未脱出pixelの `z/w/d/scaleExp/reference index/error` をcheckpointとして保存し、preview末尾からfinalを再開する。ただし浮動小数点演算順を変える可能性があるため、これはP3のactive-list方式と同じ厳しい品質gateを通す。
|
||||
|
||||
### P1-5. GPU先行投入量を時間予算で制限する
|
||||
|
||||
現在の固定 `burstLimit` を、直近stripのGPU時間EMAから求める。
|
||||
|
||||
```text
|
||||
burstLimit = clamp(1, maxBurst, floor(maxInFlightMs / predictedStripMs))
|
||||
```
|
||||
|
||||
初期案として、直近に入力があった時は `maxInFlightMs=24`、十分idleなら40程度から測定を始める。値は品質ではなくsubmit/waitとキャンセルlatencyのtrade-offなので、adapter別に自動調整する。
|
||||
|
||||
Directの全画面1 dispatchと高反復exportも同じ時間上限でstrip化する。perturbationだけを細分化しても、Directが長時間queueを占有すれば新viewは待たされる。
|
||||
|
||||
追加で、top-to-bottom固定順ではなく、focus座標と画面中心に近いmacro-tileから処理する。キャンセルされた場合でも、ユーザーが見ている領域に使える仕事の割合が増える。部分表示を行う場合はgeneration stamp付きwork textureを使い、旧generationを絶対にpublishしない。
|
||||
|
||||
### P2-1. failure mapをGPUで作り、local refsを並列化する
|
||||
|
||||
全meta readbackの代わりに、GPUで固定macro-tileごとの次の小さなsummaryを作る。
|
||||
|
||||
- reason別件数。
|
||||
- `sumX/sumY`、min/max座標。
|
||||
- UNKNOWN index rangeまたはcompact queue offset。
|
||||
|
||||
CPUへ戻すのは数KBのsummaryだけにする。必要なlocal referenceは2〜4 workerのpoolで並列構築し、完成したreferenceごとに1 tileずつ待たず、複数queueをまとめてGPUへsubmitする。補正対象も長方形全体ではなく、そのreferenceへ割り当てたUNKNOWN indexだけにする。
|
||||
|
||||
近接pan/zoomでは前frameのfailure mapを再投影してcoarse probeの優先候補に使える。ただし最終判定は新frameのguard結果で行う。
|
||||
|
||||
### P2-2. BLA fallbackを0反復目restartからcheckpoint replayへ変える
|
||||
|
||||
production candidateのBLAは近似chainが不安全になるとbaselineを0反復目から再実行する（`index.html:1320-1323`）。一方、検証用shadow kernelには最後のexact anchorからreplayする実装がある（`index.html:1130-1232`）。このcheckpoint/replayをproductionへ移すと、fallback pixelでBLA以前の仕事を捨てずに済む。
|
||||
|
||||
BLA採用条件も、現在の `fallback <= 12.5%` と `operation reduction >= 50%` だけでなく、table build、upload、probe、replayを含む予測net msで決める。cache miss時の固定費が節約時間を上回るviewではbaseline FASTを選ぶ。
|
||||
|
||||
品質gateではclassとescape iterationだけでなくsmooth値と最終RGBAも比較する。approximationが不確かなpixelは必ず既存FAST recurrenceへreplay/fallbackし、BLA由来の新しいUNKNOWNを許さない。
|
||||
|
||||
### P2-3. 初期化・resource・historyの固定費を減らす
|
||||
|
||||
- cold startではPRESENT、Direct、COLORだけを先にcompileし、FAST extended、Accurate、Deep、queue、AA、診断pipelineは必要時またはidle時にwarm upする。
|
||||
- pipeline/frame/contextごとにbind groupとtexture viewをcacheする。
|
||||
- 小さなstats readback bufferを毎回create/destroyせずringで再利用する。
|
||||
- front/back/historyを3 textureのrole rotationにし、history commit時の全texture copyをなくす。
|
||||
|
||||
これらはshader結果を変えないため、bit-identical testを要求する。
|
||||
|
||||
### P2-4. exportをGPU・readback・PNG圧縮のpipelineにする
|
||||
|
||||
現在の単一workspaceを2〜3個のringへ変え、tile N+1のGPU計算、tile Nのmap/copy、前bandのCompressionStream書込を重ねる。PNGのrow順は維持する。
|
||||
|
||||
各row band後の無条件 `requestAnimationFrame` は、経過時間に応じたyieldへ変える。操作応答性を守る必要がある時だけyieldし、headless/非操作exportでは不要な1 frame待ちを入れない。tile sizeも512固定ではなく、adapter memory limitと目標in-flight時間から選ぶ。
|
||||
|
||||
2x AAは4 sampleを維持する。サンプル削減は、pixel footprint全体が内点であることを証明できる場合以外は行わない。
|
||||
|
||||
### P2-5. 最後に残ったUNKNOWNだけを任意精度で解決する
|
||||
|
||||
local referenceにはmode別の `maxRefs` 上限があり、予算を使い切るとreason 1〜5が残り得る（`index.html:2029-2034`）。final Accurate/strict exportでは、残存indexだけをCPU workerの固定小数点または疎なGPU limb演算で `maxIter` まで直接評価し、escapedまたは各backendの現行maxIter metadataへpatchする。Deep/Fastはreason 6、Accurate Direct DSは `FIELD_INTERIOR_LIKELY` という違いを保持する。これにより、画面やtile全体を再計算せずに最終numeric UNKNOWNを0へ近づけられる。
|
||||
|
||||
これは集合所属の無限反復証明ではない。`maxIter` まで未脱出なら、起点backendの現行分類・metadata policyを変えない。対象が多い場合は先に別reference/full Deepへ戻し、疎な最終手段としてだけ使う。
|
||||
|
||||
### P3-1. active-pixel continuationへ移行する
|
||||
|
||||
最終的な高反復view向けには、1 pixelを1 dispatchで `maxIter` まで回す方式を次へ置き換える。
|
||||
|
||||
1. 64〜256反復のchunkだけ実行する。
|
||||
2. 脱出・証明済み内点を除き、active pixel indexと継続stateをcompactする。
|
||||
3. 次chunkはactive queueだけを実行する。
|
||||
4. preview時点のqueue/stateをfinalへそのまま継続する。
|
||||
|
||||
これにより、早期脱出pixelを後続chunkから除外し、workgroup divergenceを減らし、chunk境界でキャンセルできる。Directでは `z`、Deepでは `w/d/scaleExp/reference index/error` が必要になる。二重queueの論理使用量はactive数に比例するが、通常はworst caseとして全 `P` pixel分のbuffer確保が必要であり、メモリ量もKPIと採用条件に含める。
|
||||
|
||||
最大の注意点は再開前後で演算順、rescale位置、誤差伝播を変えないことである。baselineとbit-identicalにならない場合は高精度oracleに対する誤差非増加を証明し、既存pathをfallbackとして残す。
|
||||
|
||||
### P3-2. 証明できる場合だけ計算を省く
|
||||
|
||||
- Deep/FASTでも `c_ref + dc` をdouble-singleまたは区間で再構成し、main cardioid/period-2 bulbの片側安全判定を追加する。
|
||||
- center imaginary=0かつsample latticeが厳密に鏡映対称なviewでは、実軸対称性を使って片側のmeta/smoothをcopyする。
|
||||
- 周期検出やtile一括fillは、有限精度のepsilon一致だけで内点扱いしない。区間または収縮証明が成立した時だけ確定する。
|
||||
|
||||
素朴なperiodicity checking、境界だけを調べるrectangle fill、色差だけによるadaptive AAは小さい構造を消す可能性があるため採用しない。
|
||||
|
||||
## 品質契約
|
||||
|
||||
最適化を2種類に分ける。
|
||||
|
||||
### 構造だけを変える最適化
|
||||
|
||||
seedの早期終了、平方再利用、queue化、post-stats、bind group再利用、export pipelineなど、最終数値式と採用経路を変えない案は次を必須とする。
|
||||
|
||||
- `fieldMeta`、`fieldSmooth`、最終RGBAがbaselineとbit-identical。
|
||||
- known→UNKNOWNが0。
|
||||
- final reason 0が0。
|
||||
- 数値未確定を含むframeのhistory commitが0。
|
||||
- stale generationのpublishが0。
|
||||
|
||||
### 数値アルゴリズムを変える最適化
|
||||
|
||||
BLA、continuation、証明付き内点判定に加え、選択referenceや補修経路が変わるcache/routingは次を必須とする。同じreference実体をそのまま再利用するだけなら構造変更としてbit比較する。
|
||||
|
||||
- baselineで既知のpixelをUNKNOWNへ戻さない。
|
||||
- baselineとcandidateの双方が既知なら、classはbaselineおよび高精度oracleと一致する。
|
||||
- baseline UNKNOWNをcandidateがescapedまたはreason 6へ解決する差分は改善として許可し、raw classification mismatchへ加算しない。
|
||||
- exact同値を主張する経路ではfirst escape iteration mismatchが0。
|
||||
- BLA derived UNKNOWNとinternal failureが0。
|
||||
- smooth/RGBAのoracle誤差がbaseline以下。単なる画像平均ではなく最大誤差と差分pixel数を保存する。
|
||||
- final numeric UNKNOWNは各caseでbaseline以下。baselineが0ならcandidateも0。
|
||||
- 異常時は同一viewでbaselineへ自動fallbackする。
|
||||
|
||||
既存Accurate hybrid記録にはreset viewで2/1200のescape iteration mismatchがあるため、少なくともこれを悪化させず、目標は0とする。SwiftShaderの時間値はcorrectness用の相対参考であり、実GPU性能gateには使わない。
|
||||
|
||||
## KPI
|
||||
|
||||
画素数を `P = width * height`、reason別件数を `U_r` とする。
|
||||
|
||||
- `coverage_hole_ppm = 1e6 * U_0 / P`。hard targetはfinalで0。
|
||||
- `numeric_unknown_ppm = 1e6 * sum(U_1..U_5) / P`。
|
||||
- `operation_limit_ppm = 1e6 * U_6 / P`。情報指標であり失敗率ではない。
|
||||
- `recovery_rate = (U_primary - U_final) / max(1, U_primary)`。
|
||||
- `recovery_cost_ms_per_1k = (T_recovery_quiescent - T_primary) / recovered_kpixels`。
|
||||
- `cancelled_work_ratio = cancelled_kernel_steps / all_kernel_steps`。
|
||||
- `duplicate_work_ratio = repeated_kernel_steps / all_kernel_steps`。
|
||||
|
||||
latencyは最低でも次の5点を分ける。
|
||||
|
||||
- `T_feedback`: inputから再投影presentまで。
|
||||
- `T_primary`: 同一viewの最初の新規frameまで。
|
||||
- `T_final`: finalIter frameのpresentまで。
|
||||
- `T_recovery_quiescent`: background補修が成功、予算終了、またはfallback完了で停止するまで。数値未確定が残る場合も記録する。
|
||||
- `T_history_commit`: 数値未確定0のstable frameがhistoryへcommitされるまで。未確定が残って到達しないrunは、打切り時刻でcensored dataとして扱う。
|
||||
|
||||
p50、p95、maxを保存し、reference build、BLA build/probe、primary、DS、local refs、readback、color、export compressionの内訳も残す。
|
||||
|
||||
## ベンチマーク行列
|
||||
|
||||
### correctness corpus
|
||||
|
||||
- reset: center `(-0.5, 0)`, span `3.4`。
|
||||
- seahorse-low: `(-0.743643887037151, 0.13182590420533)`, span `0.1`。
|
||||
- cusp-low: `(0.25, 0)`, span `0.85`。
|
||||
- classic Seahorse deep: span `3.4e-13`, 2900 iterations。
|
||||
- BLAが有利なviewと、BLA probeがOFFになるSeahorse/Misiurewicz hard view。
|
||||
- `directPixelRatio` の4直前/直後、32直前/直後。
|
||||
- reason 1〜5をそれぞれ誘発する固定seed。
|
||||
- 実軸対称、interior-heavy、boundary-heavy、reference-end-heavyの各view。
|
||||
|
||||
### performance corpus
|
||||
|
||||
- 320×220 / 750 iter: 既存Accurate比較の継続用。
|
||||
- 654×690 / 2900 iter: 既存BLA prep scenarioとの接続用。
|
||||
- 1920×1080、および対象端末で可能なら4K。
|
||||
- 900 / 1500 / 3000 / 6000 / 12000 iter。
|
||||
- cold load、warm same view、same-span pan、small zoom、distant jump。
|
||||
- FAST/Accurate、BLA forced on/off、連続pan/zoomのcancel storm。
|
||||
- export SS1/SS2、balanced/strict。
|
||||
|
||||
`processMode` はpixel budgetとiteration係数を同時に変えるため、異なるmodeのraw msを直接比較しない。必ず実ピクセル数、DPR、iterを記録する。
|
||||
|
||||
実機は低電力integrated、現行integrated、discrete GPUを最低構成とし、SwiftShaderはcorrectnessだけに使う。各caseはwarmup後にbaseline/candidateを同一sessionで交互に10〜20回実行し、medianとp95を比較する。
|
||||
|
||||
## 合格基準
|
||||
|
||||
### hard quality/safety gate
|
||||
|
||||
- 全caseでfinal reason 0 = 0。
|
||||
- known→UNKNOWN、stale publish、不完全history commit = 0。
|
||||
- baseline既知pixelのknown→UNKNOWN = 0。双方既知pixelのclass mismatch = 0。
|
||||
- baseline UNKNOWNの解決は許可し、その結果が高精度oracleと矛盾しない。
|
||||
- exact経路のescape iteration mismatch = 0。
|
||||
- final numeric UNKNOWNは全caseでbaseline以下。strict/validate golden corpusの目標は0。
|
||||
- reference checkpoint mismatch、strip/full mismatch、WGSL error、uncaptured error、device loss = 0。
|
||||
- operation-limitは別集計し、数値未確定削減として数えない。
|
||||
|
||||
### performance gateの初期値
|
||||
|
||||
以下は実測後に調整する導入基準であり、達成値ではない。
|
||||
|
||||
- 対象hard viewの `T_primary` と `T_recovery_quiescent` のp50を20%以上、p95を15%以上短縮。`T_history_commit` 到達runも別集計で非退行とする。
|
||||
- 非対象viewでp50 +5%、p95 +10%を超える退行を出さない。
|
||||
- failure corpusのprimary numeric UNKNOWN中央値を50%以上、finalを90%以上削減し、各caseでは非増加。
|
||||
- BLA enabled viewはbuild+probe込みでbaselineより10%以上速い。BLA rejected/offの追加費用は5%または8 ms以下。
|
||||
- 1 burstのp95はFAST 25 ms以下、Deep 22 ms以下、max 50 ms以下を初期目標とする。
|
||||
- readback bytes、readback回数、correction sync waitsはbaseline以下。
|
||||
|
||||
## 実装ロードマップ
|
||||
|
||||
### Milestone 0: 観測とbaseline固定
|
||||
|
||||
1. generation単位のmetricsと3種類のUNKNOWN集計を追加する。
|
||||
2. `waitForFinal()` と `waitForNumericComplete()` をテストhookへ追加する。
|
||||
3. meta/smooth/RGBAのgolden artifactと操作traceを作る。
|
||||
4. 実GPUでcold/warm/cancel/export baselineを採る。
|
||||
|
||||
### Milestone 1: 小変更で重複仕事を除く
|
||||
|
||||
1. Accurate seedを24反復で終了する。
|
||||
2. Accurate DSとreference workerで更新後平方を再利用する。
|
||||
3. 全backendのUNKNOWNを共通post-statsで集計し、Deep/FAST/BLA primaryのpixel単位atomicを外す。
|
||||
4. `shouldPromoteFastToDeep()` を実経路へ接続する。
|
||||
5. reference/BLA cache keyを実体ベースへ変更し、旧BLA buildを実際にキャンセルする。
|
||||
6. stats readback bufferとbind groupを再利用する。
|
||||
|
||||
各変更を単独flagでA/Bし、bit-identicalと性能gateを確認する。
|
||||
|
||||
### Milestone 2: 疎queueとpreview再利用
|
||||
|
||||
1. Deep補正を既存bucket/indirect queueへ接続する。
|
||||
2. 同じcompaction基盤と新しいDirect-DS queued kernelをAccurate seed後へ接続する。
|
||||
3. previewのknown pixelと最終長reference prefixをfinalへ引き継ぐ。
|
||||
4. in-flight時間budgetを導入する。
|
||||
|
||||
queue異常時は現行full-scan、reuse条件不成立時は現行full recomputeへ戻す。
|
||||
|
||||
### Milestone 3: recoveryとBLA/exportのpipeline化
|
||||
|
||||
1. GPU failure summaryとUNKNOWN index queueを実装する。
|
||||
2. local reference worker poolとbatched correctionを実装する。
|
||||
3. production BLAへcheckpoint replayとnet-time gateを移す。
|
||||
4. export staging ringとtime-based yieldを実装する。
|
||||
5. strict/export向けの疎な任意精度最終fallbackを実装する。
|
||||
|
||||
### Milestone 4: active-list engine
|
||||
|
||||
chunk continuation、compaction、証明付き内点判定、厳密対称性をshadow-onlyで導入する。golden full-frame比較、複数adapter canary、kill switchを通過したbackendだけを標準へ昇格する。
|
||||
|
||||
## 展開とrollback
|
||||
|
||||
- 新経路はすべてfeature flag既定OFFから開始する。
|
||||
- 数値kernel/BLA変更は最初にshadow-onlyでbaselineと同時計算する。
|
||||
- adapter/browser bucket単位で10%→25%→50%→100%へ段階展開する。
|
||||
- hard quality gateはzero toleranceとし、1件でも違反したbucketは即baselineへ戻す。
|
||||
- default化後も旧path、kill switch、kernel hashを最低1 release残す。
|
||||
- mismatchまたは新しいUNKNOWN reasonを起こしたviewは座標、span、iter、adapter情報と共にgolden corpusへ追加する。
|
||||
|
||||
## 採用しない近道
|
||||
|
||||
次は生成時間を短く見せられるが、品質不変の条件に反するため採用しない。
|
||||
|
||||
- adaptive `maxIter`、DPR、export解像度、AA sample数を下げる。
|
||||
- error boundやBLA safetyを緩め、失敗を内点または脱出扱いする。
|
||||
- reason 6を「計算放棄」と数え、黒のまま補修済みと見なす。
|
||||
- 再投影画像の色が近いという理由だけで、新viewの数値metaを再利用する。
|
||||
- 未証明のperiodicity、rectangle border fill、色差ベースAAで内部sampleを省く。
|
||||
- BLA/近似経路からbaseline fallbackとgeneration tokenを外す。
|
||||
|
||||
この順序なら、まず明白な二重計算と未使用の疎処理を取り除き、その後に参照選択とGPU schedulingを改善できる。画質を守る責務は各最適化のfallbackと自動比較に持たせ、速度と数値未確定率のどちらか一方だけを改善したように見せない。
|
||||
194
docs/PERFORMANCE_IMPLEMENTATION.md
Normal file
194
docs/PERFORMANCE_IMPLEMENTATION.md
Normal file
|
|
@ -0,0 +1,194 @@
|
|||
# 軽量化の実装設計と精査結果
|
||||
|
||||
更新日：2026-09-06。[改善案](PERFORMANCE_PLAN.md)の続き。以下は承認前の設計と精査記録。採用した実装、検証結果、残る数値上の制約は [実装結果](IMPLEMENTATION_RESULTS.md) を参照。
|
||||
|
||||
## 1. 精査で確定した修正
|
||||
|
||||
| 論点 | 現在のコードで確認した内容 | 案への反映 |
|
||||
| --- | --- | --- |
|
||||
| 参照の強制更新 | `ReferenceService.request(..., fresh=false)` があり、trueで該当cacheを削除する。実コードを使った小さなCPU確認でも再投入された | 「引数がなく無効」を撤回。同じ入力から同じ短い参照を再選択し得る問題として扱う |
|
||||
| 局所参照の位置 | `FAILURE_TILE_MAP_WGSL` が失敗indexの最小値を求め、`readNumericalFailureTiles()` が代表点へ変換する | 既に失敗画素を使う。重心選択と誤記せず、代替候補・回収実績を改善対象とする |
|
||||
| reason 4・7 | 4は定義・集計、7は名前がある。現行シェーダーにそれらを失敗として書く経路は確認できない | 現在の発生原因や改善効果に算入しない |
|
||||
| 継続の終端 | `DEEP_ACTIVE_CONTINUE_WGSL` の終端分岐はtarget>=150001が必要だが、通常の目標は最大150000 | 目標到達の判定とstateの寿命を分ける |
|
||||
| 最後の1反復 | 継続loopは更新後のnがstopに達すると、次回の脱出判定より先に終了する | 結果採用時に最終stateの脱出・誤差を確認する |
|
||||
| DS queueの上限 | `computeAccurateDirectHybrid()` が初期batchを時間に応じて拡大し、元の仕事量上限へ戻していない | 適応後のclampと横分割を前提にしてからまとめ投入する |
|
||||
| 現行の計測値 | `session.pixelIterations` は入口active数×chunkの加算 | 実反復数と呼ばず、仕事量上界として比較する |
|
||||
| 現行の「正確」 | Direct DS／Deep DS補修はDSで計算するが、全丸め誤差を区間伝播する証明ではない | 数値採用・有限回未脱出・内点証明を分ける |
|
||||
|
||||
照合対象は現行 [index.html](../index.html)。精査時のSHA-256は `045a5de85b816808ea8f54c5a390196b7436b3c7802267aadcd7bc1baa7c6792`。この値は照合した版を識別する記録で、今後の編集を禁止するゲートではない。
|
||||
|
||||
## 2. 計算状態の契約
|
||||
|
||||
既存のmetaを表示用の最小情報として残し、継続可能なstate・参照の識別・仕事の所属を分ける。reasonやclassを増やすこと自体を目的にしない。
|
||||
|
||||
| 論理状態 | 必須情報 | 次の処理 |
|
||||
| --- | --- | --- |
|
||||
| 未着手 | 画素index、描画世代 | 初期計算 |
|
||||
| 継続可能 | 実到達n、参照内のm、差分、指数、誤差、参照ID | 同じ数値方式で次の有界chunk |
|
||||
| 数値補修待ち | 失敗理由、画素index、最後に有効だったstateの有無 | 理由に合う参照／精度で補修 |
|
||||
| 目標まで未脱出 | 採用済みのn、誤差確認の状態、継続stateの有無 | 次の反復目標を待つ。集合内の証明とはしない |
|
||||
| 脱出を採用 | 脱出反復数、smooth、採用条件 | 数値計算から除外し、配色変更だけに応答 |
|
||||
| 内点を確認 | 確認した方式と対象画素 | 継続から除外 |
|
||||
|
||||
各画素が同時に複数の仕事へ所属しないことを基本にする。画素単位の所有者は `継続／補修／保留／数値処理終了` のどれか1つ。集計はこの排他的な所属を数え、active件数とmetaのUNKNOWN総数をそのまま足し合わせない。
|
||||
|
||||
`n` は処理した反復数、`m` は参照軌道内の位置であり、片方から他方を推定しない。画素ごとに到達nが違う可能性があるため、sessionの単一progressを全画素の到達証明として使わない。
|
||||
|
||||
### 目標到達時の処理
|
||||
|
||||
1. 最後の更新後のstateから `z_n` を再構成する。参照範囲外なら補修へ回し、末尾indexを丸めて代用しない。
|
||||
2. 脱出条件を満たすか、境界を誤差込みで判定できるかを確認する。確定できない境界は補修へ回す。
|
||||
3. 未脱出なら現在の目標に対する誤差条件を確認し、metaへ実到達nを記録する。
|
||||
4. 採用できた未脱出画素はstateを保存し、次の目標に使える保留対象として保持する。脱出・内点は除外する。
|
||||
5. 誤差条件を満たさないstateを「正常な継続state」として再利用しない。前chunk等の有効stateがある場合だけそこから補修できるものとする。
|
||||
|
||||
P0では既存の誤差閾値を無条件に緩めず、未実行だった採用処理を到達可能にする。DSやCPU補修にも採用条件の限界を残す。数学的保証を強める場合は、別の数値方式変更として評価する。
|
||||
|
||||
## 3. GPUスケジューラーの具体案
|
||||
|
||||
同じ描画世代・参照ID・数値方式・誤差方針の画素を1グループとして処理する。最初は既存の2本のactive queueを使い、複数の常駐エンジンを増やさない。
|
||||
|
||||
### まとめ投入の上限
|
||||
|
||||
```text
|
||||
upper = このまとまりの入口のactive件数
|
||||
workCap = 継続カーネル1回の上限（初期案：4,000,000）
|
||||
chunk = min(256, floor(workCap / upper), この目標までの残り反復)
|
||||
batchPasses = 1～4（初期は1、短い完了時間を確認して増加）
|
||||
|
||||
upper == 0 または残り反復 == 0 → 反復を投入せず目標の完了処理へ
|
||||
floor(workCap / upper) == 0 → 対象を分割する。chunkを1へ丸めて上限を超えない
|
||||
batchPasses × upper × chunk → まとまり全体の仕事量上限でも制限
|
||||
```
|
||||
|
||||
この上界が有効なのは、まとまりの途中で対象を追加せず、各画素を高々1回だけ次queueへ戻す場合である。補修済み画素の再参加・別グループの統合はまとまりの境界で行う。nの違う画素の残り反復はカーネル内でも切り詰める。
|
||||
|
||||
```text
|
||||
世代を確認
|
||||
同じ参照のbufferを確保
|
||||
2～4回以下の「件数→indirect引数→有界継続」をencode
|
||||
最後の件数・失敗要約だけをstagingへcopy
|
||||
submit
|
||||
staging.mapAsyncの成立を待つ
|
||||
世代を再確認して要約を採用、unmap
|
||||
表示更新・入力処理へ制御を返す
|
||||
残件があれば次のまとまりへ
|
||||
```
|
||||
|
||||
CPU時間による初期調整目標は、1まとまりの完了を数ms～十数ms程度に収めること。ただしmapを含む経過時間は純GPU時間ではない。過去の実測が長いときは回数か仕事量を減らし、数値失敗を捨てて短くしない。初回に4回を固定投入したり、毎回時間計測用の追加同期を挟んだりしない。
|
||||
|
||||
専用参照・uniform・queue・stagingは、そのまとまりが使い終わるまで破棄／上書きしない。`mapAsync` が成立したstagingは `unmap` までGPUへ再投入しない。単一stagingを直列再利用する実装から始め、重ね合わせが必要になった場合だけ少数ringへ広げる。
|
||||
|
||||
GPUへ既に投入した処理を世代tokenだけで取り消すことはできない。入力時は追加投入を止め、旧世代の結果を新しい画素バッファへ書き込まない。参照の破棄は、それを使う処理の完了後に行う。
|
||||
|
||||
### 他の重い経路にも適用する上限
|
||||
|
||||
`computeAccurateDirectHybrid()` のDS queueは、初期値と適応後の値の両方を `maxPixels=floor(workCap/iter)` で制限する。workgroupが64でも仕事件数を最低64にする必要はなく、端数laneをguardすれば1～63画素も処理できる。
|
||||
|
||||
全幅1行でも予算を超えるDeep stripは、既存の `correctUnknownFrameScan()` と同様にx方向も分割する。処理量は論理画素数×反復上限で数え、丸められたworkgroup数だけを根拠にしない。デバイスのbuffer・binding・dispatchサイズ上限は、この仕事量上限とは別に満たす。
|
||||
|
||||
## 4. 補修と参照を再利用する手順
|
||||
|
||||
### 正常画素を巻き戻さない
|
||||
|
||||
失敗したindexを別queueへ移す際、残る画素のstateとqueueを保持する。補修から戻る情報は次の2種類を区別する。
|
||||
|
||||
- **meta・smoothのみ**：脱出なら計算終了。未脱出ならstate未提供として保留し、この画素だけを必要に応じて再計算する。現行のDS／CPU補修は主にこちら。
|
||||
- **有効な継続state付き**：同じ参照・数値方式のグループへ戻せる。異なる局所参照なら、その参照に属する別グループへ入れる。
|
||||
|
||||
局所参照で回復したstateを、元の全体参照のstateとして扱わない。全体の `setDeepContext()` を変更して別グループの処理と競合させず、encode時に使う参照bufferを明示する。原点が変わる場合の差分変換は、この最初の実装には含めない。
|
||||
|
||||
### 参照軌道の末尾延長
|
||||
|
||||
参照IDは原点・実際の計算精度・数値方式で識別し、反復目標だけの増加では同じIDを維持する。精度の自動再試行でbit数が増えた場合は、要求精度ではなく採用した精度に基づいて別IDにする。
|
||||
|
||||
Workerは参照本体の `zr, zi, zr², zi², n` と、検査用の高精度軌道の独立した終端stateを保存する。精度Pの丸め済み終端を単にP+32へ拡張して検査の初期値にしない。両者の検査済みprefixを維持し、それぞれのstateから末尾を進める。
|
||||
|
||||
参照が既に脱出した場合は単純延長を続けず、別候補か局所参照へ進む。同じ候補を同じ条件で何度も選び直さない。prefixの検査点配置は長さに依存しない規則へ揃えるか、新目標で必要になる過去の検査点も確認する。GPU側も容量が足りる範囲では末尾だけを転送し、容量拡張時は旧参照の利用完了を待つ。
|
||||
|
||||
### CPU補修の小分け化
|
||||
|
||||
最初の候補設定は同時1～2 Worker、1ジョブ最大16～64画素に加え `件数×反復数` による上限を設ける。これは固定の最適値ではない。精度bit数・実行時間も見てジョブを縮小し、少数でも長い画素がUIの次の仕事を妨げないようにする。
|
||||
|
||||
同じ精度の結果再利用は最初に導入できる。Workerへ渡した入力の世代・座標・解像度・反復予算・精度が同じ場合だけ再利用し、前回の高精度結果を次の比較へ渡す。
|
||||
|
||||
結果は完了したジョブから受け取るが、GPUへの反映は1か所で直列化する。writeBuffer／scatterの**前**に世代と対象metaを確認し、同時進行するGPU補修が確定させた画素を古いCPU結果で上書きしない。現在の `applyPrecisionFallback()` 内ではtoken確認がwriteBuffer後にあるため、呼び出し側の確認だけに依存する非同期化を避ける。
|
||||
|
||||
回収できなかった画素は、小さな保留リストと次の手段を保持する。時間予算を使い切ったことを `numeric-complete` として報告しない。
|
||||
|
||||
## 5. 未脱出の反復予算と表示
|
||||
|
||||
最初のP0～P2では、変更前に採用されていた反復方針を可能な範囲で固定して比較する。ただしP0で新しい失敗や目標境界の脱出を正しく認識した場合、その差を性能回帰と誤認しない。
|
||||
|
||||
P3の候補は、同じ大域目標の中で「境界周辺・孤立成分・長時間残件」を別優先度にする方式から始める。全候補が目標に到達したかはGPUで `未到達件数` を集約する。低優先度の残件にも割当を設け、速く終わる画素ばかりを処理し続けない。これだけでは総反復数は減らないが、表示の改善順と処理継続性を制御できる。
|
||||
|
||||
総反復数を減らす変更は、検証できた内点の除外か、明示した有限予算への停止として別に扱う。内点判定を増やす場合は適用領域を限定し、軌道の近接や少数回の無変化だけで内点へ昇格しない。
|
||||
|
||||
表示・履歴・出力の意味は次のように統一する。
|
||||
|
||||
| 表示段階 | 条件 | 履歴・PNG |
|
||||
| --- | --- | --- |
|
||||
| 現在視点の暫定表示 | 計算済みタイルを順次表示。未処理領域があることを状態として保持 | 完成履歴へ保存しない |
|
||||
| 数値補修が完了した予算画像 | 被覆漏れ0、数値補修待ち0、残る未脱出は到達nを記録 | 既定の反復方針を満たすまでは暫定。明示的な暫定出力を設けるなら予算を付記 |
|
||||
| 現在の品質方針で完了 | 必要な全候補が目標と数値条件を満たし、品質方針の停止条件を満たす | 完成履歴へ保存できる。集合内の完全証明とは別 |
|
||||
|
||||
同一画素格子のタイル表示を先に検討する。低解像度の全体previewを追加する場合、半画素中心のずれを確認し、単に同じ画像範囲という理由で最終画素の計算へ流用しない。暫定表示で初回待ちが改善しても、数値補修完了の時間を別途示す。
|
||||
|
||||
## 6. 実装単位と確認ケース
|
||||
|
||||
| 単位 | 対象 | 採用するための確認 |
|
||||
| --- | --- | --- |
|
||||
| A：判定と上限 | 継続の目標終端、meta更新、DS／Deepの分割 | 最後の反復での脱出、誤差超過、未脱出の再投入、全分割の被覆を確認 |
|
||||
| B：同期とBigInt重複 | 小さなまとめ投入、精度ペア再利用 | Aと同一入力・予算で分類、脱出反復、smooth、到達nが一致。同期や軌道数が減る |
|
||||
| C：stateと参照の寿命 | 補修queue分離、参照末尾延長 | 少数の補修で正常stateが0に戻らず、参照変更・精度変更を混同しない |
|
||||
| D：補修転送 | タイル別GPU queue、scatter反映 | 件数だけでなくindexの被覆を確認。重複・古い世代・確定画素への上書きがない |
|
||||
| E：予算と表示 | 内点判定、優先度、暫定表示 | 未到達を完了扱いしない。操作と出力で品質方針が一致する |
|
||||
|
||||
必要な確認は既存の2つのテストファイルへ足す。常時監査や別の昇格システムは作らない。
|
||||
|
||||
| ケース | 確認する差分 | 現行テストの不足 |
|
||||
| --- | --- | --- |
|
||||
| 目標最後の1回で脱出する単一画素 | 更新後の脱出反復が目標内に記録される。例：c=1なら半径2を越えるのは3反復目 | Workerの参照は半径4で生成されるため、既存のWorker確認だけでGPUの目標境界は証明できない |
|
||||
| 目標到達時の誤差超過・未脱出・参照末尾 | 誤差検査が走る。正常未脱出だけが継続可能。参照外を読まない | スモークはmetaの反復到達・この分岐を直接検査しない |
|
||||
| 0／1／63／64／65件、奇数回／偶数回のまとめ投入 | queue交換、端数lane、空queue、同じ画素の重複処理がない | 現行テストは複数pass化のqueue内容を確認しない |
|
||||
| 広いcanvas・高反復・適応batch拡大 | `logicalCount×iterationBound` がカーネル別上限内、横分割で全画素を1回ずつ処理 | 現行のstrip検査は最小1行の上限超過を許容する |
|
||||
| 大半が正常で1画素だけ補修、参照の原点／精度変更 | 正常な進捗保持、補修画素だけの再参加、参照IDの分離 | ハッシュだけでは無駄な再計算を検出できない |
|
||||
| CPU補修中のパン・再ズーム・戻る操作 | 古い世代がwriteBuffer前に破棄される。最新画面の結果だけが残る | 現行のパン往復は各回の完了を待つため、処理中の競合を検査しない |
|
||||
| 同じ深部座標のFAST／Deepと独立した少数画素 | 共通バグを含む一致と、独立な高精度確認を区別 | 比較関数は主に不一致画素だけをCPU確認する |
|
||||
| 暫定表示中・完了後のPNG | 配列長だけでなく、同じ座標・予算の数値結果を出力する | 現行スモークは小さなRGBAタイルの長さ・checksumで、PNG全体の検証ではない |
|
||||
|
||||
正確性用の小ケースを先に実行し、性能ケースは初期表示とSeahorseのFAST／Deepを基本にする。主カージオイド／周期2円の境界変更時は `re=-0.75, im=0, span=0.02` の実軸付近を追加する。既知の黒領域問題は次の入力を固定小解像度で使用する。
|
||||
|
||||
```json
|
||||
{
|
||||
"re": "-29466147000382485924219538765424656674342940730553342389512209954887705938978413587",
|
||||
"im": "5179018789925933872641942859702187326563010594882200888329237785122225251258352",
|
||||
"span": "250637324516887125119843167990565159991251418774166207381437546036409",
|
||||
"bits": 273,
|
||||
"baseIter": 350,
|
||||
"adaptive": true,
|
||||
"processMode": "standard",
|
||||
"renderMode": "accurate",
|
||||
"fixed": true
|
||||
}
|
||||
```
|
||||
|
||||
出典はGit履歴の `tests/optimization_webgpu_corpus.mjs` にある `reported-black-regression`。`fixed:true` の整数座標なので10進実数として読み替えない。今回はこのケースをGPU実行していない。
|
||||
|
||||
## 7. 性能評価と中止条件
|
||||
|
||||
同じadapter、canvas画素数、座標、初期反復、最終品質方針で比較する。固定予算での実行効率と、予算を変える方式は別の結果にする。ブラウザー起動直後のコンパイル込み時間と、同じpipelineを使う描画時間も分ける。
|
||||
|
||||
ウォームアップ1回＋計測3回を最初の上限とし、中央値と全3件の値を保存する。ばらつきが大きく結論が出ない場合は「未判定」とし、同一条件が整ってから必要なケースだけ再測定する。多数の測定を自動で走らせ続けない。
|
||||
|
||||
追加する計測は、理由別失敗数、未到達数、GPU往復回数、readback byte数、仕事量上界、再初期化した画素数、BigInt軌道数の小さな集計に絞る。性能測定中に全画面のoracle比較を走らせない。独立した画素確認は正確性用の別実行にする。
|
||||
|
||||
数値補修完了時間が悪化する変更は、初回表示だけの改善と区別する。仕事量が減ってもメモリ増加や同期で時間が増える場合は、その段階の変更を採用しない。数値判定を緩めて性能値を合わせない。
|
||||
|
||||
GPUエラー・device loss・画素欠落・古い世代の書込みがあれば、そのケースを中止して原因を確認する。重いケースのtimeout後に、新しいEdgeを追加起動して続けない。検証用Edgeは1インスタンス・1タブ・直列実行とし、起動したプロファイルを識別して終了まで管理する。
|
||||
|
||||
## 8. 計画作成時点の成果と未実施事項
|
||||
|
||||
今回実施したのは、現行コードとの照合、旧案の誤記修正、参照キャッシュの小さな実コード確認、仕事量の数値例の再計算、実装設計の追記である。終端分岐・queue・精度の確認方法を具体化したが、新しい数値方式やスケジューラーを実装・GPU検証したわけではない。
|
||||
|
||||
参照サービスのfresh処理、代表点選択、予約reason、処理量上限、現行テストの限界は本文へ反映済み。期待効果は仮説として残し、改善率や任意座標での未確定ゼロを検証済みとは記載していない。新たなEdgeは起動していない。
|
||||
205
docs/PERFORMANCE_PLAN.md
Normal file
205
docs/PERFORMANCE_PLAN.md
Normal file
|
|
@ -0,0 +1,205 @@
|
|||
# 未確定画素を減らしながら軽量化する案
|
||||
|
||||
作成日：2026-09-05。精査・追記：2026-09-06。以下はBLA除去後のコードを調査した時点の計画。承認後の変更と測定結果は [実装結果](IMPLEMENTATION_RESULTS.md) を参照。
|
||||
|
||||
実装時の状態遷移・処理量上限・手順・確認ケースは [実装設計](PERFORMANCE_IMPLEMENTATION.md) にまとめた。
|
||||
|
||||
## 推奨方針
|
||||
|
||||
まず **計算済みの状態を使い続けること、GPUとの往復を減らすこと、失敗した画素だけを適切な精度で補修すること** に集中する。反復回数や誤差判定を一律に削って軽くする方針は採らない。
|
||||
|
||||
現状はBLAを除去しても、未脱出画素の全件継続、補修後のやり直し、細かいGPU完了待ち、各画素のBigInt再計算が残っている。ここを直す方が、別の近似加速器を追加するより先である。
|
||||
|
||||
最初の実装単位は次の3つを推奨する。
|
||||
|
||||
1. 未脱出画素の到達反復数・誤差を正しく記録し、未確定の分類を揃える。
|
||||
2. 継続計算のGPU投入を小さなまとまりにし、まとまりごとの読戻しにする。
|
||||
3. 補修が必要な画素だけを別キューへ移し、正常な画素の状態と参照軌道を保持する。
|
||||
|
||||
P0の判定修正は正しい結果へ直す変更であり、従来と結果が変わる可能性がある。P0後の結果を基準として、P1では最終反復数の方針を維持し、同じ計算結果を少ない再計算・同期で得る。その後に、内点の早期確定と画素ごとの反復予算を導入する。
|
||||
|
||||
## 1. 「計算不能」を分けて扱う
|
||||
|
||||
ここでいうセルは画素を指す。現在の `FIELD_UNKNOWN` は複数の状態を含むため、総数だけを最小化すると誤判定を増やしやすい。
|
||||
|
||||
| 状態 | 現行の表現 | 目指す扱い |
|
||||
| --- | --- | --- |
|
||||
| まだ計算していない | reason 0 | 最終画像で0。タイルの被覆漏れを防ぐ |
|
||||
| 精度・参照軌道の都合で結果を採用できない | reason 1～5 | 最優先で減らす。局所参照・精度昇格・高精度補修へ回す |
|
||||
| 現在の反復数まで脱出していない | reason 6、または `FIELD_INTERIOR_LIKELY` | 数値故障とは分ける。到達反復数を記録し、継続または内点判定へ回す |
|
||||
| DS感度を表す予約名 | reason 7（名前のみ。現行シェーダーに出力経路なし） | 現在の失敗原因とは数えない。将来出力するなら補修対象・集計まで同時に定義する |
|
||||
| 内点と確認できた | `FIELD_INTERIOR_PROVEN` | 継続キューから安全に除く |
|
||||
|
||||
**有限回の未脱出だけで集合内と証明したことにはならない。** また、異なる2精度で結果が一致したことは有用な確認だが、一般の境界画素について数学的な証明そのものではない。Direct DSとDeep DS補修も、全丸め誤差の区間を伝播して脱出を証明する実装ではない。全座標で「厳密分類・未確定0・短時間」を保証する目標は置かない。
|
||||
|
||||
reason 4の `rebase-gap` も、定義と集計は残るが現行シェーダーに失敗を書き込む経路は見当たらない。rangeやreference-endの実測件数と、予約理由を区別する。現在の統計配列の要素7は `corrected` 用なので、reason 7をそこへ足す変更はできない。
|
||||
|
||||
目標は、同じ表示精度・反復方針での数値失敗を可能な限り0へ近づけ、残った未脱出画素には正直な状態と継続手段を持たせること。UNKNOWNを黒や周囲の色へ置き換えるだけでは改善と数えない。
|
||||
|
||||
## 2. 現状から分かった負荷
|
||||
|
||||
根拠は [index.html](../index.html) のコードと [前回の確認結果](CLEANUP.md)。今回、追加のEdge起動や速度測定は行っていない。2026-09-06の精査では、参照サービスの実コードを使ったキャッシュ更新確認と、小さなCPU計算で数値例を確認した。以下のボトルネック順位はコードからの推定で、GPU時間・同期時間・CPU時間の内訳は未計測である。
|
||||
|
||||
| 箇所 | 確認できた処理 | 問題・軽量化の方向 |
|
||||
| --- | --- | --- |
|
||||
| `refinePixelFrontier()`、`operationLimitIndices()` | reason 6の全画素を候補にする。8近傍だけを選ぶ `operationLimitFrontier()` は本経路から呼ばれていない | 名前に反して境界だけの計算ではない。内点判定と優先順位が必要 |
|
||||
| `pixelFrontierIterationFloor()` | 画素幅のビット数×256を最低反復予算とする | 空間精度と必要脱出反復数を強く結び付けたヒューリスティック。深部では大きな追加計算になる |
|
||||
| `DEEP_ACTIVE_RESUME_INIT_WGSL` | `w=0, n=0, m=0` から開始する | 初期描画で計算した反復を、継続経路で再び計算する |
|
||||
| `refinePixelFrontier()` の `restart` | 数値補修があると、次の周回で残存候補全体のsessionを作り直すことがある | 少数の失敗で正常な画素まで再計算する |
|
||||
| `continueOperationLimitActive()` | 原則1 dispatchごとにsubmit、全queue完了待ち、4 byte件数のmapを行う | GPUとCPUの細かい往復。GPUに次の仕事が届くまで空く可能性がある |
|
||||
| `ReferenceService.requestFixed()`、参照Worker | 反復目標が変わりキャッシュにない場合、参照を再生成して検証する | 同一原点・同一精度なら末尾延長で済ませられる余地がある |
|
||||
| `recoverNumericalUnknownTiles()` | 局所参照のバッチごとに全画面metaを読戻し、CPUで所属画素を抽出 | 失敗が疎でも全画面転送・走査が発生する |
|
||||
| `precisionFallbackWorkerSource()` | 最大4試行で2精度ずつ、各画素を反復0から計算する | 高精度計算が重複する。同じ精度の計算結果を再利用できる |
|
||||
| `recoverResidualPrecision()` | 残件をWorker数で割り、実質全残件を一度に投入して `Promise.all` で待つ | 小さな費用上限で区切られておらず、長いCPU負荷になり得る |
|
||||
| `applyPrecisionFallback()` | Workerの結果ごとに反映と全画面統計を実行 | 細切れのアップロード・統計・完了待ちをまとめられる |
|
||||
| `qualityStages()`、`renderQualityStage()` | 深部は原則1回の最終描画。補修と継続が完了するまで新規frameの公開を待つ | 完了時間がそのまま初回表示待ちになる。履歴のない座標ジャンプで特に目立つ |
|
||||
|
||||
### 具体的な規模
|
||||
|
||||
前回の320×240、Seahorse、span `3.4e-13`、初期512反復では、FASTは32768反復まで進んで約36.7秒かかった。FASTとDeepの最終meta・smoothは一致したが、これは両者共通の停止条件・数値判定まで正しいという証明ではない。
|
||||
|
||||
この条件の画素幅は約49.74 bit相当で、現在の最低反復予算は12736。目標を倍増するため最低予算を初めて越えるのは16384で、さらに安定判定によって32768などへ進む。512から32768は反復目標で64倍であり、実際の総演算量が常に64倍という意味ではない。
|
||||
|
||||
現在のchunkは、残り反復数による切り詰めを除くと `max(1, min(256, floor(4,000,000 / activeCount)))`。全画素が継続対象のまま32768反復まで進む仮定では、320×240で少なくとも約631 dispatch、800×600で4096 dispatchになる。各目標境界、補修、参照生成の追加費用は含まない。実際には脱出によって対象が減るため、この例を実測dispatch数として扱わない。ここでいうdispatch数は反復カーネルの回数で、別にindirect引数を準備する小さなdispatchが各回にある。
|
||||
|
||||
## 3. 最初に直すべき判定上の問題
|
||||
|
||||
### 継続経路の終端誤差検査が通常の目標で実行されない
|
||||
|
||||
`DEEP_ACTIVE_CONTINUE_WGSL` の未脱出時の終端処理は `p.targetIter >= p.maxIter` を条件とする。一方、呼び出し側は `p.maxIter=150001`、通常の目標は最大150000である。そのため、この分岐の誤差検査と反復数のmeta更新には通常到達しない。脱出・range等の他の検査は別途存在する。
|
||||
|
||||
提案は、「次へ継続するための状態保存」と「今の目標まで計算した結果の判定」を分離すること。各目標境界で実際の `n` と誤差を記録し、必要な画素だけを補修へ回す。既存の終端分岐を単に有効化すると `return` によって継続キューから画素が脱落するため、state保存と再投入を含めて設計する。
|
||||
|
||||
さらにloop先頭で `s.n>=stop` を先に判定するため、最後の更新で到達した `z_target` の脱出判定は次の継続まで遅れる。表示をその目標で確定するなら、最終stateを評価してから未脱出として採用する必要がある。中間chunkではなく、結果を採用する目標境界で確認する。
|
||||
|
||||
この修正で今まで見えていなかった数値UNKNOWNが一時的に増える可能性がある。改善の評価は、その増加を隠さず、正しい判定後の補修コストと残件数で行う。
|
||||
|
||||
### 未脱出の表現と停止条件を揃える
|
||||
|
||||
Direct DSは未脱出を `FIELD_INTERIOR_LIKELY` として返す一方、別経路ではreason 6となり、継続対象が異なる。同じ予算で比較するには、数値的に判定できたこと、集合内であること、追加反復を待っていることを別々に扱う必要がある。
|
||||
|
||||
また、`pixelEscapeAdvance()` の「新しい脱出が既存の脱出画素の近傍内に収まる」という条件と2回の安定周回は、将来の孤立した脱出や1画素未満の誤差を保証しない。現行の実用的な停止条件として記録し、厳密な内点証明とは呼ばない。
|
||||
|
||||
### 処理量上限は全経路で統一されていない
|
||||
|
||||
400万pixel-iterationsは現行の継続・疎補修の設計値であり、すべてのdispatchに適用できている保証ではない。`computeAccurateDirectHybrid()` のDS queueは初期batchを上限から決めるが、時間による拡大後に同じ上限でclampしていない。12000反復では333画素から500画素へ増えるだけで600万になる。
|
||||
|
||||
`initialNumericRows()` は最小1行なので、`幅×反復数` が予算より大きい場合は1行でも超える。既存の `regression.mjs` はこの例外を許容する検査で、全経路400万以下の証拠にはならない。重いDS／Deep経路は必要なら横方向も分割し、どの適応処理でも最終的に上限へ戻す。FASTの4800万等とは別のカーネル別予算として管理する。GPUの経過時間は演算内容にも依存するので、画素×反復数だけで停止防止を保証しない。
|
||||
|
||||
## 4. 軽量化案と優先順位
|
||||
|
||||
| 優先 | 案 | 期待する効果 | 未確定を増やさない条件 |
|
||||
| --- | --- | --- | --- |
|
||||
| P0 | 上記の状態・誤差判定と処理量上限を整理 | 評価基準と分割の前提を正す | 未検査の画素を確定扱いせず、上限超過時はさらに分割する |
|
||||
| P1 | GPU投入をまとめ、読戻しを間引く | 同期・submit・JS呼び出しを削減 | 各dispatchの上限と投入総量を維持 |
|
||||
| P1 | 正常画素のstateと参照軌道を保持 | 反復0からの重複計算を削減 | 参照原点・精度・計算式が同一であること |
|
||||
| P1 | 数値失敗キューをGPU上で作る | 全画面readback・CPU走査を削減 | キュー被覆とoverflow時の処理を保証 |
|
||||
| P2 | 失敗理由別に補修を選ぶ | 回収できない補修の反復を削減 | 失敗した画素には次の補修手段を残す |
|
||||
| P2 | BigIntの重複計算と一括投入を減らす | CPU負荷・最長待ち時間を削減 | 2精度比較と未採用画素の追跡を維持 |
|
||||
| P3 | 安全な内点判定を加える | 未脱出キュー自体を縮小 | 判定に失敗した点は通常計算へ戻す |
|
||||
| P3 | 画素・タイルごとに反復予算を配分 | 一律の深い反復を削減 | 優先度の低い未確定画素を捨てない |
|
||||
| P4 | 同一視点の段階表示とメモリ上限 | 初回待ち・メモリ圧迫を軽減 | 暫定表示を完成履歴へ昇格させない |
|
||||
|
||||
### P1-A：GPU主導の継続と小さなまとめ投入
|
||||
|
||||
`encodeDeepActiveChunks()` は既に複数passを符号化できる。最初は2～4回程度の有界dispatchをまとめ、件数を読むのはまとまりの最後だけにする。GPU上の件数からindirect dispatchを構築し、対象0の後続passは何も処理しないようにする。
|
||||
|
||||
補修画素の再投入がないまとまりの中ではactive数は増えない。その入口の件数を保守的な上限に使えば、毎回CPUへ戻らず各dispatchの処理量を制限できる。再投入するときはこの前提を更新する。
|
||||
|
||||
4 byteの読戻し自体のために `mapAsync()` の前で全queueの完了を重ねて待つ必要はない。対象バッファのGPU使用完了はmapの成立で扱える。ただし、mapの成立は他バッファや別のpromiseの完了を意味しない。投入量の制御や別用途の完了待ちは分けて残す。[WebGPU仕様のbuffer mapping](https://gpuweb.github.io/gpuweb/#buffer-mapping)
|
||||
|
||||
継続・高コスト補修の各dispatchを400万pixel-iterations以内へ実際に制限したうえで、GPUへ先行投入する時間・総仕事量にも上限を置く。まとめる回数を増やしてWindowsのGPU停止やキャンセル遅延を再発させない。uniformの値がpassごとに変わる場合は専用offsetや別バッファで保持し、submit前の同じuniform領域への上書きで全passが最後の値を見る構成にしない。[WebGPU開発者による複数passのuniform書き込みの説明](https://github.com/gpuweb/gpuweb/discussions/2509)
|
||||
|
||||
### P1-B：正常なstateと参照軌道を使い続ける
|
||||
|
||||
最初に補修キューと継続キューを分離する。数値失敗した画素だけを継続キューから外し、正常画素の `d, w, scaleExp, n, m, errScaled` を保持する。補修した画素は、その結果と参照に対応したstateで再参加させる。stateを復元できない画素に限って再計算する。
|
||||
|
||||
次に、同一原点・同一精度の参照Workerに末尾stateを保持し、目標増加時は軌道の末尾を延長する。既に検査したprefixは同じ条件のまま保持し、新しく追加した部分を検査する。精度変更や原点変更時は別の参照として扱う。
|
||||
|
||||
初期Deep描画からの継続state保存はその次に行う。FAST・Direct・DSのstateをDeepへそのまま移植しない。実装を共通化する場合も、丸め順・誤差・参照の契約を揃えてから採用する。
|
||||
|
||||
参照が短い場合の `refs.request(..., true)` は、現行の第5引数 `fresh` によって該当キャッシュを削除する。旧案の「引数がなく無効」という記述は誤りだった。ただし同じ入力の処理中promiseは再利用され、再生成しても決定的な候補探索は同じ原点を選び得る。改善対象はfreshの追加ではなく、試した原点の記録、失敗分布に基づく別候補の選択、十分な長さを得られない場合の処理である。
|
||||
|
||||
### P1-C：GPU内で失敗画素を集める
|
||||
|
||||
reason別・タイル別の件数、prefix sum、画素indexのscatterをGPU上で作り、局所参照ごとの範囲をそのまま補修へ渡す。既存の疎キューを拡張する形を優先し、別の監査基盤は追加しない。
|
||||
|
||||
CPUへ必要なのは参照を選ぶための小さなタイル要約と、最終的にBigIntへ渡す少数の失敗indexである。全画面metaの読戻しは通常の補修ループから外し、任意の検証や例外処理に限定する。
|
||||
|
||||
overflowや被覆漏れの検査はGPUで集計してまとまりの最後に確認する。件数確認を減らすことと、未処理画素を黙って捨てることを混同しない。
|
||||
|
||||
### P2-A：失敗理由ごとの補修
|
||||
|
||||
| 理由・分布 | 最初に試す処理 | 次の処理 |
|
||||
| --- | --- | --- |
|
||||
| reference-end | 同一原点の軌道延長。実際に脱出する参照なら失敗領域内で参照を再選択 | 局所参照で再計算 |
|
||||
| error-boundが局所に集中 | 既存参照でのDS補修か、回収実績のある局所参照を選ぶ | 改善しなければ高精度補修 |
|
||||
| escape-uncertain | 該当画素だけ精度を上げる | 必要な画素だけBigInt |
|
||||
| range | スケーリングと座標差の表現を確認 | 指数を持つ表現または高精度補修 |
|
||||
| 広く密集した失敗 | タイル単位で参照・精度を選び直す | 大量の画素別BigInt投入を避ける |
|
||||
|
||||
現在も `readNumericalFailureTiles()` はタイル内の最小indexの失敗画素を代表点に使っている。`sumX/sumY` という名前だが重心の総和ではなく、その代表点×件数である。改善は、この既存代表点を基準に失敗の密集度・到達反復・過去の回収費用から少数の代替候補を選ぶこと。単に「中心から失敗画素へ変更する」という新規機能ではない。参照変更でグリッチを減らせる一方、近い参照を選ぶだけで誤差を保証できるわけではない。[摂動法のグリッチと参照選択](https://mathr.co.uk/blog/2014-03-31_perturbation_glitches.html)
|
||||
|
||||
reason 4・7を将来使う場合の経路は予約設計として別途定義する。発生していない理由に専用の常時計算を追加しない。
|
||||
|
||||
補修1回で回収できた画素数、残件数、費用を少数の集計値で保持する。回収の止まった手段を同じ条件で繰り返さず、次の手段へ送る。時間切れの画素は保留として残し、補修完了数へ加算しない。
|
||||
|
||||
### P2-B：BigInt補修を小さくする
|
||||
|
||||
現在の精度比較は `P/P+32 → P+32/P+64 → …` で、隣り合う試行が同じ精度の軌道を再計算する。前回の高精度側の結果を次の低精度側へ使えば、最大4試行の8軌道を5軌道に減らせる。最初の比較で成功する画素にはこの削減は発生しない。
|
||||
|
||||
Workerへの仕事は全残件の等分ではなく、小さな画素数・推定pixel-iterationsで区切る。まず1～2 Workerを基本にして空いたWorkerへ次のバッチを渡し、端末の余裕がある場合だけ増やす。入力が来たら追加投入を止め、長い処理は必要に応じてWorker終了で取り消す。
|
||||
|
||||
同時期に返った結果のindex・meta・smoothをまとめて転送し、GPU scatterで反映する。全画面統計はWorker結果ごとではなく適用バッチごとに1回。2精度で採用できない画素は失敗キューに残す。
|
||||
|
||||
### P3-A：継続が不要な内点を安全に除く
|
||||
|
||||
Directにある主カージオイド・周期2円の判定を、適用可能なタイル・参照表現へ広げる。深い座標を単純にf32へ丸めて判定せず、高精度座標または誤差を含む区間で領域内と確認できた場合だけ採用する。領域から遠いタイルでは判定自体を省ける。[Cardioid and bulb checking](https://mathr.co.uk/blog/2022-11-19_cardioid_and_bulb_checking.html)
|
||||
|
||||
さらに一般の周期成分を対象とするなら、周期候補の検出と内点の確認を分ける。有限精度で同じ値になった、近い位置へ戻った、という理由だけでは確定しない。包含・収縮等を確認できる方式は後段の研究候補とし、全画素で毎反復行わず長く残る画素に絞る。
|
||||
|
||||
主カージオイドと周期2円だけでは、Seahorseや小さなコピー内部の問題を全部解決できない。効果の対象範囲を区別する。
|
||||
|
||||
### P3-B：反復予算を空間精度と切り離す
|
||||
|
||||
画素幅は座標の必要精度を決める。一方、外部の点が何回で脱出するかは軌道に依存するため、`pixelBits × 256` は必要反復数の証明ではない。
|
||||
|
||||
一律の倍増を置き換える候補は、境界近傍、孤立した未脱出成分、長時間残る画素を別キューで管理し、変化の多い部分を優先する方式。低優先度の未確定画素にも一定量を配り、孤立した遅い脱出を永久に取り残さない。8近傍だけへ対象を限定する変更は行わない。
|
||||
|
||||
この変更は従来と最終反復数・停止条件が変わり得る。P1の純粋な実行効率改善と分けて評価する。通常閲覧の有限予算と、明示的な高品質計算の扱いを決め、到達予算と未確定数を内部状態に残す。
|
||||
|
||||
### P4：表示待ちとメモリ負荷を抑える
|
||||
|
||||
最終的な未確定を減らす処理を継続しつつ、現在の視点で計算した暫定結果を段階表示する案を検討する。全体の低解像度計算を単純に追加すると二重計算になるため、同一画素格子のタイル完成表示か、最終計算へ再利用できる段階処理を優先する。暫定画像は完成履歴にしない。
|
||||
|
||||
現在のactive用stateは全画面に32 byte/画素、2本のqueueは合計8 byte/画素。800×600ならこの部分だけで約18.3 MiBあり、meta・smooth・texture・参照は別に必要になる。候補数が少ないときは密なslot配列、候補が多いときは上限付きタイルworkspaceを使い分ける。ただし画素indexとslotの対応、世代、queue境界を明確にする。slot方式でindex対応表を追加すれば、その分のメモリも増える。タイル処理でも生存stateを破棄して毎回0から計算してはならない。
|
||||
|
||||
## 5. 実装・確認の進め方
|
||||
|
||||
| 段階 | 変更範囲 | 確認すること |
|
||||
| --- | --- | --- |
|
||||
| 0 | 終端判定・未確定分類・処理量上限・最低限の集計 | 正常画素と未検査画素を区別できる。継続画素がqueueから消えず、適応batchも上限内 |
|
||||
| 1 | 同期のまとめ、BigIntの同精度結果再利用 | 同じ予算で脱出分類・反復数・smoothが一致。同期数と重複軌道数が減る |
|
||||
| 2 | 失敗キュー分離、正常state保持、参照末尾延長 | 補修後も正常画素の進捗が戻らない。数値UNKNOWNが減るか増えない |
|
||||
| 3 | GPUでのタイル別queueと補修選択 | 全画面読戻しbyte数、BigInt対象数、補修失敗の再試行が減る |
|
||||
| 4 | 内点判定と反復予算・段階表示 | 内点の誤確定を防ぐ。遅い脱出・孤立成分・操作往復で破綻しない |
|
||||
|
||||
自動監査を描画ループへ戻さない。計測は `?test` の明示実行で、初回表示までの時間、数値補修完了までの時間、未確定の理由別件数、仕事量上界、再初期化数、GPU読戻し回数・byte数、CPU補修数を1ケース1レコードへ集約する。現在の `activeCount×chunk` は早期脱出分も含む上界で、実行した反復数そのものではない。実反復を測るならテスト時のみGPU内で集約し、区別して記録する。
|
||||
|
||||
テストは既存の `regression.mjs` と `browser_smoke.mjs` を必要な分だけ拡張する。初期表示、同じSeahorse座標のFAST／Deep、実軸付近、既知の黒領域問題の座標を小さな代表セットとする。最初は同じadapter・解像度・予算でウォームアップ1回＋計測3回。少数回の測定からp95は主張しない。
|
||||
|
||||
GPU制御は **検証用Edgeを1インスタンス、タブを1つ** に限定し、ケースを直列実行する。Edge内部の複数プロセスはあり得るが、ケースごとにブラウザーやプロファイルを増やさない。終了時に今回の検証用ブラウザーを閉じ、通常利用のブラウザーは終了対象にしない。
|
||||
|
||||
採用条件は、同条件での数値失敗の減少または非増加、計測した時間・仕事量の削減、既知の表示破綻がないこと。P0で従来未検査の失敗を可視化した直後は、修正後の正しい状態を比較基準とする。速度改善率・任意座標での未確定0は実装前に約束しない。
|
||||
|
||||
既存テストはこの案の採用条件をまだすべて検査しない。特に `numericalFailures=0` とFAST／Deep一致だけではP0の終端検査や共通する誤りを検出できない。既存の比較関数は不一致箇所だけを高精度で確認するため、一致した画素の独立確認も少数必要である。追加する確認ケースと、現行テストが未対応の範囲は実装設計に明記した。
|
||||
|
||||
## 6. 後回しにする案
|
||||
|
||||
- BLA、series approximation等の別の近似加速器の再導入。まず既存計算の重複・同期・補修を直す。
|
||||
- 全画面を常にDS／BigIntにする変更。高精度が必要な画素へ限定する。
|
||||
- Worker・Edge・GPU投入数の無制限な増加。
|
||||
- 誤差guardの緩和、未確定画素の着色だけで件数を減らす変更。
|
||||
- 常時shadow比較、フレームごとの全面ハッシュ、新しい多段階昇格ゲート。
|
||||
|
||||
未使用の `encodeDeepBucketHistogramStats()` や旧背景補修経路などの追加整理は可能だが、実行されていないコードの削除だけで数十秒の描画時間は解消しない。次の実装では、上記の実際に実行される仕事量と待ち合わせを優先する。
|
||||
|
|
@ -1,31 +1,41 @@
|
|||
# Mandelbrot WebGPU v24.2.55
|
||||
# Mandelbrot WebGPU
|
||||
|
||||
## 目的
|
||||
v24.2.54で確認された、FAST深部描画の矩形状/穴状の黒欠損と、数値補修を最終表示前に待つことによるレイテンシ増大を修正する。
|
||||
`index.html` をWebGPU対応のEdge／Chromeで開く。外部ライブラリやビルドは不要。
|
||||
|
||||
## 黒穴の原因
|
||||
COLOR passでは数値UNKNOWNを透明としていたが、PRESENT passが履歴補完を `scale <= 1.035 / offset <= 0.022` に制限していた。そのため通常のズームでも履歴補完が無効になり、透明UNKNOWNがcanvasの黒背景へ落ちた。
|
||||
- 描画は高速方式に統一。画素間隔に応じてDirect f32または参照軌道を使うFAST perturbationへ自動で切り替える。旧「正確」の共有URLもこの方式で開く。
|
||||
- パン／ズーム、配色変更、URLによる表示位置の共有、PNG出力に対応。
|
||||
- 数値未確定画素の補修と未脱出画素の継続計算を終えてから、完成画像を履歴へ保存する。
|
||||
- 計算中は現在の視点の暫定画像を表示する。反復上限は「自動」または指定回数を選べる。未脱出を集合内の証明とは扱わない。
|
||||
- 画面と同じ解像度・1 sampleのPNGは、補修済みの完成画像をそのまま保存する。
|
||||
- 色相変化は表示済みの数値結果を使い、計算中も色を更新する。停止ボタンまたは色相位置の手動操作で停止する。
|
||||
- 描画時間は初期描画から精細化・数値補修・最終GPU処理までの合計。計算中は経過時間、完了時は確定した時間を表示する。
|
||||
|
||||
さらに、その不完全front textureを完成historyとしてcommitする経路があった。局所reference補修が予算内で全UNKNOWNを回収できない場合、タイル境界に沿った黒欠損が完成画像へ固定され得た。
|
||||
BLAと比較専用の監査処理は削除済み。[整理内容と検証範囲](CLEANUP.md)を参照。
|
||||
|
||||
## v24.2.55の契約
|
||||
1. 数値UNKNOWNを含むfrontはstable historyへ昇格しない。
|
||||
2. 通常のパン/ズーム範囲では、数値UNKNOWNを直前のstable frameから再投影して埋める。
|
||||
3. FASTの数値補修は一次画像のpublishをブロックせず、同一viewのbackground taskとして継続する。
|
||||
4. background補修が完了して数値UNKNOWNが0になった時点で初めてhistoryを更新する。
|
||||
5. tiled FAST開始時にmeta/smoothをzero sentinelへ初期化し、最終color前にreason=0の未書込pixelだけbaseline FASTで再計算する。
|
||||
[軽量化の実装結果と測定値](IMPLEMENTATION_RESULTS.md)を参照。承認前の[改善案](PERFORMANCE_PLAN.md)と[実装設計](PERFORMANCE_IMPLEMENTATION.md)も残している。
|
||||
|
||||
`REASON_OPERATION_LIMIT` は数値故障ではなく、maxIterまで未脱出だったpixelなので従来どおり黒表示する。今回の矩形状欠損対策は主に数値UNKNOWN/未書込pixelを対象とする。
|
||||
色相・時間表示の修正と描画方式統合については[ビューワー修正](VIEWER_FIXES.md)を参照。
|
||||
|
||||
## FASTレイテンシ
|
||||
production BLAのCPU側64点shadow計算を廃止した。BLA workerはtable構築だけを行い、採用判定は既存の64点GPU probeへ一本化した。
|
||||
## 検証
|
||||
|
||||
classic Seahorse Valley相当 (654x690, span 3.4e-13, 2900 iter) のNode/V8 workerモデル:
|
||||
- 旧 CPU validate 64点: 約446.9 ms
|
||||
- 新 table build only: 約60.0 ms
|
||||
- 同期prep削減: 約386.9 ms
|
||||
Node.js 22以降で実行する。追加パッケージは不要。
|
||||
|
||||
BLAが不利なviewでは本体FAST計算時間そのものは残る。今回の変更では、数値補修Deep/multi-referenceを一次表示のクリティカルパスから外すことで、黒穴を出さずに操作から画像表示までの待ち時間を短縮する。
|
||||
```sh
|
||||
node tests/regression.mjs
|
||||
```
|
||||
|
||||
## 数値コア
|
||||
v24.2.54から変更したproduction WGSLはFAST_PERTURB_WGSLのみ。通常 `unknownOnly=0` の計算式・perturbation recurrenceは変更していない。追加分はcoverage repair用のearly guardである。
|
||||
構文、現行シェーダーのハッシュ、バックエンド選択、フレーム振り分け、Worker、補修対象と処理量上限を確認する。ハッシュファイルを無条件に再生成してテストを通さないこと。
|
||||
|
||||
実GPUのスモークテストは、独立した一時プロファイルのEdge／Chromiumをリモートデバッグポート9333で起動して実行する。
|
||||
|
||||
```sh
|
||||
node tests/browser_smoke.mjs 9333 all
|
||||
```
|
||||
|
||||
`all` は `reset`、`fast`、`mid`、`legacy`、`axis`、`black`、`kernels`、`cancel`、`budget`、`ui` に置き換えて単独実行できる。描画6ケース（旧方式指定の移行を含む）、キューの被覆、独立高精度サンプル、計算中のキャンセル、指定反復予算、PNGの復号、色相変化、時間表示を確認する。
|
||||
|
||||
起動時は拡張機能と同期を無効にし、専用プロファイルのタブを1つだけにする。テストはそのタブを再利用し、最後に `about:blank` へ戻す。終了後は検証用ブラウザーを閉じる。
|
||||
|
||||
測定が必要な場合だけ `node tests/browser_smoke.mjs 9333 bench` を実行する。初期表示・Seahorse FASTを各1回ウォームアップ＋3回測定する。通常の回帰確認ではベンチマークを繰り返さない。
|
||||
|
||||
検証APIと詳細計測は `index.html?test` でのみ有効。通常起動では監査計算を自動実行しない。Strict設定も比較テストを起動しない。
|
||||
|
|
|
|||
|
|
@ -1,75 +0,0 @@
|
|||
# Validation Report — v24.2.55
|
||||
|
||||
## 1. JavaScript / bundle syntax
|
||||
- kernel bundle: PASS
|
||||
- application bundle: PASS
|
||||
|
||||
## 2. production kernel差分
|
||||
v24.2.54とのSHA-256比較。
|
||||
|
||||
変更:
|
||||
- `version`
|
||||
- `FAST_PERTURB_WGSL`
|
||||
|
||||
不変:
|
||||
- Direct
|
||||
- Accurate seed / DS direct
|
||||
- Deep perturbation
|
||||
- Deep correction
|
||||
- COLOR
|
||||
- PRESENT shader本体
|
||||
- BLA candidate / production frame kernels
|
||||
|
||||
FAST_PERTURBの通常recurrenceは不変。`unknownOnly=2` 時だけzero-sentinel pixelを再計算するearly guardを追加。
|
||||
|
||||
## 3. coverage contract
|
||||
PASS:
|
||||
- tiled numeric開始時にmeta/smoothをzero clear
|
||||
- color前にbaseline FAST coverage repair
|
||||
- coverage repairはreason=0 UNKNOWNだけをiteration
|
||||
- 既計算pixelはearly return
|
||||
|
||||
これにより、strip/tile未書込が発生してもrectangular zero-metadata holeをそのままpublishしない。
|
||||
|
||||
## 4. temporal fill / history
|
||||
PASS:
|
||||
- history利用範囲をstable reprojectionと同じ `2.25 / 0.45` へ統一
|
||||
- numeric recovery pending/running時はstable historyへcommitしない
|
||||
- recolor経路も `numericFrameComplete()` を満たさない限りhistoryへcommitしない
|
||||
|
||||
## 5. background numeric recovery
|
||||
PASS (static/control-flow):
|
||||
- FAST primary終了後に数値failureがあれば60ms後にbackground recoveryを予約
|
||||
- local multi-referenceを先行
|
||||
- 残存時だけfull Deep + DS + local recovery
|
||||
- view tokenが変われば結果をpublishしない
|
||||
- recovery中のrecolorはqueueへ退避
|
||||
|
||||
## 6. BLA production prep
|
||||
classic Seahorse Valley相当のworker-model実測:
|
||||
- 旧64-point CPU validation: 446.9 ms
|
||||
- 新build-only: 60.0 ms
|
||||
- 同期prep削減: 386.9 ms
|
||||
|
||||
BLA table buildそのものはほぼ同時間 (58.4 vs 59.4 ms)。削減分は描画前CPU shadow sample計算。
|
||||
|
||||
## 7. BLA safety regression
|
||||
既存289-point Seahorse test、safety=1/64:
|
||||
- classification mismatch: 0
|
||||
- first escape mismatch: 0
|
||||
|
||||
productionではCPU per-view validationを外したが、64-point GPU probeとBLA pixel fallback契約は維持。
|
||||
|
||||
## 8. browser smoke
|
||||
Chromiumでlocalhostからロード:
|
||||
- page JavaScript error: 0
|
||||
- kernelVersion: `24.2.55-no-black-hole-async-recovery`
|
||||
|
||||
このコンテナでは当該起動条件でWebGPU adapterを取得できなかったため、canvasを含む実端末フレーム時間は未測定。
|
||||
|
||||
## 9. release layout
|
||||
- executable HTML: `index.html` の1本のみ
|
||||
- `index.baseline-*.html`: なし
|
||||
|
||||
## 残る性能課題
|
||||
BLA probeがOFFになるSeahorse/Misiurewicz型viewではbaseline FASTのpixel-iteration量が依然支配的。v24.2.55はこのケースのCPU prepと同期補修待ちを削るが、primary perturbation本体を別アルゴリズムで高速化する変更ではない。
|
||||
35
docs/VIEWER_FIXES.md
Normal file
35
docs/VIEWER_FIXES.md
Normal file
|
|
@ -0,0 +1,35 @@
|
|||
# 色相・描画時間・描画方式の修正
|
||||
|
||||
対象：`index.html`。2026-09-06。
|
||||
|
||||
## 色相変化
|
||||
|
||||
従来は数値計算中の色変更を保留し、精細化終了時に保留分を実行する処理も抜けていた。精細化終了後に最新の色を必ず反映するようにした。
|
||||
|
||||
自動色相変化中は、公開済みの数値結果だけを別のGPUバッファへ保持し、独立した色用テクスチャへ描く。計算中のバッファやfront/backを変更せず、GPUキューの順序を保って表示色を更新する。位置が変わった際は保存した視点に応じて再投影する。新しい暫定結果の公開時に色用の数値結果も更新する。
|
||||
|
||||
追加領域は自動色相変化を使う間だけ確保する（12 byte/画素＋32 byte、320×240で約0.88 MiB）。停止後の色反映または次の結果公開で解放する。数値再計算はせず、色更新は最大約20回/秒。GPUが処理中の場合のフレームレートは機器の負荷に依存する。
|
||||
|
||||
## 描画時間
|
||||
|
||||
従来の表示は最後の処理段階の時間だった。初期描画・精細化待ち・参照作成・数値補修・最終GPU処理を含む、1回の生成全体の経過時間へ変更した。描画中は250 ms間隔で更新し、完了時にその場で確定する。色変更では計測をやり直さない。
|
||||
|
||||
途中キャンセルとエラーを完了と区別し、古い生成からの完了通知は新しい計測を終了させない。起動時に初期化完了通知から同じ視点を重複生成する処理も抑止した。画面への物理的な走査時間は計測に含まない。
|
||||
|
||||
## 描画方式の統合
|
||||
|
||||
独立した「正確」モードと専用Direct DSの4シェーダー、専用パイプライン、全画面Deep初期計算、未使用の背景Deep切り替えを削除した。描画方式の選択UIはなくし、従来の高速方式へ統一した。旧URLの `rm=accurate` は高速方式で復元し、旧ローカル設定も除去する。
|
||||
|
||||
高速方式でも使うBigInt参照、局所参照、DS補修、CPU高精度補修、未脱出画素の継続計算は維持する。これらの数値シェーダーは変更していない。名前としての「正確」を外すことで、有限反復の描画を数学的な全画素証明と誤解させない。任意の座標・反復予算での数値失敗0を保証するものではない。
|
||||
|
||||
中間倍率の確認で、自動反復の150000回へ正常到達しても安定判定を満たさないと画像を完成扱いにできない問題も見つかった。残った全画素の到達反復数を確認できた場合は有限予算の結果として公開し、「反復上限で完了」と表示する。未脱出は未脱出のまま記録し、内点へ置き換えない。到達不足や数値故障は引き続き完成扱いにしない。
|
||||
|
||||
## 検証
|
||||
|
||||
`node tests/regression.mjs` と、専用Edge 1インスタンス・1タブで `node tests/browser_smoke.mjs 9333 all` を使用する。色相テストはボタンの状態だけでなく、表示に使うGPUテクスチャの画素変化と数値バッファの不変性を確認する。長い数値補修中の色変更、停止、手動操作、完成時の保留色反映、通常描画との数値一致も対象。
|
||||
|
||||
時間表示は段階間の待ちを含む合計、数秒かかる実描画の完了直後の表示、色変更で時間が変わらないことを確認する。旧設定と共有URLの移行、描画6ケース、独立BigIntサンプル、キャンセル、PNGも従来の回帰テストに含める。
|
||||
|
||||
追加した中間倍率（Seahorse、span=1e-6）と旧Deep専用の黒領域は、それぞれ12サンプルの分類と脱出反復数が独立BigInt計算に一致した。一方、連続色付け用smooth値の差は最大約0.0367反復分／0.0516反復分だった。両ケースではsmoothのULP精度を保証せず、偏差をテスト出力に記録する。高速Seahorseと実軸の8 ULP以内という検査は維持している。旧正確モードと同じ色の数値精度を維持したという主張ではない。
|
||||
|
||||
最終版でCPU回帰と実GPUの `all` が通過した。6描画ケースの数値失敗は0。1100×720の実画面でも自動色相変化による色の変化、描画完了直後の「2.32 s」、描画方式の選択肢がないことを確認した。検証用Edgeと専用プロファイルは終了・削除済みで、残存Edgeプロセスは0だった。
|
||||
Loading…
Add table
Add a link
Reference in a new issue