Chapter 127: Large Dataset Rendering

Large Dataset Rendering 讨论的是一帧图像怎样从远大于显存的数据集中稳定产生。这里的“大”同时覆盖文件体积、数据读取、层级选择、GPU buffer 更新、交互响应和画质退化这些因素。读完本章后，读者应能定位大数据渲染的主要约束，判断瓶颈来自数据规模、IO、显存、GPU 执行还是交互延迟，并能设计一条可复用的分块、LOD、缓存和质量降级路径。

本章使用一个贯穿材料：一个城市级三维点云与体数据混合场景。原始数据包含数十亿个采样点、若干局部体素块和少量矢量标注，用户在浏览器或桌面可视化窗口中进行平移、缩放、旋转和剖切。单机显存只能容纳当前视图附近的一小部分数据，CPU 内存也只能保存热区缓存，完整数据位于本地磁盘、局域网对象存储或远端服务中。这个材料覆盖了大数据渲染的关键路径：可见范围确定、层级选择、数据请求、解压上传、GPU 绘制和交互反馈。

大规模数据渲染的核心结论是：渲染器应把“完整数据集”转成“当前视图可见、当前交互所需、当前资源预算允许的一组数据块”。因此设计顺序应从数据空间划分开始，接着建立 Level of Detail，随后用 Out-of-Core 管理把缺失数据异步补入，再用压缩和传输策略控制带宽，最后用可观察指标确认系统在数据规模扩大时怎样降级。

这一章关心的是工程判断。文中的 tile、chunk、page、block 都表示可独立请求、缓存、解压、上传和渲染的数据单元；具体名称由数据格式和引擎约定决定。正文会固定使用“数据块”作为统一说法，在需要强调二维瓦片、三维体块或点云节点时再补充限定。

127.1 大规模数据集的挑战与约束

大规模数据集首先改变的是渲染器的输入边界。普通模型渲染常把 mesh、texture 和 material 预先加载进内存，然后每帧根据相机状态提交 draw call。大数据渲染的输入集合会随相机、缩放级别、剖切平面、筛选条件和网络状态变化，渲染器每帧面对的是一个“可见数据候选集”，然后从候选集中选出可以进入 GPU 的部分。

在贯穿材料中，城市级点云可能占用数百 GB 到数 TB。当前画面只显示一个街区，但用户快速缩放时，可见范围会从单栋建筑扩展到整座城市。这个动作会同时扩大空间覆盖范围、降低单点屏幕贡献、改变需要的 LOD 层级，并触发大量缓存命中或缺失。渲染器的目标是让屏幕上的每个像素得到足够信息，同时让交互帧率维持在可接受范围；完整点集只作为离线数据来源。

数据规模进入渲染管线的方式

数据规模会沿着五条路径进入管线。第一条是存储路径，原始数据在磁盘或远端服务中，需要索引、范围查询和批量读取。第二条是 CPU 路径，数据块需要解析、解压、筛选、重排和生成上传命令。第三条是 GPU 资源路径，点、体素、颜色、属性、索引和层级元数据需要映射到 buffer、texture 或 storage resource。第四条是 shader 路径，shader 需要根据当前 LOD、属性精度和可见状态计算颜色、透明度、点大小或采样值。第五条是交互路径，用户输入产生新视图后，系统需要在数据尚未完整到达时给出稳定反馈。

这个路径可以用一个帧内数据流表示。图中的“缺失”是大数据渲染的常态，也是调度器每帧都要处理的状态。

这张图的关键点是反馈回路。渲染器不能把数据读取视为一次性前置工作，因为相机状态会持续改变。每次交互都会改变 Query 的结果，Select 必须在资源预算内重新选择数据块。Feedback 提供的证据包括帧时间、缺失块数量、当前分辨率、点密度、tile cache 命中率和用户可见的模糊区域。

约束需要按资源层级拆开

大数据渲染的约束来自多个层级，排查时应先把症状放到正确层级。画面出现空洞可能来自数据块尚未读取，也可能来自 LOD 选择过低、GPU buffer 容量不足、透明排序错误或 shader 丢弃规则过严。帧率下降可能来自 GPU 顶点吞吐，也可能来自 CPU 解压、网络等待、命令提交过多或缓存抖动。

