GPU Profiler

先把题目说成人话

游戏一到烟雾技能就顿一下，玩家只会感觉画面慢，团队却不能立刻猜是模型、特效还是脚本。先把每一帧当成一张时间账单：一边是准备工作的处理器，另一边是实际画像素的图形处理器；只有先确认哪边超时，才值得继续追最贵的一笔。把图形端账单按阶段展开的是图形性能分析器（GPU Profiler）；它帮助用同一镜头和同一条件证明改动是否真变快。

这是虚构教学故事，不是个人项目经历。

场景：先让问题变得看得见

教学捕获来自同一台电脑、同一份可执行版本：关闭画面同步，固定分辨率、质量档、镜头和技能释放时机。项目以每秒 60 帧为基线，一帧约有 16.7 毫秒。正常镜头里，负责画像素的一端（GPU）用时 13–15 ms；烟雾技能出现时升到 28–33 ms，准备脚本与绘制命令的一端（CPU）仍为 8–11 ms。

这组数据只把嫌疑从“两边都有可能”缩到“画像素的一边明显超时”。它还没有证明烟雾本身就是最贵的效果，更没有告诉我们该删掉哪一层。

（右脑）画面： 一家餐馆答应每隔十六点七毫秒端出一道菜。没有战斗时，前台接单、切菜和下锅都来得及；烟雾技能一出现，前台还是准时把菜送进厨房，灶上的锅却一直烧到三十毫秒，下一道菜只能在门外排队。客人感到的是整家店突然慢了，真正拖住队伍的却只是那口迟迟没有离开炉火的锅。

（左脑）对表： 先固定同一 Windows DirectX 11 Player，比较主线程、渲染线程与图形处理器帧时间，并把毫秒统一对照 16.7 毫秒预算。CPU Timeline 的主线程若出现 Gfx.WaitForPresentOnGfxThread，意思是主线程已经准备好，却仍在等渲染线程完成呈现相关工作；它本身不能区分原因是 GPU 反压还是 VSync，还要继续检查渲染线程的 Camera.Render、Gfx.PresentFrame 和目标构建设置。这段等待不能冒充处理器主动工作。确认图形端受限后，用性能分析器（Unity Profiler）的图形阶段计时找到昂贵区间，再用帧调试器（Frame Debugger）把区间对应到绘制事件、材质和目标缓冲。分辨率比例、绘制次数和毫秒是三种不同证据，只有固定条件下的单变量对照与合并复测，才能把相关变化收紧为因果判断。

小明：先形成一个完整猜测

小明看到对象很多，先怀疑 Draw Call。他合并了一批材质，让 Draw Call 从约 210 降到 150；在同一段捕获里，GPU 时间只改善不到 1 ms。

这个尝试并不丢人。它用结果排除了“提交数量是这次 GPU 慢帧的主因”。Draw Call 仍可能影响 CPU 提交成本，但当前 CPU 没有逼近预算，继续沿这条路追，优先级就不对了。

小红：把猜测放回现实检查

小红先把 Render Scale 从 1.0 临时调到 0.75，其他设置不变。GPU 时间降到约 21 ms。像素数量理论上变为原来的 0.75²=56.25%，但整帧还包含与分辨率无关的工作，所以帧时间不会按同一比例下降。这个变化只证明瓶颈对屏幕像素量敏感，不等于“最终方案就是模糊画面”。

她回到 Unity Profiler 的 GPU Usage，沿耗时标记找到透明与全屏效果，再用 Frame Debugger 检查这些阶段实际画了什么。时间捕获显示全屏扭曲约占 5 ms，多层透明烟雾约占 3 ms；Frame Debugger 则确认扭曲覆盖全屏、烟雾贴片在角色附近重复叠加。前者回答“哪里花时间”，后者回答“这一段画了什么”，两种证据没有混用。

我：用检查结果修正模型

第一轮把扭曲改为半分辨率，并减少低价值的透明重叠，GPU 降到约 20–23 ms。它明显变快，却仍高于 16.7 ms，所以不能宣布完成。

三个人重新确认美术不能丢的东西：技能轮廓、爆发节奏和战斗可读性。随后只削减不支持这三项目标的成本：限制烟雾同时覆盖层数、收紧粒子贴片的空白区域、降低扭曲采样与全屏计算，并让高成本版本只在关键爆发时短暂出现。这段固定短捕获中的 GPU 大多落在约 14–16 ms，说明方案已经有希望，却还不能证明 60 FPS 交付完成；长时间战斗、发热后的设备状态和最坏可接受镜头都进入 16.7 ms 预算，并通过美术验收后，才能宣布达标。质量档与回滚开关继续保留。

本页不能代替本人的真实经历：原题要求“三个曾解决的问题”，这里仅演示一条诊断链，三个案例都必须来自自己的捕获、改动记录和复测结果。

（右脑）画面修正： 小明先把送进厨房的单子从约 210 张整理成 150 张，灶上的等待却只短了不到一毫秒，说明这次不是单子太散。小红临时把每只盘子缩小，厨房很快轻松到约 21 毫秒，于是继续盯着那些会铺满整只盘子的工序。她最终看见，画面扭曲像一层膜盖住整盘，烟雾又用许多透明薄片反复覆盖同一处。减少这些覆盖后，慢下来的原因才从“战斗里东西太多”收窄到两件真正看得见的事。

（左脑）严格对表： 诊断顺序是：固定设备、构建、API、分辨率、质量档、镜头与预热；记录 CPU/GPU 分布并与 16.7 ms 预算比较；用 GPU Profiler 定位阶段、用 Frame Debugger/平台捕获对应事件；一次只改变 Render Scale、扭曲分辨率或透明覆盖中的一个量并重复采样；最后对合并版本跑长时最坏镜头。验收要求 GPU、CPU 和 Player Frame Time 的既定统计量均过门禁且美术目标通过；个人案例还必须有本人改动与团队验收记录。

老师解惑

• 先比较 CPU、GPU 与目标预算，才能决定追脚本、提交还是像素成本；不要从某个漂亮的面板直接跳到结论。
• CPU Timeline 主线程里的 Gfx.WaitForPresentOnGfxThread 表示主线程在等渲染线程完成呈现相关工作；它可能来自 GPU 反压或 VSync，必须结合渲染线程与构建设置判断，不等于 CPU 正在执行同等时长的有效工作。
• 降 Render Scale 是灵敏度测试：变化大，说明像素相关工作值得优先检查；它不是自动生成的交付方案。
• 单项改动失败也有价值，只要它排除了一个假设，并且测试条件没有变化。
• 优化完成的条件不是“某个效果更便宜”，而是最坏可接受场景进入预算，同时画面验收通过。

工具分工

• Unity Profiler CPU/GPU Usage：比较两端时间，并在受支持的图形 API 上查看 GPU 标记与阶段耗时。
• Frame Debugger：按绘制顺序检查 Pass、材质、Render Target 与具体对象；它不提供可靠的 GPU 计时。
• RenderDoc、PIX 或平台 GPU 工具：当 Unity 标记不够细或目标平台不支持计时时，继续查看事件、资源和硬件计数器。
• 目标构建的重复捕获：固定镜头与操作，记录典型值和最坏值，防止拿编辑器单帧当结论。

记忆钩子

先分 CPU 和 GPU，再找最贵阶段；一次只动一个效果，最后让美术验收与帧预算一起通过。