我如何学会停止担忧并爱上性能分析导言一个幽灵，性能问题的幽灵， 在游戏项目内徘徊过低的帧率，随机的卡顿，以其高度的隐蔽性及修复难度，犹如噩梦般，困扰着项目进度，程序开发，以及未来的市场口碑而资料的匮乏或不适合的工具，使得开发人员难以定位并修复问题。

整个项目，自上而下弥漫着担忧的氛围本文主要目的，在于讲述一些通用的性能分析的方法，帮助各位定位分析游戏中的性能问题，正如启示录21:6所说，希望这篇文章，犹如各位在性能分析的荒漠痛苦前行时，能够解渴的一杯水，学会停止担忧并爱上性能分析。

第一章 问题这行的真谛不在于找对答案，而是找对问题——阿诺德·阿宾逊爵士，《是，大臣》软件工程是一个高速变化的行业，游戏攻略每时每刻总有新的技术诞生，解决方案，或者说答案，在每个时刻并不唯一，而不变的则是问题，当各位能够找对问题，自然明白自身所需，从而找到适合各位的答案。

1.1 什么是游戏 CPU 性能问题在解答这个问题之前，首先需要明白， CPU 在游戏这个舞台上扮演了一个什么样的角色，公认的游戏性能的指标是每秒传输帧率，简称帧率，代表的是每秒绘制次数，直观上来讲，这体现的是GPU 的性能指标。

假设游戏运行在这样一个环境下，普通的消费端 GPU，配上算力能够匹配如天网超级计算机的单片 CPU ，则游戏能够到达的最高帧率，必定是由 GPU 本身的峰值性能所决定所以， CPU 本身无法提升，仅有可能让游戏无限接近 G游戏攻略PU 性能所能达到的最高帧率。

当然更有可能的情况是，完全无法发挥 GPU 的峰值性能CPU 在游戏中的角色，主要表现为，物理计算，AI 计算，以及提交 GPU 绘制命令过多的物理和 AI 计算，可能影响 GPU 绘制命令提交，再加上不合理的 GPU 绘制命令提交，就会使得 GPU 无法发挥峰值性能。

所以，游戏 CPU 性能问题，其实就是一个木桶的最短木板问题，不合理的 CPU 调用，就是导致木桶水位下降的那块最短木板，合理化 CPU 调用，使得 GPU 发挥峰值性能，问题自然迎刃而解1.2 什么是理想的 CPU 性能分析工具。

当游戏 CPU 性能问题浮现，各位自然会去寻找分析工具，以求找到结症游戏攻略所在各个 CPU 厂商，操作系统，都有一套基于硬件性能计数器，统计调用函数的 CPU 性能分析工具，比如 AMD μProf ，Intel VTune 。

这些传统 CPU 性能分析工具是否适合游戏？世界并非非黑即白，正确的答案是：是，也不是他们在游戏 CPU 性能分析中，发挥重要的作用，但是不适合做初步分析传统 CPU 性能分析工具，默认统计的是每个函数的运行效率，但是占据 CPU 时间最高的函数，可能并不是导致帧率下降的罪魁祸首。

游戏的表现是基于时间线而非函数，前一秒表现正常的函数不代表下一秒不会导致掉帧，所以统计结果需要基于时间线，而非函数名展现，就能找到某段时间内表现不正常的函数基于时间游戏攻略线的结果展示，很多传统 CPU 性能分析工具也已经实现，但这仍旧缺少一个至关重要的因素：表现不正常的是哪段时间。

上一节已经解释过，游戏的主要性能指标是基于 GPU ，帧率的降低意味着 CPU 没有发挥出 GPU 的峰值性能所以和 CPU 同步的，基于时间线的 GPU 的使用率也是必不可少的，由此就能得知 GPU 表现不正常的时间段。

综上所述，理想的游戏 CPU 性能分析工具包含：1. 基于时间线的 GPU 使用率统计，用以确定帧率表现不正常的时间段2. 和 GPU 同步的、基于时间线的 CPU 函数调用统计，用以发现帧率表现不正常的时间段内不合理的 CPU 函数调用，进行初步分析。