约束层级	典型资源	可观察症状	常用证据
数据规模	原始文件、空间索引、层级节点	首次进入区域时加载慢	数据块数量、请求队列长度、范围查询耗时
IO 带宽	磁盘、网络、对象存储	画面逐步清晰，等待时间长	每秒读取字节、请求延迟、并发请求数
CPU 处理	解压、解析、筛选、重排	主线程卡顿，上传批次延后	解压耗时、worker 占用、上传队列积压
GPU memory	buffer、texture、tile cache	频繁淘汰，旧区域回看重新加载	resident bytes、eviction 次数、缓存命中率
GPU 执行	draw、shader、采样、blend	数据已到达但帧时间过高	GPU timestamp、pass 时间、点数、采样次数
交互体验	camera、selection、剖切、筛选	拖动时延迟、闪烁、细节跳变	input-to-frame latency、降级状态、稳定帧数

这组维度给出第一条判断顺序：先确认当前帧究竟缺数据、缺预算还是缺吞吐。缺数据时看请求队列和缓存命中；缺预算时看显存占用和淘汰；缺吞吐时看 draw 数量、shader 成本和采样量。把这些层级拆开后，后续的分块、LOD、Out-of-Core 和压缩策略才有明确对象。

视觉正确性受数据调度影响

大数据渲染中的画质问题经常来自调度策略。点云在远距离可以用低密度节点表示，近距离需要更高密度节点补充。体数据在快速拖动时可以先显示低分辨率体块，停止后再补充高分辨率体块。矢量标注需要保持屏幕可读性，它的加载优先级可能高于远处点云细节。

因此“正确画面”同时由 shader 公式和当前帧已到达的数据块决定。渲染器应把每个像素的来源记录为可解释状态：来自高层级节点、来自临时低清缓存、来自占位颜色，还是来自缺失区域。这个状态会直接服务 127.5 中的质量降级评估。

127.2 分块与 Level of Detail 策略

分块把不可整体处理的数据集拆成可独立调度的单元，Level of Detail 负责在不同视图尺度下选择不同细节。两者需要一起设计：只有分块没有层级，会让远景需要加载过多数据；只有层级没有合适分块，会让局部更新和缓存淘汰缺乏最小单位。

在城市级点云中，一个数据块可以对应八叉树节点、二维地图瓦片、体数据 brick 或空间网格 cell。每个数据块需要包含空间包围体、数据范围、属性摘要、字节大小、压缩格式、层级关系和渲染入口。LOD 节点则回答当前相机下这个块需要多细：远处街区使用上层采样点，近处建筑立面使用更细节点，屏幕外节点直接跳过。

分块粒度由调度成本和视觉误差共同决定

数据块过大时，单次读取和上传延迟会变长，用户进入新区域时容易看到整块空缺。数据块过小时，请求数、元数据数量、绑定次数和调度开销会上升，CPU 可能把大量时间用于管理小块。合理粒度应让一个数据块在当前平台上可快速读取、解压和上传，同时让它在屏幕上的误差可以被 LOD 规则描述。

常用判断可以落到四个量。第一是字节大小，单块压缩后大小应便于批量传输和缓存淘汰。第二是屏幕覆盖，单块投影到屏幕的范围应能支持局部更新。第三是几何误差，低层级替代高层级时的最大偏差要能估计。第四是交互频率，用户拖动时进入和离开的块数量应可控。

分块对象	适用数据	关键元数据	主要风险
八叉树节点	点云、稀疏体素、三维场	包围盒、点数、误差、子节点	深层节点过多导致调度开销上升
二维瓦片	地图、地形纹理、影像	tile 坐标、级别、覆盖范围	倾斜视角下屏幕误差估计偏粗
三维 brick	体数据、医学或流场体	体素范围、值域、空块标记	边界采样和过滤需要邻域数据
meshlet / cluster	大 mesh、扫描重建模型	cone、bounds、index range	材质和属性拆分会增加批次

分块设计完成后，每个块都应能独立回答“我是否可见、我有多重要、我需要多少资源、我可以被哪个低层级块替代”。如果一个块无法回答这些问题，它就难以进入可预测的调度系统。

LOD 选择应以屏幕误差为主线

