中EN
概念页

渲染瓶颈定位与性能度量

Bottleneck Location & Performance Measurement

渲染管线中最慢的阶段(瓶颈)决定整体吞吐量。优化就是"找到瓶颈 → 优化到瓶颈转移 → 重复",并让非瓶颈阶段做到与瓶颈同样多的工作以换取画质。定位靠逐阶段增减负载的实验和性能工具;度量要用毫秒帧时间而不是 FPS。两条箴言:了解你的架构 (KNOW YOUR ARCHITECTURE);测量、测量、再测量。

优化循环(18 章引言)

flowchart LR
  A["定位瓶颈"] --> B["优化该阶段, 只到瓶颈转移为止"]
  B --> C{"达到性能目标?"}
  C -- "否" --> A
  C -- "是" --> D["让非瓶颈阶段做更多工作提升画质"]

如上图。要点:

  • 不要过度优化某一阶段,因为瓶颈转移后,可能要先优化其他几个阶段它才会再次成为瓶颈。
  • 瓶颈在一帧内甚至一次绘制内都会变化(许多小三角形时是几何阶段,重型程序着色器时是像素处理,纹理队列满时着色器停顿);"某阶段是瓶颈"指大部分时间如此,很少只有一个瓶颈。
  • 利用空闲:若应用阶段每帧 50 ms、其他阶段各 25 ms,几何和光栅化可以用满 50 ms 做更复杂的光照、阴影、反射而不降帧率。计算着色器也改变了思路:阴影贴图渲染时顶点/像素着色器很简单,光栅化或合并成为瓶颈,可重叠异步计算让着色单元保持忙碌。
  • 不要依赖某款 GPU 的特定实现做优化,硬件会变。

性能分析工具(18.1 节)

功能包括帧捕获与逐步回放、CPU/GPU 时间分析、着色器调试与热编辑、调试标记。书中列举:RenderDoc(Crytek 开发后开源,支持 DirectX/OpenGL/Vulkan)、AMD GPU PerfStudio(含静态着色器分析器)与 Radeon GPU Profiler、NVIDIA Nsight、微软 PIX 与 Visual Studio Graphics Diagnostics、GPUView(基于 ETW,关注 CPU 与 GPU 交互)、Intel GPA、Xcode Instruments(OpenGL ES Analysis、Metal System Trace)。没有工具时可用 API 的计时查询,部分厂商提供 GPU 计数器和线程追踪库。

逐阶段定位(18.2 节)

基本方法:减少某阶段的工作,帧率上升则它是瓶颈;或只减少其他阶段的工作,性能不变则未改动的阶段是瓶颈。统一着色器架构下顶点与像素共享单元、由 GPU 动态分配,区分二者更难。

阶段测试方法注意
应用 (CPU)看 CPU 是否接近 100%;用空驱动 (null driver) 得到程序运行速度上限;降频 CPU 看性能是否成比例下降(GPU 同理)CPU 可能在等 GPU;空驱动会掩盖驱动本身和 CPU-GPU 通信的瓶颈;降频可能让原本非瓶颈的阶段变成瓶颈
几何:顶点获取加大顶点格式(如多加几组纹理坐标),性能下降即为瓶颈几何阶段最难测,改动常牵连其他阶段,可从光栅化往回测
几何:顶点处理加长顶点着色器确保编译器没有把多余指令优化掉;几何着色器看输出大小与程序长度,细分着色器还看细分因子
光栅化同时加长顶点和像素着色器,帧时间不变则瓶颈在光栅化少见;细分或草叶产生的小三角形可能导致;小三角形也增加顶点负载,并因 2×2 quad 增加像素负载(quad overshading)
像素处理降低分辨率帧率明显上升;或加长 / 精简像素着色器;把纹理换成 1×1 看纹理访问是否为瓶颈有 LOD 系统时小屏幕也会简化模型;分辨率还影响遍历、深度测试、混合
合并改变输出缓冲位深;给不透明物体开启 alpha 混合后处理、阴影、粒子,以及(较少)头发和草这类着色简单的场景常在此受限

