8.2 性能分析与优化实践

8.2 性能分析与优化实践

本节摘要：优化的第一原则是测量先于动手。本节布置 CPU 与 GPU 两侧的测点（含时间戳查询的完整用法），然后按「提交成本、绑定成本、带宽与同步」三条主线给出排障顺序，把第 2 到第 6 章埋下的性能知识点收拢成一张实操清单。

深夜的性能值班室里，一位同事盯着掉帧的回放说「把阴影精度降一档试试」。这是所有性能问题的经典起点：一个没有测量支撑的直觉。Vulkan 给了开发者足够的观测手段去验证直觉——本节的目标是让你在动任何一行「优化代码」之前，手里先有数据。

一、布测点：两侧时钟各就各位

CPU 侧的测点围绕帧循环的四个关节：采集耗时、录制耗时、提交耗时、呈现等待（vkQueuePresentKHR 在 FIFO 模式下的阻塞时长，是最容易被忽略的「GPU 反压 CPU」信号）。普通的性能采样器（Tracy、内置计时）即可覆盖。

GPU 侧的正牌工具是时间戳查询。流程四步：建查询池、命令里埋时间戳、回读、按设备周期换算：

// 建池：每帧两个测点（段开始与段结束），double 型容量
VkQueryPoolCreateInfo qi = {VK_STRUCTURE_TYPE_QUERY_POOL_CREATE_INFO};
qi.queryType  = VK_QUERY_TYPE_TIMESTAMP;
qi.queryCount = 2 * queriesPerFrame;
vkCreateQueryPool(device, &qi, NULL, &queryPool);

// 录制：在目标段落前后各埋一枚
vkCmdResetQueryPool(cmd, queryPool, 0, 2);
vkCmdWriteTimestamp(cmd, VK_PIPELINE_STAGE_TOP_OF_PIPE_BIT, queryPool, 0);
// ……本段命令……
vkCmdWriteTimestamp(cmd, VK_PIPELINE_STAGE_BOTTOM_OF_PIPE_BIT, queryPool, 1);

// 回读（确认执行完成后）：换算毫秒
float period = limits.timestampPeriod;   // 纳秒每刻度，物理设备属性里查
// vkGetQueryPoolResults 取回 uint64_t，耗时毫秒 = 差值 * period / 1e6
​

时间戳的读数语义要精确理解：它标记的是「该阶段掩码执行到的时刻」，两枚之间通常是段落耗时，但遇到队列空闲插入时读数会放大——与第三方分析器的时间线交叉验证是标准做法。厂商分析器（Nsight Graphics、RGP）能给出命令级时间线与占用率计数器，本节的时间戳适合留在程序里做常驻自观测，两者互补。

二、三条主线：按证据排障

GPU 分析器与自观测数据到手后，按三条主线排查，每条都有先兆特征与对策：

三条主线的排查顺序默认自上而下：先确认 CPU 没在拖后腿（提交），再看 GPU 段间切换（绑定），最后才是着色与带宽本身。大量「换着色器就能快」的错觉，根子在把第二三行的症状错记到渲染负载头上。

三、常青事：缓存与复用

两件与排障无关却永远值得做的投资。管线缓存持久化（4.2 的展开）：导出数据随安装包与版本走，冷启动装配时间能从秒级压到百毫秒级——注意缓存头含驱动指纹，跨驱动失效时要兜底重建。资源生命周期复用：暂存缓冲分块复用（3.3 案例）、命令缓冲缓存式录制（5.2 案例）、描述符集按帧回收再领（3.4）——显式 API 的分配昂贵是常态，把「每次都办新证」改造成「循环用旧证」，是贯穿全册的一条暗线。

四、案例：一次瓶颈错位的完整排障

背景：某体素编辑器在场景规模上万块后帧率腰斩。直觉判断是体素三角形太多，第一反应方案是减面与降网格精度。

操作：按流程先布测点。GPU 时间戳显示「几何段」耗时只有两毫秒，与直觉严重不符；提交侧测点随即暴露真凶——CPU 每帧为上万块体素各自录制命令并单独提交，单帧提交调用数过万，CPU 帧时间被吃掉七成。对策落在第一主线：体素按区块合并命令、静态区块改缓存式录制（内容不变时复用上帧次级缓冲）、动态区块改间接绘制按块分发。

结果：CPU 帧时间回落到预算内，帧率恢复且几何精度一档未降。团队复盘时的结论是：测量 fifteen 分钟定位的问题，直觉方案（减面）既伤画质又不会有效果。

解读：这案子的方法论价值在于「先证伪直觉」：瓶颈错位在显式 API 里比老 API 更常见，因为显式性把隐藏成本（这里是提交与录制）明码标到了开发者账上——账单变清晰了，但多数人的注意力还停留在着色与三角形上。测量十几分钟定位的问题，直觉方案（减面）既伤画质又不会有效果。

变式：真实瓶颈常常复合（提交端与大带宽并存），排障要按测量收益排序逐项处理，每改一项复测一轮——「一次只改一处、每处有前后数据」是性能工作的基本纪律。

五、进阶观测：厂商计数器怎么读

时间戳回答「哪段慢」，厂商分析器的硬件计数器回答「为什么慢」。几类常用计数器的读法值得预学。占用率（occupancy）类指标反映活跃工作组的饱和程度：着色器段耗时高且占用率低，通常意味着分支发散或寄存器压力压低了并行度，优化方向是简化分支或降低每线程资源；占用率高仍慢，则是真算力不足，考虑减载或换算法。带宽类指标对比「实际吞吐与理论峰值」：远低于峰值说明访存模式不友好（采样局部性差、缓存抖动），贴着峰值则只能靠减少数据量（压缩格式、降采样）。管线阶段占比能识破「错位」——某段标称几何处理，计数器却显示大部分时间花在顶点取数，结论就从「减三角形」翻转成「改顶点布局」。

读计数器的一条纪律：任何单项指标都不构成结论，至少两项互证（如占用率加带宽）再下判断。厂商指标命名与口径不同，跨厂商对比时以相对变化为准——优化前后同机同项的差值，才是可写进结论的数据。

六、要点回顾

• 测量先于动手：CPU 四关节测点加 GPU 时间戳常驻，直觉未经数据确认不动代码。
• 时间戳会读：埋点、回读、按 timestampPeriod 换算，与第三方分析器交叉验证。
• 三主线顺序：提交、绑定、带宽与同步，每条有先兆特征与对策清单，自上而下排查。
• 两件常青事：管线缓存持久化、资源与工单的循环复用，是贯穿全册的暗线收口。
• 一次一处：复合瓶颈按收益排序逐项改，每项留下前后测量。