LOD 的核心输入是当前视图中某个数据块对屏幕的贡献。对于点云，可以用节点包围盒的屏幕尺寸、点间距和目标像素密度估计是否需要展开子节点。对于体数据，可以用 brick 在屏幕上的大小、采样步长和值域变化估计分辨率需求。对于地形和大 mesh，可以用几何误差投影到屏幕后的像素误差决定层级。

一个可复用的 LOD 判断顺序是：先剔除屏幕外块，再估计屏幕覆盖，再比较误差阈值，然后检查资源预算，最后按重要性排序请求缺失块。这个顺序把视觉目标和资源限制放在同一条线上。只按距离选 LOD 会在长焦相机、宽屏视角和近距离斜视场景中产生错误；屏幕误差能更直接反映用户看到的变化。

下面的简化伪代码说明调度器每帧如何选择块。它展示逻辑关系，具体工程中需要把请求队列、优先级和 GPU 资源更新拆到任务系统中执行。

def select_visible_blocks(camera, root_nodes, budget):
    selected = []
    candidates = list(root_nodes)

    while candidates and budget.has_room():
        node = candidates.pop()
        if node.outside_frustum(camera):
            continue

        screen_error = node.projected_error(camera)
        if screen_error > budget.error_threshold and node.children_available():
            candidates.extend(node.children)
            continue

        selected.append(node)
        budget.reserve(node.estimated_bytes, node.estimated_draw_cost)

    return sort_by_priority(selected, camera)

这段代码的重点是 projected_error 和 budget 同时参与选择。projected_error 把几何或采样误差转成屏幕像素语境，budget 把显存、draw 成本和解压队列容量纳入选择。调度器最终返回的 selected 集合就是本帧渲染器可以绑定的最小工作集。

层级切换需要稳定策略

LOD 切换会带来 pop、闪烁、点密度突变和纹理清晰度跳变。稳定策略通常包含三层。第一层是空间稳定，同一相机附近的选择结果在小幅移动时不要频繁翻转，可以使用 hysteresis 阈值或延迟替换。第二层是时间稳定，高层级块到达前继续显示父节点，子节点全部或部分就绪后再替换。第三层是视觉稳定，点云可以用 density normalization 调整点大小，体数据可以在不同分辨率 brick 之间做短时间混合。

贯穿材料中的城市点云在快速缩放时会经历父节点先显示、子节点陆续补齐、最终进入高密度模式的过程。这个过程如果没有稳定策略，用户会看到建筑表面像噪声一样跳动。稳定策略的目标是让画面从粗到细收敛，用户能感知加载进度，同时保持相机控制响应。

127.3 Out‑of‑Core 数据管理技术

Out‑of‑Core 数据管理指工作集大于可用内存或显存时，系统通过索引、缓存、异步请求和淘汰策略让当前帧只访问必要部分。它解决的问题是资源常驻容量有限，而数据集完整规模持续超过容量。对渲染器来说，Out‑of‑Core 是一套跨 CPU、GPU 和 IO 的数据生命周期管理，文件读取只是其中一个环节。

在贯穿材料中，完整点云和体数据无法全部进入 GPU memory。Out‑of‑Core 管理器需要维护三个集合：已在 GPU 中可绘制的 resident blocks，已在 CPU 内存中解压但尚未上传的 staging blocks，以及已经请求但尚未完成的 pending blocks。每个集合都需要优先级、状态和失效规则。

数据块生命周期是核心状态机

一个数据块从磁盘或网络进入画面，通常经历“未请求 → 请求中 → 已读取 → 已解压 → 已上传 → 可绘制 → 待淘汰”这些状态。每个状态都对应可观察证据。请求中可以看到 request id 和等待时间；已解压可以看到 CPU 内存字节数；已上传可以看到 GPU buffer offset 或 texture handle；可绘制可以在 frame capture 中看到绑定资源；待淘汰可以看到最近使用帧号和引用计数。

这个状态机让渲染器可以解释缺失画面。某个街区没有显示时，系统能够回答它停在 Pending、Loaded、Decoded 还是 Resident 之前。不同状态对应不同修复方向：Pending 多说明 IO 或请求优先级不足；Loaded 积压说明解压或解析受限；Decoded 积压说明上传或 GPU 资源分配受限；Resident 多但 Drawable 少说明可见性、绑定或 pass 筛选存在问题。