3. CPU游戏攻略 性能计数器，用以调查不合理的 CPU 函数内部硬件性能问题，进行深入分析第二章 工具好的开始，是成功的一半——贺拉斯，古罗马诗人作为一个好的开始，找对合适的工具进行分析，能够让性能分析事半功倍，并快速定位问题所在。

上一章内，已经描述了理想的游戏 CPU 性能分析工具，但是完美的事物并不存在，需要多个工具组合，才能达到理想的效果如果以医学放射科做类比，可以把理想的游戏 CPU 性能分析工具拆分为两个功能部分：1. 类似于 X 光扫描的初步分析，用以确定帧率表现不正常的时间段，及期间内的 CPU 函数调用。

2. 类似于 CT 扫描的深入分析，用以调查不合理的 CPU 函数的内部硬件性能问题功能2游戏攻略可以用传统 CPU 性能分析工具来实现而功能1的资料缺失，导致性能分析无从下手，而功能1又是功能2的前置必要条件，所以这章主要介绍的就是 CPU 初步性能分析工具。

由于 Windows 及 DirectX 12 是最为主流的游戏开发平台，所以下文皆基于此环境2.1 Event TracingWindows Event Tracing 事件跟踪，简称 ETW ，ETW 支持对内核和应用程序事件进行一致、直接的捕获。

可以随时启用或禁用事件捕获，而无需重新启动系统或进程可以捕获并呈现所选事件以非侵入性的方式标识并诊断系统和应用程序性能问题这段对 ETW 的描述摘抄自 MSDN ，依旧是毫无悬念的晦涩游戏攻略难懂其实这段话中只需关注这如下几个关键点。

1. ETW 可以捕获整个内核和应用程序事件的性能事件，所以其事件捕获是基于操作系统级别，其中自然包括 GPU 和 CPU 事件2. ETW 的事件捕获是一致的，意味着 GPU 和 CPU 事件是同步且一一对应的。

3. ETW捕获的各个事件单位不一定相同，可以保证一致性的条件必定是基于时间戳，所以生成的日志可以按时间线展示4. ETW 的捕获是非入侵式的，所以无需修改应用程序，同样可以证明其事件捕获是基于操作系统而非程序级别。

所以 ETW 符合作为初步分析的所有条件，由其作为入手点是一个非常不错的选择2.2 如何获取 ETWWindows Perfor游戏攻略mance Toolkit (WPT) 内的 Windows Performance Recorder (WPR) 和 Windows Performance Recorder User Interface (WPRUI) 是获取 ETW 的标准工具，其功能非常强大，但他们不是今天的主角。

由于 ETW 可以记录几乎所有操作系统的事件，WPR 和 WPRUI 里的选项非常庞杂另外一个原因则是，没有快捷键可以在后台启动它们，必须从游戏窗口切换回桌面开启记录，而游戏窗口的失焦必定导致游戏帧率下降，从而导致收集到的数据失真。

所以一个可以无需设置、有快捷键、随开随用的 ETW 记录工具是一个理想的选择这游戏攻略里比较推荐 UIforETW ，UIforETW 是一个开源的，可视化管理 ETW 的解决方案，可以方便地管理捕获的 ETW 文件，同时提供了后台快捷键，事件捕获随开随关，其选项足以应对绝大多数 C/C++ 为开发语言的游戏，操作方便快捷，唯一需要注意的是 GPU tracing 默认未勾选，勾选以后便能捕获 GPU 队列数据。

Figure 1 UI for ETW

方便的操作意味着只需经过简单培训，毫无开发经验的人员亦可熟练操作，其可以带来一个意想不到的好处——最新的 1.56 版本内自带了 WPT ，使其成为了一个完全独立的软件包，可以将其分发给测试部门，当测试部门发现了性能问题，只需提供捕游戏攻略获的 ETW ，即可做性能分析，大大节省开发时间。

或者更进一步，提交给客户做事件捕获，亦未尝不可还在为测试部门提交的性能问题无法重现烦恼不已？还在翻箱倒柜，尝试组装和测试部门一样的硬件环境而灰头土脸？还在为测试部门无法重现客户上报的奇奇怪怪的性能问题头疼？

