333/mandelbrot
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

q

Browse source
This commit is contained in:
33333-33333 2026-08-25 14:03:13 +09:00
commit b653d77d4e
49 changed files with 1636 additions and 4724 deletions
Download patch file Download diff file Expand all files Collapse all files

15
docs/CHANGELOG.md
View file

@ -1,15 +0,0 @@
# CHANGELOG
## v24.2.26
- v24.2.23〜v24.2.24 のLOD / frontier全画面再計算系を撤回。
- v24.2.18 の Direct / Fast / Deep / Color WGSL を完全復元。
- v24.2.18 の `maxIter` と fallback を復元。
- 一次描画後だけ起動する GPU-only `INTERIOR_LIKELY` queue を追加。
- 補足精密化は高速モードでも guarded Deep で実行。
- 精密化シェーダーは一次表示後に遅延コンパイル。
- queue候補は境界近傍 + 疎なscreen-space seedに限定。
- CPUへ戻す精密化情報は16 byte統計のみ。全meta readbackなし。
- 標準精密化batchを最大1.8M sample-iterationsに制限。
- 自動色変化速度を v24.2.18 の1/10へ変更。
- baseline一致・batch予算・品質単調性の専用テストを追加。

128
docs/README.md
View file

@ -1,117 +1,31 @@
# Mandelbrot Deep Zoom v24.2.26
# Mandelbrot WebGPU v24.2.55
## 目的
v24.2.54で確認された、FAST深部描画の矩形状/穴状の黒欠損と、数値補修を最終表示前に待つことによるレイテンシ増大を修正する。
v24.2.23〜v24.2.24 系で発生した「品質低下・速度低下」を撤回し、**v24.2.18 の一次描画を基準線として復元**した版です。
## 黒穴の原因
COLOR passでは数値UNKNOWNを透明としていたが、PRESENT passが履歴補完を `scale <= 1.035 / offset <= 0.022` に制限していた。そのため通常のズームでも履歴補完が無効になり、透明UNKNOWNがcanvasの黒背景へ落ちた。
この版の合格条件は次の4点です。
さらに、その不完全front textureを完成historyとしてcommitする経路があった。局所reference補修が予算内で全UNKNOWNを回収できない場合、タイル境界に沿った黒欠損が完成画像へ固定され得た。
1. 一次表示は v24.2.18 より遅くしない。
2. 補足精密化を停止しても v24.2.18 より品質を下げない。
3. 通常描画ループで fieldMeta 全体を GPU→CPU readback しない。
4. 黒い `INTERIOR_LIKELY` の追加判定は一次表示後・アイドル時だけ行う。
## 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で再計算する。
## 一次描画
`REASON_OPERATION_LIMIT` は数値故障ではなく、maxIterまで未脱出だったpixelなので従来どおり黒表示する。今回の矩形状欠損対策は主に数値UNKNOWN/未書込pixelを対象とする。
一次描画の以下のWGSLは v24.2.18 と **SHA-256まで一致**しています。
## FASTレイテンシ
production BLAのCPU側64点shadow計算を廃止した。BLA workerはtable構築だけを行い、採用判定は既存の64点GPU probeへ一本化した。
- `DIRECT_F32_WGSL`
- `FAST_PERTURB_WGSL`
- `DEEP_PERTURB_WGSL`
- `COLOR_WGSL`
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
`maxIter()` も v24.2.18 と同じです。
BLAが不利なviewでは本体FAST計算時間そのものは残る。今回の変更では、数値補修Deep/multi-referenceを一次表示のクリティカルパスから外すことで、黒穴を出さずに操作から画像表示までの待ち時間を短縮する。
```text
baseIter + floor(70*sqrt(zoomExp) + 15*zoomExp)
```
1920×1080 / 標準負荷の代表条件では内部描画は約 1672×941 = 1,573,352 px です。
| zoom | 一次 iter | 一次描画の最悪 sample-iterations |
|---:|---:|---:|
| 10^6 | 611 | 0.961 B |
| 10^8 | 667 | 1.049 B |
| 10^12 | 772 | 1.215 B |
| 10^20 | 963 | 1.515 B |
これは v24.2.18 と同じ計算量です。補足精密化用WGSLも起動時にはコンパイルせず、一次描画完了から320ms後に初めて遅延コンパイルします。
## アイドル補足精密化
一次描画後にだけ `FIELD_INTERIOR_LIKELY` を追加判定します。
### GPU-only queue
全 `fieldMeta` をCPUへ戻しません。GPU上で候補インデックスqueueを作り、CPUへ戻すのは **16 byte のqueue統計だけ**です。
候補は次のように絞ります。
- stage 1: 境界近傍 + 4px間隔 seed
- stage 2: 境界近傍 + 8px間隔 seed
- stage 3: 境界近傍 + 16px間隔 seed
境界判定は各候補につき最大8点だけ参照します。広い真内部を毎回全面再計算する方式にはしていません。1920×1080/標準の代表内部解像度では、純粋な疎seedだけなら stage 1/2/3 はそれぞれ約98,648 / 24,662 / 6,195画素です。10^8 の場合、疎seed部分の合計は約0.220B sample-iterationsで、一次描画最悪値約1.049Bの約21%です。境界画素はこれに追加されますが、batch上限と休止でGPU占有を制限します。
### 数値エンジン
高速モードの一次表示は従来のFast経路ですが、**アイドル精密化は高速モードでも guarded Deep を使用**します。精密化用reference bufferは通常描画の `deepCtx / fastCtx` と分離しているため、精密化後もv24.2.18のpan reference再利用を壊しません。
これにより、一次描画で `INTERIOR_LIKELY` だった点だけを保守的に再評価します。精密化シェーダーは実行直前にも対象がまだ `INTERIOR_LIKELY` か確認するため、既存の `ESCAPED` / `INTERIOR_PROVEN` を上書きしません。
### 反復ターゲット
標準モードでは概ね次の3段階です。
| zoom | 一次 | stage 1 | stage 2 | stage 3 |
|---:|---:|---:|---:|---:|
| 10^6 | 611 | 1222 | 2444 | 3000 |
| 10^8 | 667 | 1334 | 2668 | 3600 |
| 10^12 | 772 | 1544 | 3088 | 4800 |
| 10^20 | 963 | 1926 | 3852 | 7200 |
### 1 GPU batch の上限
標準モードの補足精密化は **1.8 million sample-iterations / batch 以下**に丸めます。
例: `10^8`
- 1334 iter: 1344 pixels / batch → 1,792,896 sample-iterations
- 2668 iter: 640 pixels / batch → 1,707,520
- 3600 iter: 448 pixels / batch → 1,612,800
ユーザー操作が入ると `state.token` が変わり、次batchへ進む前に中断します。また一定時間ごとにGPUを休ませます。
## 品質の単調性
補足精密化前の画像は v24.2.18 と同じです。
精密化は `FIELD_INTERIOR_LIKELY` のみを対象とし、既に確定した画素には触れません。さらに再着色時も一次描画の `baseIter` を色周期正規化に使うため、精密化によって既存の外部色が一斉に変化することを避けています。
## 色操作
v24.2.18 のズーム相対色周期と対数スライダーを維持しています。`色を自動変化` の速度のみ、要求どおり v24.2.18 の **1/10** にしています。
## fallback
JavaScript fallback は v24.2.18 と SHA-256一致です。疑似等高線・縞模様は追加していません。
## 検査
```bash
npm test
npm run build
```
`tests/v24-baseline-idle-refinement-model.mjs` が以下を検査します。
- 一次WGSL 4本の v24.2.18 SHA-256一致
- fallback の v24.2.18 SHA-256一致
- `maxIter()` の基準線維持
- 精密化WGSLの遅延コンパイル
- 全meta readback不使用
- 16 byte queue統計readback
- 既存確定画素を上書きしない契約
- 各倍率で1batchが予算を超えないこと
実GPUのfpsやdevice-lost有無は、このコンテナでWebGPUが初期化できない場合は保証できません。静的・CPUモデル結果と実機測定は区別します。
## 数値コア
v24.2.54から変更したproduction WGSLはFAST_PERTURB_WGSLのみ。通常 `unknownOnly=0` の計算式・perturbation recurrenceは変更していない。追加分はcoverage repair用のearly guardである。