缓存策略要服务相机运动

Out‑of‑Core 缓存的命中率取决于相机运动模式。用户沿街道平移时，前方相邻块应提前请求；用户绕建筑旋转时，当前建筑附近的多角度数据应保留；用户从城市远景快速放大到街区时，父级节点和目标区域子节点都需要较高优先级。缓存策略应把最近使用、屏幕重要性、运动预测和请求成本组合成优先级。

常见缓存层级可以分成四类。元数据缓存保存树结构、bounds、误差和值域摘要，体积较小，应尽量常驻。压缩数据缓存保存原始块字节，适合二次进入区域时减少网络或磁盘读取。解压缓存保存 CPU 可直接上传的数据，适合内存充足时降低 CPU 解压压力。GPU resident cache 保存可直接绘制的 buffer 或 texture，是最昂贵也最直接影响帧的缓存。

缓存层	保存内容	命中收益	淘汰依据
元数据缓存	层级、bounds、误差、值域	快速做可见性和 LOD 选择	数据集关闭或索引切换
压缩缓存	块的压缩字节	减少 IO 请求	读取成本、最近使用、磁盘空间
解压缓存	CPU 侧可上传数据	减少解压耗时	CPU 内存预算、上传优先级
GPU 缓存	buffer、texture、descriptor	直接进入绘制	显存预算、屏幕重要性、最近使用

这张表给出第二条判断顺序：当画面延迟来自数据缺失时，先看元数据是否常驻，再看压缩缓存命中，再看解压队列，最后看 GPU resident cache。很多性能问题表现为“加载慢”，实际瓶颈可能在四个缓存层中的任意一个。

异步请求与帧稳定性需要隔离

Out‑of‑Core 系统需要异步执行 IO、解压和上传，但当前帧的绘制列表应保持稳定。稳定做法是使用双缓冲或多版本 visible set：第 N 帧根据已有 resident blocks 生成可绘制列表，同时调度第 N+1 或后续帧可能需要的数据。新数据到达后进入待提交队列，在安全同步点更新 GPU 资源和绘制列表。

这种隔离能减少主线程卡顿。IO 完成时间不可预测，网络请求也可能乱序返回。渲染器应把“数据到达”转成事件，再由调度器决定它是否仍然对当前相机有价值。用户快速移开视角后，刚到达的数据块可以降级为缓存候选，等待后续优先级评估，再决定是否上传占用 GPU 预算。

失败情况需要可解释回退

Out‑of‑Core 系统在请求失败、网络波动、显存紧张或数据块损坏时，需要给出可解释回退。点云可以保留父节点；体数据可以保留低分辨率 brick；影像瓦片可以显示上一级 tile；矢量标注可以优先加载骨架数据。回退的重点是保持空间参考稳定，让用户知道当前看到的是低细节版本还是缺失版本。

在调试时，可以给每个块绘制状态颜色：绿色表示 resident，黄色表示 pending，蓝色表示父级替代，红色表示请求失败。这类 debug overlay 直接回答数据生命周期问题，比单独看帧率更有效。

127.4 数据压缩与快速传输方案

压缩和传输策略的目标是减少从存储到 GPU 的总成本。这里的总成本包括字节数、解压耗时、随机访问粒度、GPU 上传次数、shader 解码成本和画质损失。大数据渲染应同时评估压缩率、解压成本和随机访问开销；压缩率越高，解压和随机访问开销可能越大。合适方案要匹配数据类型、交互模式和平台资源。

在贯穿材料中，点云需要位置、颜色、强度、分类和时间戳等属性。体数据需要密度、温度或语义标签。矢量标注需要几何和文本。不同属性的压缩目标不同：位置需要控制几何误差，颜色需要控制视觉差异，分类标签需要保持离散值准确，时间戳和强度可以按查询需求选择是否加载。

压缩应按属性通道设计

点云位置通常适合块内量化。每个数据块保存局部包围盒，点的位置使用相对坐标和固定 bit 数表示。这样可以减少字节数，同时让误差被限制在块范围内。颜色可以使用常见纹理或属性压缩策略，强度和分类可以单独打包。属性通道拆开后，调度器可以按当前任务加载需要的通道。例如远景只加载位置和平均颜色，近景再加载强度或分类。

