68 lines
4.8 KiB
Markdown
68 lines
4.8 KiB
Markdown
# Task 12b 报告：SetPartitions 单 mapper fps 去风险探针
|
||
|
||
## 状态
|
||
完成（探针真实跑出，结论：渲出但未达交互级）。
|
||
|
||
## 实测环境与数据
|
||
- store（9c/12 同款单线全分辨率整卷）：`D:\Git\lanbingtech\geopro\build\tmp\gpr_store_B_001`
|
||
- 整卷维度：44476 × 29 × 162 = 208,948,248 体素，417,896,496 B（398.5 MB，VTK_SHORT）
|
||
- 离屏渲染（vtkRenderWindow SetOffScreenRenderingOn），硬件加速 OpenGL（offscreen-smoke 闸门 OK）。
|
||
|
||
## 实现要点（tools/gpr_poc/main.cpp 新增 `renderC-partitioned` 子命令）
|
||
- WholeVolumeSource 重组**整卷单个** vtkImageData（不预切块）。
|
||
- 关键：`vtkGPUVolumeRayCastMapper` 抽象基类**无** `SetPartitions`；该 API 在 OpenGL 具体实现
|
||
`vtkOpenGLGPUVolumeRayCastMapper`（工厂默认产物）上。故直接建该具体类，
|
||
`SetInputData(整卷)` + `SetPartitions(ceil(nx/16384),1,1)`。
|
||
- 分区数：沿线 44476 → `ceil(44476/16384)=3`（每区 ~14826 ≤16384）；ny=29、nz=162 → 1。
|
||
实测 `SetPartitions(3,1,1)`。
|
||
- 量化域传函复用现有 `makeI16VolumeProperty`（qmin/qmax、kBlank 透明、q.toPhys 反查 ColorScale）。
|
||
- 双闸（同 9c，绝不把空纹理假帧率当性能）：
|
||
① CapturingOutputWindow 捕获 3D 纹理维度错误；
|
||
② 真实回读像素统计非背景像素。
|
||
- 相机修正：整卷极扁长（44476:29:162），首版用 `ResetCamera()` 全体 + 仅取末帧像素时，
|
||
末帧恰好边缘视角 → 误报“非空像素=0”。修正为：以 mapper 包围盒定向 + 抬高/旋转视角让薄维度可见，
|
||
且旋转扫描中**多帧采样非背景像素取最大值**（区分“真渲不出”与“采样时机不巧”）。修正后稳定渲出。
|
||
|
||
## 核心结论：SetPartitions 单 mapper 是否真渲出 + fps + 内存 + 分区数
|
||
- **分区数**：SetPartitions(3, 1, 1)。
|
||
- **是否真渲出**：**是**。无纹理维度错误（SetPartitions 成功绕过 GL_MAX_3D_TEXTURE_SIZE=16384 纹理墙），
|
||
真实回读非背景像素 1264（非空），一个 mapper 一次 ray cast。
|
||
- **体绘制 fps**：**~8.8 ~ 11 fps**（多次实测 8.84 / 10.95 / 10.59，落在 8.8–11 区间）。
|
||
- **峰值进程内存**：~556 ~ 653 MB（整卷 398.5 MB 常驻 + 渲染开销）。
|
||
|
||
## 对照表
|
||
| 路径 | 是否渲出 | fps |
|
||
|---|---|---|
|
||
| renderB 整卷单 SmartVolumeMapper | INVALID（纹理墙，沿线 44476>16384） | — |
|
||
| renderC MultiBlock（每块一 mapper） | 渲出 | 9.5 静态 / 1.45 换页 |
|
||
| **renderC-partitioned 单 mapper SetPartitions** | **渲出** | **~8.8–11（静态整卷）** |
|
||
|
||
## 是否达交互级
|
||
**否**。目标 ≥15~30 fps，实测 8.8–11 fps，低于交互级下限。
|
||
|
||
## 判据落点
|
||
- “对的架构”（单 mapper + SetPartitions）**确实绕过了纹理墙、确实把全分辨率整卷一次性渲出**——
|
||
这点比 9c（INVALID）与 12（每块一 mapper）都更干净，证明架构方向正确。
|
||
- 但**纯 GPU ray cast 静态整卷 fps 仍只有 ~9–11**，与 renderC MultiBlock 的 9.5 静态 **基本同档**，
|
||
未拉开差距、未到交互级。即：**“每块一 mapper”不是 9.5fps 的主要元凶；瓶颈在 208M 体素全分辨率
|
||
整卷的 ray cast 本身**（采样量 + 显存带宽），单 mapper 分区并不能把它变快。
|
||
- 结论：**VTK 这条路（整卷全分辨率体绘制）的交互级天花板在本数据上已暴露**。要到交互级，
|
||
production C 必须靠 LOD/降采样/核外换块（动态分辨率），而非寄望“单 mapper 分区”本身提速。
|
||
brief 判据的“仍不到 → 评估 OpenVDS/自建 GL”一支成立。
|
||
|
||
## concerns
|
||
1. **fps 受相机框选与视图影响**：8.8–11 的波动主要来自每帧旋转中视线穿过体的采样深度差异；
|
||
该数为“静态整卷、绕轴旋转”口径，已剔除换页/解压（不像 renderC 动态 1.45 含 update）。
|
||
作为“单 mapper 分区静态整卷 fps 天花板”是诚实的，但生产中真实 fps 还会被交互缩放/平移影响。
|
||
2. **首版“空渲染”教训已修正**：极扁长体 + 末帧单采样会假报空；现多帧取最大 + 视角抬高，已稳定非空。
|
||
报告口径据此可信。
|
||
3. **本探针只验静态整卷**（遵 YAGNI，未做 LOD/换块/后台解压）。production C 的动态分辨率方案
|
||
还需单独验证其在“降采样后”能否到交互级——这是下一根要验的链子，不在本探针范围。
|
||
4. SetPartitions 在 9.6 属 `vtkOpenGLGPUVolumeRayCastMapper`（非抽象基类）；若后续 VTK 升级
|
||
该 API 位置变动需留意。
|
||
|
||
## 交付物
|
||
- 代码：`tools/gpr_poc/main.cpp`（新增 `renderC-partitioned` 子命令）。
|
||
- 结果：`docs/superpowers/plans/poc-results-C.md`（含对照表与判据结论）。
|
||
- 报告：本文件 `.superpowers/sdd/task-12b-report.md`。
|