142
docs/VALIDATION_REPORT.md
View file

@ -1,101 +1,75 @@
# v24.2.26 検査報告
# Validation Report — v24.2.55
## 結論
## 1. JavaScript / bundle syntax
- kernel bundle: PASS
- application bundle: PASS
v24.2.26 は v24.2.18 を一次描画の基準線として復元し、黒い `INTERIOR_LIKELY` の追加判定だけを一次表示後のアイドルGPU処理として分離した。
## 2. production kernel差分
v24.2.54とのSHA-256比較。
一次描画の品質・数値計算量を変えないことを、ソースハッシュ・式・静的契約で確認した。実GPU上のfps/device-lostは、この実行環境でWebGPU/EGLを初期化できなかったため未測定である。
変更:
- `version`
- `FAST_PERTURB_WGSL`
## 一次描画の同一性
不変:
- Direct
- Accurate seed / DS direct
- Deep perturbation
- Deep correction
- COLOR
- PRESENT shader本体
- BLA candidate / production frame kernels
v24.2.18 と SHA-256 が一致する本番WGSL:
FAST_PERTURBの通常recurrenceは不変。`unknownOnly=2` 時だけzero-sentinel pixelを再計算するearly guardを追加。
| Shader | SHA-256 |
|---|---|
| DIRECT_F32_WGSL | `59301bf0c5ba3dda4a4055335b32d4a3f84a21991be30f8efc74deb5a5f11ccf` |
| FAST_PERTURB_WGSL | `03b45713b1bbb7b56e18bd8fdf0f2d8161d7ed25adf02482b41c1038dc16e3b8` |
| DEEP_PERTURB_WGSL | `2865a015d5c1a9b459085b7044e23563fcc5f0eec5362634249b6604a47e660a` |
| COLOR_WGSL | `cccac7bfb69c64093c46c3468ff9d685d680ba3a88de0d1ea57168d91a067acf` |
## 3. coverage contract
PASS:
- tiled numeric開始時にmeta/smoothをzero clear
- color前にbaseline FAST coverage repair
- coverage repairはreason=0 UNKNOWNだけをiteration
- 既計算pixelはearly return
JavaScript fallback も v24.2.18 と一致:
これにより、strip/tile未書込が発生してもrectangular zero-metadata holeをそのままpublishしない。
`689a6f56aedd416b5e512b17ab6a3ddebcf7c73494e0a8a600ce74a06d8073a2`
## 4. temporal fill / history
PASS:
- history利用範囲をstable reprojectionと同じ `2.25 / 0.45` へ統一
- numeric recovery pending/running時はstable historyへcommitしない
- recolor経路も `numericFrameComplete()` を満たさない限りhistoryへcommitしない
`maxIter()` は v24.2.18 と同じ:
## 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へ退避
`baseIter + floor(70*sqrt(zoomExp) + 15*zoomExp)`
## 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
補足精密化用WGSLは本番pipeline初期化ではコンパイルしない。一次表示完了後、320msのアイドル遅延後に必要な場合だけ遅延コンパイルする。
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
1920×1080 CSS / 標準負荷では内部描画を約1672×941 = 1,573,352画素とする。
productionではCPU per-view validationを外したが、64-point GPU probeとBLA pixel fallback契約は維持。
| zoom | 一次iter | 一次最悪 sample-iterations |
|---:|---:|---:|
| 10^6 | 611 | 961,318,072 |
| 10^8 | 667 | 1,049,425,784 |
| 10^12 | 772 | 1,214,627,744 |
| 10^20 | 963 | 1,515,137,976 |
## 8. browser smoke
Chromiumでlocalhostからロード:
- page JavaScript error: 0
- kernelVersion: `24.2.55-no-black-hole-async-recovery`
これはv24.2.18と同一。
このコンテナでは当該起動条件でWebGPU adapterを取得できなかったため、canvasを含む実端末フレーム時間は未測定。
標準モードのアイドル補足精密化は1バッチ1,800,000 sample-iterations以下に制限する。
## 9. release layout
- executable HTML: `index.html` の1本のみ
- `index.baseline-*.html`: なし
| zoom | refine iter | pixels/batch | 最悪 sample-iterations |
|---:|---:|---:|---:|
| 10^6 | 1222 | 1472 | 1,798,784 |
| 10^6 | 2444 | 704 | 1,720,576 |
| 10^6 | 3000 | 576 | 1,728,000 |
| 10^8 | 1334 | 1344 | 1,792,896 |
| 10^8 | 2668 | 640 | 1,707,520 |
| 10^8 | 3600 | 448 | 1,612,800 |
| 10^12 | 1544 | 1152 | 1,778,688 |
| 10^12 | 3088 | 576 | 1,778,688 |
| 10^12 | 4800 | 320 | 1,536,000 |
| 10^20 | 1926 | 896 | 1,725,696 |
| 10^20 | 3852 | 448 | 1,725,696 |
| 10^20 | 7200 | 192 | 1,382,400 |
10^8 の最初のrefine batchは一次描画最悪値の約0.171%。1バッチを巨大dispatchにしないことを優先している。
## 候補量モデル
代表解像度で境界判定以外の疎seedだけを数えると:
- stride 4: 約98,648画素
- stride 8: 約24,662画素
- stride 16: 約6,195画素
10^8 でこの疎seed全部を3段階処理した場合は約0.220B sample-iterationsで、一次描画最悪値1.049Bの約20.9%。実際には境界候補も加わるが、処理は小batchに分割し、一定時間ごとに休止し、ユーザー操作で中止する。
## 品質契約
- 一次画像はv24.2.18と同じ本番シェーダーで生成する。
- refinement対象は `FIELD_INTERIOR_LIKELY` のみ。
- refinement shaderは実行時にも対象classを再確認する。
- `FIELD_ESCAPED` / `FIELD_INTERIOR_PROVEN` は上書きしない。
- 高速モードのidle refinementもguarded Deepを使う。
- refinement用reference bufferを通常描画の `deepCtx / fastCtx` と分離し、pan reference reuseを壊さない。
- 再着色は一次描画の色周期スケールを維持し、既存の外部色を一斉に動かさない。
- JavaScript fallbackに疑似等高線を追加しない。
## 自動テスト
最終ソースに対して以下を実行し、すべてPASS:
```text
npm test -> RC=0
npm run build -> RC=0
npm test -> RC=0 (build後再検査)
node --check script.js -> PASS
node --check gpu-kernels.js -> PASS
```
専用モデル `tests/v24-baseline-idle-refinement-model.mjs` もPASSし、上記ハッシュ、batch上限、readback契約、品質単調性を検査した。
## 実WebGPU検査の制約
このコンテナのChromiumではGPUプロセスがEGL/ANGLE初期化に失敗したため、実WebGPUのfps・device lost試験は完了できなかった。観測した主な失敗は `EGL_NOT_INITIALIZED` / `SwANGLE failed` 系である。
したがって「実機でv24.2.18より何%速い」という主張はしない。保証しているのは一次描画経路の構造的な基準線復元と、idle refinementのbatch仕事量上限である。
## 残る性能課題
BLA probeがOFFになるSeahorse/Misiurewicz型viewではbaseline FASTのpixel-iteration量が依然支配的。v24.2.55はこのケースのCPU prepと同期補修待ちを削るが、primary perturbation本体を別アルゴリズムで高速化する変更ではない。