体数据常使用 brick 级压缩和值域摘要。空 brick 或低变化 brick 可以用更小表示，高变化区域保留更高精度。体渲染还需要注意边界采样，压缩块之间如果没有 padding 或邻域处理，三线性采样可能在边界出现接缝。这个问题属于数据格式和 shader 采样共同决定的画质问题。

数据类型	压缩目标	解码位置	判断重点
点云位置	降低几何字节数，控制屏幕误差	CPU 或 GPU shader	量化误差投影到屏幕后的像素影响
点云属性	按任务加载颜色、强度、分类	CPU、GPU vertex fetch 或 shader	属性是否参与当前着色和筛选
体数据 brick	减少空区和低变化区域字节	CPU、GPU compute 或采样 shader	边界过滤、值域误差、解压吞吐
影像瓦片	降低纹理传输和显存占用	GPU texture unit	格式支持、mipmap、采样质量
大 mesh cluster	压缩索引、法线、UV、顶点	CPU 或 GPU preprocessing	顶点误差、cache locality、draw 粒度

这张表强调压缩方案与渲染路径绑定。某种格式在离线存储中压缩率高，不代表它适合交互渲染。交互渲染更关心块级随机访问、可渐进解码、可部分上传和 GPU 端使用成本。

传输要以优先级和批处理组织

快速传输首先依赖请求优先级。当前屏幕中心、近距离、高误差、用户正在关注的选择对象，应获得更高优先级。屏幕边缘、远景、被遮挡或已有父级替代的块，可以延后。请求队列应定期根据新相机状态重排，过期请求应降级或取消。

其次是批处理。大量小请求会增加网络、文件系统和任务调度开销。调度器可以把相邻块合并请求，把同一 LOD 层的块批量读取，把多个小 GPU 上传合并到 staging buffer。批处理的边界要受交互延迟限制；批次过大时，首个可用块的到达时间会推迟。

第三是预取。预取根据相机速度、方向、缩放趋势和历史访问路径提前请求数据。城市点云的街道漫游很适合沿运动方向预取，体数据剖切适合沿剖切面移动方向预取。预取应受预算约束，预取占满队列会延迟当前可见块。

GPU 上传路径决定最终可用时间

数据从 CPU 到达 GPU 之后才可被绘制。上传路径通常包括 staging buffer、resource copy、barrier 或状态转换、descriptor 更新和 draw 列表更新。若每个小块都单独创建资源和 descriptor，CPU 提交开销会增长。更稳定的做法是使用大 buffer 分配器、texture array、atlas 或 bindless-style 资源表，把数据块映射到可复用资源槽位。

上传阶段需要记录两个时间：数据可上传时间和数据可绘制时间。前者表示 CPU 已经准备好字节，后者表示 GPU resource 更新完成并且渲染 pass 能够读取。两者之间的差距可以揭示资源创建、拷贝同步或 descriptor 更新的成本。RenderDoc、Nsight 或 Xcode GPU tools 可以作为可选观察入口，用来查看资源绑定、copy pass、barrier 和 draw call 是否符合预期；判断正确性仍以本章的数据状态和帧内路径为准。

渐进传输要配合画质标记

渐进传输允许画面先显示低成本版本，再补充高成本版本。点云可以先传父节点代表点，再传子节点完整点集；体数据可以先传低分辨率 brick，再传高分辨率 residual 或局部细节；影像可以先传低 mip，再传高 mip。渐进策略需要在画面中保持质量标记，系统应知道某个区域当前是粗略、过渡还是完整状态。

质量标记对用户体验和调试都关键。用户拖动时看到低清画面可以接受，停止后长时间停留在低清就说明请求、缓存或预算策略存在问题。质量标记还能防止系统把“低清但稳定”的画面误判为已完成画面。

127.5 Out-of-Core Scalability Evidence and Quality Degradation

Out-of-Core 系统的可扩展性应通过运行时证据评估，单纯打开更大的文件只说明加载入口可用。可扩展性应通过数据规模、IO 带宽、GPU memory、tile cache、交互延迟和质量降级共同评估。一个合格的大数据渲染器在数据规模扩大时，应表现出可解释的加载时间增长、可控的显存占用、稳定的交互响应和有边界的画质退化。

