Draw Call 优化
一、传统引擎层面的合批（Batching）与实例化
传统优化的核心是减少渲染状态的切换（State Changes），因为每次切换材质、Shader 或绑定新纹理，都会在 CPU 端产生高昂的驱动层验证开销。
1. GPU Instancing（GPU 实例化）
- 原理：使用单次 Draw Call 绘制大量具有相同网格（Mesh）和相同材质（Material）的对象。位置、旋转、颜色等差异化数据通过 Compute Buffer 或 Instance Buffer 传递给 Shader 动态计算。
- 适用场景：大规模植被（草、树）、粒子群、飞行的箭矢、建筑群。
- 引擎实践：在 Unity 中勾选材质的
Enable GPU Instancing，或使用Graphics.DrawMeshInstancedIndirect；在 UE 中广泛使用 HISM（Hierarchical Instanced Static Mesh）。
2. SRP Batcher（Unity 可渲染管线专有）
- 原理：不同于传统的动态或静态合批，SRP Batcher 不要求网格相同。只要使用同一个 Shader 变体，它就能通过在 GPU 显存中预先缓存材质属性（CBUFFER），将原本分离的 Draw Call 放入一个大的 Batch 中提交，极大降低 CPU 开销。
- 适用场景：大量使用同一种底层 Shader（如 URP/HDRP 的 Lit Shader）但参数不同的场景物体。
3. 静态合批（Static Batching）与动态合批（Dynamic Batching）
- 静态合批：在构建时（或场景加载时）将所有标记为 Static 且共享相同材质的 Mesh 合并为一个巨大的 Mesh。代价是内存占用显著增加。
- 动态合批：CPU 在每帧动态组合共享材质的小顶点网格。由于 CPU 需要进行额外的顶点变换计算，如果网格顶点数过多，开销反而会高于原本的 Draw Call，在现代多核 CPU 和 GPU 环境下已逐渐被边缘化。
二、材质与状态切换优化
Draw Call 的昂贵很大程度上来自于其附带的状态切换（比如 SetTexture, SetShader）。
- 纹理图集（Texture Atlasing）：将多个小道具的纹理合并到一张大图中。这样即使网格不同，也可以共享同一个材质，从而创造合批条件。
- Texture Arrays（纹理数组） / Bindless Textures（无绑定纹理）：现代图形 API 允许在 Shader 中一次性绑定一个纹理数组或使用无绑定技术。通过网格的自定义数据传递 Index，Shader 根据 Index 采样不同的纹理，彻底消除因切换纹理带来的 Draw Call 打断。
- Shader 变体控制（Variant Stripping）：减少不必要的宏定义分支。如果两个材质仅因为一个不起眼的宏不同而被编译为两个变体，它们就无法被引擎（如 SRP Batcher）合批。
三、现代范式：GPU-Driven Rendering Pipeline
对于追求极致性能和高密度的场景，优化的尽头是把 Culling（剔除）和 Draw Call 提交的权力从 CPU 交给 GPU。
1. GPU Culling（计算着色器剔除）
将所有的场景包围盒数据传递给 Compute Shader。利用 GPU 的海量并行计算能力执行：
- Frustum Culling（视锥体剔除）
- Occlusion Culling（遮挡剔除）：通常配合上一帧的深度缓冲（Hi-Z Culling）进行计算。剔除完成后，由 Compute Shader 直接生成并填充绘制参数（Draw Arguments）。
2. Indirect Drawing（间接绘制）
传统的 Draw Call 由 CPU 明确指明绘制多少个顶点。而在 GPU-Driven 管线中，使用如 DrawInstancedIndirect 或现代 API 的 ExecuteIndirect。CPU 只需要发出一个命令，GPU 会读取由 Compute Shader 生成的 Buffer 中的数据（即剔除后存活下来的实例数量和参数）来执行渲染。这意味着场景中有 10 万棵树还是 10 棵树，对 CPU 的开销几乎是一样的。
3. Mesh Shading / Nanite 架构
这是当前引擎（如 Unreal Engine 5 的 Nanite）最前沿的渲染策略。
- 传统的顶点流水线（Vertex -> Rasterizer）对极小三角形的效率极低。
- Mesh Shader 替代了传统的 Vertex/Geometry/Tessellation 阶段，允许在 GPU 端以类似于 Compute Shader 的方式，按簇（Meshlets）级别进行细粒度的 Culling、LOD 切换和顶点生成。这不仅彻底解决了 Draw Call 瓶颈，还顺带解决了多边形渲染瓶颈。
性能排查建议：在进行优化前，永远先看 Profiler（比如 RenderDoc、PIX 或引擎自带的 Frame Debugger）。如果是 CPU 端的
RenderThread或RenderLoop被压垮，那确实是 Draw Call / 状态切换问题；如果是 GPU 耗时过长，盲目减少 Draw Call 有时会导致合批后的 Mesh 过大，反而加剧了 GPU 端的 Overdraw 或显存带宽压力。
本博客所有文章除特别声明外，均采用 CC BY-NC-SA 4.0 许可协议。转载请注明来源 Never Settle！
相关推荐
2026-04-17
Shader 优化实战清单：从指令、带宽到 Shader Cache（170ms → 1.04ms 案例）
这篇文章把 Shader 优化拆成两类问题： 算得太多（ALU）：指令数高、昂贵函数太多、重复计算、分支导致浪费。 读得太多（带宽/采样）：纹理采样次数多、采样依赖（dependent read）、格式不亲和、缓存命中差。 最后再补上经常被忽略但收益巨大的工程项：Shader Cache / 预编译（你给的例子里，编译耗时从 170ms 降到 1.04ms）。 目标不是“把指令数降到极限”，而是在视觉可接受的前提下，把瓶颈从 GPU/编译/加载链路里移走，并让优化可验证、可回归。 0. 先说清楚：你要优化的是哪一种“慢”Shader 相关的“慢”常见有三类，解决手段完全不同： 运行时 GPU 慢：帧时间里 Pixel/Vertex/Compute 占比高（看 GPU Profiler / RenderDoc / Xcode GPU Frame Debugger）。 运行时 CPU 慢（驱动/状态切换）：材质变体过多、关键字爆炸、drawcall...
2026-04-23
CPU 与 GPU 性能瓶颈分析与定位完全指南（RenderDoc + Nsight 实战）
1. 宏观定位：找到流水线阻塞点现代游戏引擎渲染建立在**流水线并行（Pipelined Parallelism）**之上，主要由三大核心线程协作完成。排查的第一原则是：区分”真正在干活”与”在死等同步锁（Stall / Bubble）”的时间。 1.1 三大核心线程职责 线程 职责 Game Thread（逻辑线程） 跑物理、AI、动画，生成场景可见性数据 Render Thread（渲染线程） 接收逻辑数据，进行视锥体 / 遮挡剔除，生成渲染指令（Draw Calls） RHI / GPU Thread 将指令翻译为底层 API（Vulkan / DX12）Command Buffer，提交 GPU 硬件执行 1.2 宏观瓶颈判定核心思路是对比各阶段耗时（工具：Unreal Insights / stat unit / Nsight Systems）。 12345678瓶颈所在 ...
2026-04-29
DX 共享内存技术
技术概述通过创建一个“共享显存服务进程”（下文简称共享进程），把所有客户端的纹理创建/加载请求统一转发到共享进程执行，从而实现一个跨进程的纹理资源管理器（同一份纹理只创建一次，多客户端复用同一块显存）。 问题背景 某大型端游/客户端应用存在“多开”使用场景，且大量视觉效果由 2D 序列帧纹理驱动。多开时每个客户端重复加载同一批资源，会导致显存总占用快速升高；显存压力过大时，可能出现资源分配失败甚至进程崩溃。 多开往往具有较高内容相关性（例如多个客户端在同一场景/同一队伍内），意味着加载集合高度重叠。如果能把“相同资源只加载一次并跨进程共享”，则总显存占用可进一步下降。 技术思路 Direct3D 11 支持共享资源（shared resource / shared handle）。一个进程创建的纹理可以通过共享句柄让另一个进程打开并使用。 客户端启动时创建或连接共享进程；客户端侧所有纹理创建请求都转发给共享进程执行。 客户端与共享进程之间的控制面通信使用共享内存（元信息、状态、句柄等），数据面仍由...
2026-05-13
游戏移动端与 PC 端的优化差异
1. 减少带宽和显存消耗2. 减少渲染中 Pass 切换的数目来降低带宽1. OpenGL ES 中使用 Framebuffer Fetch2. Vulkan 使用 Subpass 来减少带宽例如，延迟渲染中的 GBuffer 和 Lighting Pass 两个 Pass 如果执行了 EndPass，会将 On-Chip Memory Store 到系统内存中，下个 Pass 要 Load On-Chip Memory。通过 Subpass Load 将利用 Tile 中的数据计算。 3. 每一帧显式提交一个 Clear 减少 Tile Load3. 带宽压缩1. ASTC 贴图格式压缩，不同资源压缩比例不同 4×4 - 8×82. 降低 RT 精度2. Early-Z、HSR 硬件像素剔除比较关键 半透明材质不受 HSR，存在 Overdraw Alpha Test 材质会破坏 HSR，所以放到不透明物体最后渲染 3. 实际项目优化示例1....
2026-04-10
学习图形学：光线追踪入门（从 0 到可用的最小实现）
0. 为什么要学光线追踪光线追踪（Ray Tracing）的价值不只是“更真实”，而是它把渲染问题拆成一套非常统一的数学与工程模块：发射射线 → 求交 → 计算散射/发光 → 继续追踪/结束。理解这套闭环后，再回头看光栅化管线、PBR、GI、采样与降噪，会更容易形成体系。 本文目标：做出一个能渲染球体/三角形、支持阴影、反射，并能逐步扩展到路径追踪的最小实现。 1. 你需要的最小数学与约定 向量：点乘（投影/夹角）、叉乘（法线/面积）、归一化 射线： r(t) = o + t d ，其中 t > 0 坐标系：右手/左手都行，但要一致（相机、法线方向、叉乘方向） EPS：为避免自相交，常用一个很小的偏移量 \epsilon （如 1e{-4}） 2. 关键模块总览（建议按这个顺序实现） 2.1 相机（Camera）：把像素坐标映射到世界空间射线 2.2 几何（Hittable）：射线-物体求交（球体最容易起步） 2.3 材质（Material /...
2026-05-09
移动渲染管线
1. 流程图 Tile-Based Deferred Rendering (TBDR) 流程图讲解这是 PowerVR GPU 的 TBDR 渲染架构流程图，分为两大阶段：几何阶段和渲染阶段，核心特点是利用片上缓存（On-Chip Buffers）减少对系统内存的读写。 第一阶段：几何处理（Geometry Phase）① Vertex Processing（顶点处理） 执行顶点着色器，完成坐标变换、光照计算等 输入来自系统内存中的 Geometry Data（几何数据） ② Clip, Project & Cull（裁剪、投影与剔除） 将顶点从世界空间变换到裁剪空间 剔除视锥体外的图元，减少后续计算量 Cull：剔除，视锥体外 Clip：裁剪，一部分视锥体内，一部分视锥体外 ③ Tiling（分块） 将屏幕划分为若干小块（Tile），判断每个图元属于哪些 Tile 输出 Primitive List（图元列表）和 Vertex Data（顶点数据）存入系统内存 ⚠️ 这是 TBDR 的关键步骤，后续按 Tile 逐块处理 第二阶段：逐 Tile...
评论
