geopro/docs/superpowers/plans/poc-results-trackB.md

95 lines
4.6 KiB
Markdown
Raw Permalink Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

# Track B 总验收实测结果build-stream 多线合并流式建体)
工具:`tools/gpr_poc`CLI子命令 `build-stream`
执行机Windows 11MSVCVS18 Community+ NinjaRelease/O2开发机RTX 3060 Laptop GPU 旁)。
日期2026-06-23。
整条流式链路B1→B5 成果在 B6 串起来):
`assembleGprSurveySlab道窗口→ sampleGprPoint结构化插值→ StreamingVolumeWriter增量 zlib 写 brick→ buildPyramidStreaming从盘 brick 逐级降采样)→ WholeVolumeSource(load)`
> Track B 的核心命题:把建体管线改成沿 X 分段slab流式逐段读道→插值→写 brick→释放
> 使建「20 线合并大体」的峰值内存**有界、不随线数增长**、无 OOM且产物可被 `load` 读回。
> 对比基线:旧 double-survey 非流式方案,单线装配峰值 ≈4.2 GB20 线 ≈84 GB → 装配阶段必然 OOM。
---
## 1. 验收命令
```
gpr_poc build-stream "D:\Downloads\明星路" --cellXY 0.2 --cellZ 0.05 --out <storeDir> --levels 2
gpr_poc load <storeDir>
```
- 合并方式:**沿 X 顺序排列**(退路近似)——各线按 brick 对齐的 X 偏移依次拼入一个连续 store。
真实 RTK 几何拼接(按各线实际平面坐标拼成路网大体)留 **Track D**
- 量化 scale/offset **全局一致**:先扫一遍全部 20 线得全局 min/max流式下不能每 slab 各算),
再以全局值域逐线逐 slab 写 brick。
---
## 2. build-stream 实测指标20 线合并大体cellXY=0.2cellZ=0.05levels=2
| 指标 | 值 |
|------|-----|
| 合并测线数 | **20** |
| 合并体维度nx×ny×nz | **156544 × 8 × 82** |
| 体素数 | **102,692,864**≈1.03 亿) |
| 原始体积int16进显存判据 | **195.871 MB** |
| 落盘 data.bin含金字塔各级 | **105.422 MB** |
| 压缩比(原始/落盘) | **1.858×** |
| 扫全局量化区间耗时 | **181,288 ms**(一次性读全 14 GB 原始道) |
| 建体(流式 slab→写 brick耗时 | **89,927 ms** |
| 流式金字塔耗时 | **6,972 ms** |
| build-stream 端到端墙钟 | **278,788 ms≈4.6 min** |
| **峰值内存** | **246.164 MB** |
### 峰值内存全程稳定(核心结论证据)
20 线全程峰值内存稳在 **≈246 MB**245.973 MB → 246.164 MB**不随合并线数增长**
| 阶段 | 峰值内存 |
|------|----------|
| 扫全局量化 / 起始线 | 245.973 MB |
| 第 20 线写入完成 | 246.164 MB |
即流式建体的峰值内存**有界**——只随单个 slab + 一行 brick 的工作集,与合并总量(线数/体素数)无关。
对比旧 double-survey 非流式方案 20 线需 ≈84 GB本方案以 246 MB 建出 1 亿体素的合并大体,**无 OOM**。
---
## 3. load 实测指标 —— 产物可读 ✓
命令:`gpr_poc load <storeDir>`
| 指标 | 值 |
|------|-----|
| 加载耗时 | **1,756 ms** |
| 整卷维度 | **156544 × 8 × 82** |
| 峰值内存 | **214.55 MB** |
流式产出的合并大体 store 可被 `WholeVolumeSource` 完整加载、维度一致、**产物可读**。
---
## 4. Track B 总验收结论
-**峰值内存有界、与总量无关**20 线合并大体建体全程峰值稳在 ≈246 MB
245.973→246.164),不随线数增长。这是 Track B 的核心目标,达成。
-**无 OOM**:旧非流式方案 20 线 ≈84 GB 必 OOM流式方案 246 MB 即建出 1 亿体素合并体。
-**产物可读**`load` 在 1,756 ms 内读回维度一致156544×8×82峰值 214.55 MB。
-**压缩与落盘正常**:原始 195.871 MB → data.bin 105.422 MB含金字塔各级压缩比 1.858×。
### 已知约束 / 留待后续
1. **扫全局量化 181 s 是「读全 14 GB 原始道」的 I/O 开销**——为保证量化 scale/offset
全局一致必须先全扫一遍 min/max。可后续优化如复用建体阶段的单遍读、或用头估值域本次不做。
2. **合并几何用退路近似(沿 X 顺序排列brick 对齐)**——非真实路网平面几何。
真实 RTK 几何拼接(按各线实际平面坐标拼成路网大体)留 **Track D**
3. **最低配未验**仅在本机RTX 3060 Laptop 开发机)实测;最低配机器内存/磁盘表现待补测。
### 与 Track C 的衔接
Track B 已证「大体能建246 MB 有界)+ 能读1.76 s 加载」。Track C 在此大 store 上做
视野自适应 LOD 体绘制(视锥裁剪+视距选层 → 视野区域单纹理重组 → 平滑切换+后台预取),
解决 POC-B §4 记录的「整卷 X 维超 GL 单轴纹理上限16384」问题。