让 UIforETW 来拯救你那糟糕的一天吧2.3 分析 ETW最后但是最重要的一步就是分析工具，WPT 内自带了 ETW 的分析工具，这里推荐使用的是 GPUView 各位可能会问，现在分析的是 CPU 性能问题，不该是选个叫 CPUView 之类名字的工具吗？莫被表象迷惑，尽管这个工具名字里大大地写着 GPU ，但却是一个用来分析游戏 C游戏攻略PU 性能问题的工具。

前文已经说明， ETW 内捕获了 GPU 和 CPU 性能事件， GPUView 可以忠实地将其展示出来 GPUView 分为上下两部分，蓝色背景灰色线条的上半部分表现的是 GPU 队列的使用率，绿色的下半部分则是同步时间内的进程，及展开的线程 CPU 调用堆栈。

如Figure 2 GPUView所示，红框内的 GPU 3D 渲染队列有明显的空隙，只需展开游戏进程，查看此时间段内的 CPU 调用，就能很容易的发现问题所在 由此，则可以将 CPU 导致的 GPU 性能问题简化为队列填空问题，移除或修复不合理的 CPU 函数调用，保证 GPU 队列的满负荷使用。

Figure 游戏攻略2 GPUView

GPUView 尽管外表充满了沉重的历史感，但却是游戏 CPU 性能分析最为重要的一环自此，最后一块拼图已经合上，是否有点摩拳擦掌，想在项目里面试试身手了呢？第三章 实例纸上得来终觉浅，绝知此事要躬行。

——陆游武器展销会上经过实战的武器大多更受欢迎，只有经过实际项目的检验，才能确认上文介绍的方法是否有效，本章将以一个实际游戏项目作为案例，验证理论的有效性 3.1 简介这里以一个实际参与过的项目为例，因其基于虚幻4研发，所以很具现实意义，由于保密问题，就暂且用代号称之为”大E”吧。

”大E”的早期开放测试过程中，经常会发生随机的掉帧卡顿，但是再次运行相同场景，状况则显著改善，不过游戏攻略仍旧会有轻微的卡顿，此类不易重现的掉帧卡顿问题可以说是开发人员的噩梦，需要花费大量的时间重现和分析问题，幽灵出现了。

3.2 重现线索其实已经在描述中，再次运行场景，掉帧显著改善，这个行为模式非常类似于缓存，只需要进入一个不同场景，就能捕获一份有用的 ETW ，当然这一节暂时不讨论 ETW 如果有过相关的优化经验，各位大概已经能够看出幽灵的影子。

诸如 AMD 、 NVIDIA 之类的显卡或者 DirectX 、 Vulkan 之类的图形 API ，会为了优化游戏而将运行过的着色器作为缓存存于硬盘上，以减少之后的编译时间，着色器缓存极有可能缓解了掉帧。

只需要删除着色器缓存便可验证猜测，这里推荐如下游戏攻略的脚本，可以一键删除 Windows 上的着色器缓存 1. rem Run as administrator 2. rem Disable Steam Shader Pre-Caching before running this script

3. rem Reboot after running this script to clear any shaders still in system memory 4. 5. setlocal enableextensions

6. cd /d "%~dp0" 7. rmdir /s /q "%LOCALAPPDATA%D3DSCache" 8. rm游戏攻略dir /s /q "%LOCALAPPDATA%AMDDxCache"

9. rmdir /s /q "%LOCALAPPDATA%AMDGLCache" 10. rmdir /s /q "%LOCALAPPDATA%AMDVkCache" 11. rmdir /s /q "%ProgramData%NVIDIA CorporationNV_Cache"

12. rmdir /s /q "%ProgramFiles(x86)%Steamsteamappsshadercache" 运行脚本，重启系统以清空内存，再次运行相同的场景，掉帧马上就重现了，这下抓住你了。

3.3 分析解游戏攻略决重现的麻烦之后，便可以进行问题分析清除着色器缓存，保证没有消耗资源的后台进程以减少干扰，运行游戏之后使用 UIforETW 开启捕获，发现卡顿后关闭捕获，便能获得一份干净的 ETW 记录。

使用 GPUView 打开 ETW 记录，赫然发现大量的 GPU 渲染队列空隙，如Figure 3 ETW GPU所示，最长一段空隙超过了2秒，其余的还有很多小空隙，这样就不太妙了Figure 3 ETW GPU。