性能度量(18.3 节)

  • 厂商峰值(每秒顶点数、像素数)很难达到;GPU 计数器和利用率百分比如果可用很有价值:某部件计数远低于峰值就不太可能是瓶颈,但统计时段内瓶颈会移动。
  • 时钟频率不稳定:NVIDIA GPU Boost、AMD PowerTune 按功耗和温度调整频率,同一基准测试会因 GPU 初始温度不同而结果不同;DirectX 12 提供锁定 GPU 核心频率的方法以获得稳定计时。
  • 用毫秒,不用 FPS 做分析:FPS 是倒数而非线性量。50、50、20 FPS 的平均值 40 FPS 有误导性,换成帧时间 20、20、50 ms,平均 30 ms 即 33.3 FPS。某效果"耗 7 FPS"无法推广,因为各技术的 FPS 不能相加,时间可以相加。
  • 测量总帧时间时要关闭垂直同步(单缓冲模式),否则缓冲交换与显示器刷新同步。帧卡顿 (stutter) 分析通常需要统计方法;GPU 时间戳可了解帧内情况。
  • 移动设备还要优化功耗:有意降低帧率但保持交互可显著延长电池寿命;每瓦性能与 FPS 有同样的缺陷,更有用的度量是每项任务的焦耳数,如每像素焦耳。
  1. realtime_rendering_4ed.pdf 第 18 章 Pipeline Optimization

相关页面