本节把前面四节收束成证据框架。证据框架的作用是回答三个问题：数据变大后系统在哪个环节受限；资源不足时画质怎样降级；降级是否仍然保留用户任务所需的信息。

可扩展性证据要覆盖六个维度

第一是数据规模。记录总字节数、块数量、层级深度、点数或体素数，并记录当前视图实际选择的块数量。大数据渲染关注工作集大小与总规模之间的关系。如果总规模增长十倍，而同一视图下工作集保持接近，说明分块和 LOD 发挥了作用。

第二是 IO 带宽。记录每秒读取字节、请求延迟、并发请求、失败率和过期请求数量。过期请求过多说明调度器跟不上交互变化，或者预取方向不匹配。带宽高但画面仍缺数据时，应继续检查解压和上传队列。

第三是 GPU memory。记录 resident bytes、buffer 或 texture 槽位占用、淘汰次数和重新加载次数。频繁在同一相机附近淘汰并重新加载，说明缓存预算或优先级策略与相机运动不匹配。

第四是 tile cache。记录元数据、压缩、解压和 GPU 缓存的命中率。只有总命中率不足以定位问题，需要分层记录。压缩缓存高命中但 GPU 缓存低命中，通常表示显存预算或上传策略受限；GPU 缓存高命中但帧率低，说明瓶颈转向 GPU 绘制或 shader。

第五是交互延迟。记录 input-to-frame latency、拖动期间帧时间、停止交互后达到目标质量的时间。大数据渲染常采用交互时降级、停止后补清的策略，因此需要同时看交互期和静止期。

第六是质量降级。记录屏幕误差、点密度、体数据采样步长、缺失区域面积、使用父节点替代的像素比例和用户任务成功率。质量降级应可量化，并与主观观察相互校验。

质量降级应按任务保真度排序

质量降级的目标是保留当前任务所需信息。浏览城市全景时，建筑轮廓、道路结构和大范围色彩比单个窗框细节更重要；检查建筑立面时，局部点密度和边缘细节更重要；分析体数据剖切时，阈值附近的值域变化更重要；选择矢量标注时，标签可读性和拾取准确性更重要。

因此降级策略应按任务排序。通用顺序可以写成：先降低远景细节，再降低屏幕边缘细节，再降低非关注属性，再降低采样频率，最后才显示缺失占位。对于当前选择对象、剖切面附近区域和用户正在操作的控件，系统应提高优先级。

降级对象	具体动作	保留的信息	可观察风险
点云远景	使用父节点、降低点密度	城市轮廓和空间关系	表面变稀、细边消失
体数据远区	使用低分辨率 brick	大尺度值域分布	边界变钝、局部峰值被平滑
属性通道	延迟加载强度、分类或时间属性	几何和基础颜色	筛选结果暂时不完整
影像纹理	先显示低 mip	颜色和大尺度纹理	文字或细线模糊
标注系统	优先保留选中和屏幕中心标签	交互语义	远处标签延迟出现

这张表把质量降级从“画面变差”变成可解释动作。每个动作都应说明保留了什么、损失了什么、何时恢复。恢复条件可以是相机停止、资源释放、请求完成或用户关注区域改变。

扩展测试要固定场景和指标

评估大数据渲染系统时，应固定测试场景。一个基本测试集可以包含远景总览、快速缩放、街区平移、局部旋转、体数据剖切和属性筛选。每个场景记录同一组指标：帧时间、请求队列、缓存命中、GPU resident bytes、可见块数量、屏幕误差和达到目标质量的时间。

扩展测试应逐步增加数据规模。例如从 1 倍城市子集扩展到 10 倍、50 倍和 100 倍，同时保持相机路径一致。理想结果是当前视图的 resident 工作集主要由屏幕覆盖和误差阈值决定，总数据规模增长只带来受控的索引和缓存压力。若 resident 工作集随总规模线性增长，说明分块索引、可见性筛选或 LOD 剪枝没有发挥作用。

最终判断顺序

完整的大数据渲染排查可以按固定顺序执行。先看当前视图选择了哪些块，确认可见性和 LOD 结果。再看这些块处于 Missing、Pending、Decoded、Resident 还是 Drawable 状态。接着看缓存命中和请求队列，判断数据是否按优先级到达。然后看 GPU memory 和上传队列，确认资源是否进入可绘制状态。最后看帧时间和画质指标，判断性能与降级是否符合当前任务。