在 GPUView 内配置好 PDB 路径，放大那块最大的 GPU 空隙，随后展开游戏进程，很容易的就会发现在这段时间内 ID 4284线程最为可疑，点击Figure 4 Computer Sha游戏攻略der标注的蓝色框体内的游标打开发生在此时间内的事件列表，在列表内使用4284过滤掉其他线程的事件，最后便能找到线程的调用堆栈。

红色框体内的调用堆栈表明， FD3D12DynamicRHI::RHICreateComputePipelineState 在此时被触发，由于没有 PSO 缓存而导致 FD3D12PipelineStateCache::OnPSOCreated 被触发，最后进入 ID3D12Device2::CreatePipelineState 开始编译计算着色器。

创建管道极有可能是为了创建着色器，而在游戏运行过程中进行此操作是非常不可取的，这个同步操作必定会导致渲染挂起，使得渲染游戏攻略队列产生空隙，掉帧卡顿自然无可避免 Figure 4 Computer Shader。

再来看看其他空隙，Figure 5 Graphic Shader显示了在另外一段 GPU 空隙内， ID 10168，2856和2708 的线程也在加班加点，打开堆栈一看，原来都在调用 FD3D12DynamicRHI::RHICreateGraphicPipelineState 试图创建图形着色器，难怪会卡的这么厉害，其余空隙也都是在创建图形着色器，在此就不再赘述，问题找到了。

Figure 5 Graphic Shader

至此分析完毕，很明显这是在游戏过程中，虚幻4的 RHI 线程在向线程池大量提交创建着色游戏攻略器任务，导致渲染被挂起而引起的随机掉帧，掀开盖在幽灵身上的床单，是不是也没那么可怕呢？3.4 解决问题已经发现，有经验的虚幻开发人员估计马上就能发现虚幻4官方早已给出了解决方案，那就是

PSO 缓存具体实现就不再这里赘述，简而言之就是在烘焙过程中将着色器预先编译，使得虚幻引擎在启动时加载着色器，减少编译预热时间，其行为类似于显卡或是图形 API 提供的着色器缓存不过直到虚幻4.27.2， PSO 缓存仍旧无法记录以及烘焙计算着色器，但是却可以加载，可以认为是引擎的一个功能缺失。

不过虚幻5已经完整实现了其功能，而且修改并不复杂，完全可以移植到虚幻4，具体可以参考 GitHub上的提交到此，终于将幽游戏攻略灵赶出了项目，真是愉快的一天呐第四章 并非唯一的答案前文详细介绍了 GPUView 及其使用方法，但是能够分析 ETW 的工具并非只有 GPUView 一个。

WPT 内自带有一个更现代的 Windows Performance Analyzer (WPA) ，拥有更为现代化的 UI 以及更为强大的事件分析功能，运用得当可以做更深度的系统分析不过其放大缩小没有 GPUView 那么精确，而且分析数据量较大的 ETW 时加载速度较慢，各位可以酌情自选。

Visual Studio Concurrency Visualizer 同样可以分析 ETW ，恰如其名，这是一个 Visual Studio 的游戏攻略插件，平时喜欢使用 Visual Studio 作为开发环境的可以一试。

Superluminal 与上面介绍的有所不同，是一个第三方的性能分析工具，并不基于 ETW ，同样包含同步的 GPU 和 CPU 性能数据，所以也可以用以做初步分析，而且有对主机和 Unity 的支持，值得一试，不过有个缺点就是————它是收费的。

前文提及，答案并非唯一，而问题才是关键，这个列表可能随着时间被添加，更改或是废弃，但是正确的问题却能够促使各位寻找正确的答案，无论何时以及何地看完此文，不知各位是否有所思，有所得，希望它能够作为各位项目迈向成功中的一小步。

后续还会有更多专题内容在此分享，也欢迎各位将自己感兴趣的游戏攻略问题在评论区告知我们，或许就会成为我们下次分享的主题！HarryAMD DevTech Engineer，专注于帮助游戏开发者高效利用 AMD 处理器。

其工作内容包括：分析 PC 应用程序以及游戏在 AMD 处理器上的性能问题，以及开发基准测试