图形学渲染管线Rendering Pipeline渲染管线是实时图形的核心:给定虚拟相机、三维物体、光源等,把场景转换成一张二维图像。RTR4 把它粗分为四个功能阶段:应用、几何处理、光栅化、像素处理,各阶段并行执行,整体速度由最慢的阶段决定。图形学实时渲染Real-Time Rendering实时渲染是在计算机上快速生成图像、并让图像随用户输入即时变化的技术。RTR4 认为它由三个要素共同定义:交互性、三维空间感,以及图形加速硬件 (GPU)。图形学绘制调用与状态切换优化Draw Calls & State Change Optimization调用图形 API 的开销主要在 CPU 端的驱动里:状态切换昂贵,每次绘制调用有固定开销,大量小批次会让 GPU"饿死"。对策是:合理放置缓冲;按状态代价排序分组;共享纹理和着色器;合并网格和实例化以减少调用;并用一个整数排序键同时兼顾状态分组与前后排序。图形学像素与帧缓冲优化Pixel & Framebuffer Optimization需要着色的像素通常远多于顶点,所以像素处理优化往往最划算。核心手段:保证占用率以隐藏纹理延迟、按距离切换着色器 LOD、利用 early-z 并通过从前往后排序或 z-prepass 减少过度绘制、缩小帧缓冲每像素存储(色度子采样、YCoCg 棋盘),以及只在需要时开启混合、避免 GPU 回读。几何与光栅化阶段的常用优化也一并列出。游戏开发多线程渲染与任务系统Multithreaded Rendering & Task SystemsCPU 时钟频率约在 2003 年停在 3.4 GHz 附近后,性能来自多核。应用阶段的优化一是让代码与内存访问更缓存友好,二是利用多核:多处理器流水线(时间并行,提高吞吐但增加延迟)、并行处理(空间并行,延迟更低)以及两者结合的任务系统;图形 API 用命令缓冲让多个线程并行录制绘制命令,新一代 API(DirectX 12、Vulkan、Metal)把更多责任交给应用以降低驱动开销。图形学GPU 并行架构GPU Parallel ArchitectureGPU 为吞吐量而设计:芯片大部分面积是成千上万个着色器核心,而不是缓存和控制逻辑。它靠在大量线程组 (warp/wavefront) 之间快速切换来隐藏访存延迟,用 SIMD 让一组线程锁步执行同一条指令。理解占用率和线程分歧,是写出高效着色器的关键。图形学延迟纹理与可见性缓冲Deferred Texturing & Visibility Buffer延迟着色避免了着色的过度绘制,但生成 G-buffer 时仍有过度绘制:先画的物体读了大量纹理,被后画的物体挡住后这些带宽全部浪费。延迟纹理只用一遍几何 pass、存极少的数据(纹理坐标与切线基,或仅三角形与实例 ID),直到着色时才读纹理。由于 GPU 算力增长快于带宽,让瓶颈落在计算而非缓冲访问被视为面向未来的做法。图形学GPU 内存、缓冲压缩与多重缓冲GPU Memory, Buffer Compression & Multiple Buffering带宽是稀缺资源。GPU 通过独立显存或统一内存架构 (UMA)、多级缓存与按瓦片存储提高局部性,并用基于瓦片表的无损压缩和快速清除减少渲染目标的带宽(注意:无损压缩只省带宽,不省内存)。颜色缓冲有高彩、真彩、深色三种模式;显示控制器以固定刷新率或 FreeSync/G-sync 自适应同步把颜色缓冲送到显示器;单/双/三缓冲在撕裂、等待与延迟之间取舍。图形学并行图形架构与排序分类Parallel Graphics Architectures & Sort Taxonomy提升图形速度的最佳方式是并行:多个几何单元、光栅化单元和像素处理单元同时工作再合并结果。Amdahl 定律指出串行部分限制总加速比。由于 API 要求按提交顺序处理图元,并行单元之间必须在某处做"模型空间到屏幕空间"的排序,按排序位置分为 sort-first、sort-middle、sort-last fragment、sort-last image 四类,各有负载均衡与带宽取舍。本页还简述光线追踪硬件的共同特征。综合帧时间预算与渲染性能Frame Budget & Rendering Performance本页把 wiki 中分散在 RTR4 第 18~23 章的性能知识串成一条线:一帧的时间预算由最慢的管线阶段决定,先用毫秒帧时间度量并定位瓶颈,再按瓶颈所在位置——CPU/驱动、几何、像素、带宽/内存——选用对应手段;最后从 GPU 硬件机制(占用率、HiZ/early-z、压缩、分块架构)理解这些手段为何有效。各结论的细节与出处见所链接的概念页。游戏开发 · UE5UE5 性能分析UE5 ProfilingUE5 性能分析的基本流程是:先用 stat unit 判断瓶颈在游戏线程、渲染线程还是 GPU,再用对应的 stat 组、profilegpu/GPU 统计或 Unreal Insights 的 Timing/Memory 等视图向下钻取;渲染特性(RDG、VSM、TSR)各自提供作用域和可视化。测量时要避开会扭曲数据的设置(调试构建、异步计算、可视化模式)。游戏开发 · UE5移动端渲染优化Mobile Rendering Optimization移动端优化的核心是认清设备的 CPU/GPU 速度、线程、带宽和内存,然后控制最主要的几项开销:Draw Call(官方称其为当前导致图形性能低下的最大因素,在 Galaxy Tab S6 上建议约 700 个,低端设备少于 500 个)、材质复杂度和 overdraw。合并网格和材质(Substance 把多种材质画进同一张纹理,用顶点色作遮罩)是减少 Draw Call 最直接的办法。游戏开发游戏内性能与内存剖析In-Game Profiling & Memory Tracking游戏是实时系统,要保持 30 或 60 FPS,同时受目标硬件内存限制。第三方剖析工具有局限、在主机上未必可用,所以许多引擎自带游戏内剖析器(手动插桩的代码块计时、层级关系、调用次数、导出 CSV)和内存统计与泄漏检测工具。GEA 讲解它们的实现要点和常见限制。(卷 I 10.8–10.9 节)

被这些页面引用1 篇

输入关键词开始搜索

滚轮或双指缩放 · 拖动平移 · 双击放大 / 还原