这个顺序把本章主问题闭合起来：大数据渲染的关键动作是把数据集变成可选择、可请求、可缓存、可降级、可验证的帧内工作集。系统的成熟度体现在它能解释每一帧为什么显示这些数据、为什么缺少另一些数据，以及资源变化后画质会怎样退化。

最小自检任务

给定一个城市级点云可视化器：原始数据 800 GB，GPU memory 预算 4 GB，用户从城市远景快速缩放到单栋建筑。缩放过程中画面先显示低密度点，停止 3 秒后局部仍然有空洞，帧率稳定在 60 FPS。请判断主要问题更可能位于 GPU 执行、Out-of-Core 数据调度、压缩解码还是 LOD 误差设置，并给出排查顺序。

答案要点

主要问题应优先定位到 Out-of-Core 数据调度或数据块生命周期；GPU 执行可以放到较后位置复查。证据是帧率稳定在 60 FPS，说明当前可绘制工作集的 GPU 执行压力可控；局部空洞持续存在，说明目标区域需要的数据块没有按时进入 Drawable 状态。

排查顺序先看停止后目标建筑区域的块选择结果，确认 LOD 是否已经请求高密度子节点。若 LOD 仍停在父节点，检查屏幕误差阈值、相机投影误差和资源预算。若高密度子节点已经进入请求队列，继续看它们停在哪个状态：Pending 表示 IO 或请求优先级受限；Loaded 或 Decoded 积压表示解压、属性整理或上传受限；Resident 但未绘制表示绑定、pass 筛选或可见列表更新问题。

随后检查 tile cache。若目标区域反复淘汰并重新请求，应调整 GPU resident cache 的优先级和预算分配。若压缩数据已命中但解压队列积压，应优化解压并发、属性通道加载或块大小。若请求队列被远景预取占满，应提升屏幕中心、近距离和高误差块的优先级，并降低过期请求权重。

LOD 误差设置也需要复查，但它属于后续判断点。只有当目标区域没有产生高密度请求，或者系统认为父节点已经满足误差阈值时，才把问题转向 LOD 误差估计。压缩解码是中间候选，需要通过 Decoded 队列、worker 耗时和上传等待来确认。最终结论应由数据块状态、请求队列、缓存命中和目标质量恢复时间共同支撑。

本章知识点总结

• 工作集：大数据渲染应把完整数据集转成当前视图、交互目标和资源预算允许的帧内工作集。
• 分层约束：加载慢、空洞和卡顿需要分别放到 IO、CPU、GPU memory、GPU 执行和交互延迟中定位。
• 分块粒度：数据块大小应同时满足读取上传成本、屏幕覆盖、误差估计和缓存淘汰需求。
• LOD 主线：LOD 选择应以屏幕误差为主线，并结合资源预算和数据块优先级。
• 切换稳定：父子节点替换、点密度调整和低清到高清过渡需要保持时间稳定和空间稳定。
• 生命周期：Out-of-Core 管理的核心是跟踪数据块从 Missing 到 Drawable 再到 Evictable 的状态变化。
• 缓存分层：元数据、压缩数据、解压数据和 GPU resident cache 应分别记录命中率和淘汰原因。
• 异步隔离：IO、解压和上传可以异步执行，当前帧绘制列表需要在安全同步点更新。
• 属性压缩：位置、颜色、强度、分类和体数据值域应按通道设计压缩和加载策略。
• 传输优先级：屏幕中心、近距离、高误差和用户关注对象应获得更高请求优先级。
• 上传证据：数据可上传时间和可绘制时间之间的差距可以暴露资源创建、拷贝和绑定成本。
• 质量标记：渐进渲染需要记录区域处于粗略、过渡还是完整状态，才能解释画质恢复过程。
• 扩展证据：可扩展性应同时检查数据规模、IO 带宽、GPU memory、tile cache、交互延迟和质量降级。
• 任务保真：质量降级应按当前任务保留关键视觉信息，并明确损失内容和恢复条件。
• 排查顺序：先看块选择和生命周期，再看缓存与请求，接着看 GPU 资源，最后看帧时间和画质指标。