Intel GPA 图形性能分析：从 GPU 瓶颈到 draw call 优化

调图形性能这件事，最怕的不是没工具，是工具甩给你一屏计数器，你却不知道该盯哪一个。Intel GPA（Graphics Performance Analyzers）这套工具的价值，就是把"我感觉有点卡"翻译成"第 137 号 draw call 的像素着色器多花了 1.8 毫秒"这种能动手改的结论。它由 Monitor、Frame Analyzer、Trace Analyzer 等几个组件拼成，覆盖实时监控、单帧深挖、长时段追踪三条路径，Windows 桌面端和 Android 端都有对应方案。这篇文章不打算复述安装向导里的"下一步"，而是把我在实际项目里怎么用它定位 GPU 瓶颈、怎么做 Erg 实验把开销砍到具体某个 pass、怎么用 Pixel History 抓出"画面看着没问题但就是慢"的元凶，整套流程摊开写。正在做游戏、三维可视化、CAD、车载 HMI，或者任何对帧率敏感的应用，手上有一台 Intel 显卡的机器或者一台能连 adb 的 Android 设备，这篇可以直接照着抄。

1. GPA 到底解决什么问题，以及它不该被用来干什么

1.1 几个组件各自的职责边界

很多人第一次打开 GPA 会被一堆快捷方式搞懵，其实按"看问题的时间尺度"分就清楚了。GPA Monitor负责秒级到分钟级的实时监控，它把 CPU 占用、GPU 占用、帧时间、显存、功耗、温度这些系统级指标以叠加层（HUD）的形式压在目标应用上，同时画成时间曲线。它的强项是快速回答"这一帧到底卡在 CPU 还是 GPU"，弱项是精度——采样间隔和驱动上报频率决定了你看不到亚毫秒级的抖动细节。

GPA Frame Analyzer是整套工具里最值钱的部分。它抓取单帧，把这一帧里所有 draw call、dispatch、render target、纹理、着色器、状态设置全部展开，还能做"实验"（Erg）：临时禁用某个 draw call、把某个着色器替换成纯色输出、把某个渲染目标的分辨率或格式降下来，然后立刻看到 GPU Duration 的变化。它解决的问题是"这一帧里谁最贵"，粒度可以细到单次 draw。

GPA Trace Analyzer / Platform Analyzer处理的是时间轴问题：把几十秒甚至几分钟内的 API 调用、GPU 队列、CPU 线程活动和同步点排在同一条时间线上，用来看帧率为什么周期性掉、为什么某个时刻出现 30 毫秒的长帧。它不追求单帧内的极致细节，追求的是"事件之间的因果关系"。

注意：别再去找一个叫 System Analyzer 的独立工具了，它是 Monitor 的旧名字，新版里已经合并。网上不少教程还停留在老版本的界面截图，照着点会找不到按钮。

1.2 三分钟选型：什么场景用哪个

我把常见需求整理成一张对照表，遇到问题时先在这里对一下，能省掉大量试错时间。

选型的核心逻辑只有一条：先用粗粒度工具缩小范围，再用细粒度工具钻进去。我见过太多人一上来就抓帧，结果在一个 2000 个 draw call 的帧里翻列表翻到怀疑人生。正确的顺序永远是从 Monitor 开始，确认 GPU 是瓶颈之后才值得抓帧。

1.3 它做不到的事，提前知道能少走弯路

第一，硬件级 EU 计数器只在 Intel 显卡上有完整数据。EU Active、EU Stall、Sampler 吞吐、L3 命中率这一类指标依赖驱动暴露的性能计数器，换到别的品牌显卡上，Monitor 和 Frame Analyzer 依然能跑，但很多硬件指标会显示为不可用，能拿到的主要是 API 层面的时间信息。

第二，受保护进程、带反作弊的游戏、部分商用 DRM 播放器挂不上。GPA 的注入机制本质上是在目标进程里加载一层拦截库，任何阻止第三方 DLL 注入的安全机制都会让它失效，这不是配置问题，是设计上的硬边界。

第三，它不会告诉你"该怎么改"。Erg 实验能精确告诉你"把这个着色器的输出换成纯色能省 1.2 毫秒"，但要不要降精度、要不要改成延迟渲染、要不要合并 pass，这些是工程决策，工具只负责提供数据。

实操心得：如果目标程序崩溃或者行为异常，先怀疑是注入本身导致的，而不是你的代码出 bug 了。最简单的验证方式是把同一份构建放在没装 GPA 的干净机器上跑一遍做对照。

2. 环境搭起来：桌面端和 Android 端是两条完全不同的路

2.1 Windows 端的安装与驱动前提

安装包从 Intel 开发者工具页面下载，搜索 "Graphics Performance Analyzers" 就能找到，安装包里自带 Monitor、Frame Analyzer、Trace Analyzer 等组件，体积通常几百 MB。安装过程需要管理员权限，装完之后建议重启一次，因为部分组件依赖驱动侧的支持模块。系统要求大致是 Windows 10 1909 及以上、Windows 11 全系，显卡方面 Intel 核显和 Arc 系列独显支持最完整。

真正容易出问题的不是安装，是驱动版本。GPA 的深层功能依赖显卡驱动里的分析接口，驱动太老会出现"能连上但抓不到帧"或者"能抓到帧但没有 GPU Duration"这类半残状态。我的习惯是装 GPA 之前先把显卡驱动升到官网最新稳定版，然后在 GPA 的关于页面里核对一下识别到的驱动版本号，确认在它支持的范围内。

还有一个容易被忽略的点是显示模式。全屏独占（Fullscreen Exclusive）模式下，叠加层经常画不出来或者一闪一闪。测试阶段一律切成无边框窗口模式，等定位完问题再切回去验证真实表现。另外多显示器、系统缩放不是 100%、HDR 开启这几种情况都可能让 HUD 的位置和尺寸错乱，排查显示问题时先把这几项恢复成默认值。

2.2 Android 端接入的完整实操

Android 端完全是另一套流程，核心是 adb 和 Agent 注入。先把设备和电脑连上，确认调试通道没问题：

# 确认设备被识别，-l 会显示机型信息，方便核对是否在兼容列表里 adb devices -l # 看一眼系统版本和 GPU 信息，判断能不能拿到硬件计数器 adb shell getprop ro.build.version.release adb shell getprop ro.hardware.egl

设备侧需要在开发者选项里打开 USB 调试，部分机型还要额外允许"通过 USB 安装应用"和"USB 调试（安全设置）"。连接之后 Monitor 会提示在设备上安装分析用的 Agent，按提示走完就行。如果自动安装失败，可以在 GPA 的安装目录里找到对应的 apk 手动装。

# 手动安装 Agent 的典型用法，路径按你本地安装位置调整 adb install -r "C:\Program Files\Intel\GPA\android\GPAAndroidAgent.apk" # 装完之后确认包名存在 adb shell pm list packages | grep -i gpa

Android 端的兼容性和机型强相关，官方发布说明里会列出验证过的设备清单，不要想当然认为手上这台一定能挂上。实际测下来，能不能拿到 GPU 硬件指标取决于 GPU 型号和驱动实现，拿不到的时候你至少还能从系统层面读到帧提交时间和合成器信息，用来判断是不是掉帧，这对大多数问题已经够用了。

注意：Android 端抓帧对性能的扰动比桌面端更明显，抓帧过程中应用可能会掉到十几帧，这是正常的，不要拿抓帧时的帧率去评估真实性能。

2.3 第一次捕获：从 Monitor 到 Frame Analyzer 的完整链路

流程大致是这样：打开 Monitor，选择要分析的目标程序（可以直接启动，也可以附加到已在运行的进程），让程序跑起来进到你想分析的那个场景，然后用抓帧热键触发单帧捕获。默认热键在不同版本里有调整，一般在 Monitor 的设置页能看到并修改，常见的是 Ctrl+Shift+C 这一类组合键。抓完之后 Monitor 会生成一个捕获文件，直接点"在 Frame Analyzer 中打开"就能跳转。

如果要想清楚"抓哪一帧"，我的做法是先让场景稳定运行十秒以上，避开加载、编译着色器、纹理流送这些一次性开销集中的阶段，然后在帧率最低的那个典型场景下按键。更严谨一点的做法是连续抓三到五帧，对比着看——如果某一帧的 draw call 数量或者 GPU 时长明显偏离其他帧，说明你抓到了一个特殊帧，得重抓。

Trace Analyzer 的捕获走的是另一条路，它录的是一段时间窗口。启动录制，让程序跑一段包含问题现象的时间，停止录制之后得到一条完整时间线。这里有个参数值得注意：录制窗口越长，文件越大，同时因为要记录的数据量增加，对目标程序的扰动也越大。我一般先用 10 秒窗口做粗筛，锁定问题区间之后再缩到 2 到 3 秒做精查。

3. Monitor 实时监控：先把瓶颈分层，再谈优化

3.1 三个必须会看的指标

**帧时间（Frame Time）**是一切的基础。GPU 侧的帧时间和 CPU 侧的帧提交间隔要分开看，很多人只看一个总的 FPS 数字，结果在 CPU 和 GPU 之间反复横跳，白折腾半天。先算清楚预算：60 fps 对应 16.67 毫秒，90 fps 对应 11.11 毫秒，120 fps 对应 8.33 毫秒。把实测帧时间和预算一比，超出的部分就是你要干掉的目标。比如实测 22 毫秒而目标是 16.67 毫秒，那你有 5.3 毫秒要抠出来，接下来所有优化工作都围绕这 5.3 毫秒展开，方向感立刻就有了。

GPU Busy（有的版本叫 GPU 占用率或 GPU 活动）反映的是 GPU 在采样窗口内有多少比例的时间真的在干活。如果 GPU Busy 长期在 90% 以上，同时帧时间超标，基本可以判定 GPU 是瓶颈，直接进 Frame Analyzer。如果 GPU Busy 只有 40% 而帧时间依然超标，问题多半在 CPU 侧或者同步逻辑上，这时候该看的是线程视图而不是 draw call 列表。

GPU 频率这个指标经常被忽略，但它能解释很多诡异现象。移动端和轻薄本上，GPU 会因为功耗或温度策略降频，你在调试阶段看到的帧率可能比用户实际体验的好得多，也可能反过来更差。做对比测试时，把 GPU 频率和温度一起记录，确保两次测试的硬件状态可比。

3.2 线程视图：CPU 侧等待到底等在哪

Monitor 的线程视图会把主线程、渲染线程、工作线程的活动画成色块。看图的时候重点找三种模式：主线程长时间空转但渲染线程满载，说明渲染线程是瓶颈；所有线程都在等某个同步对象，说明有资源竞争或者跨线程同步开销过大；工作线程之间负载严重不均，说明任务切分粒度有问题。

这里有个特别实用的技巧：把 CPU 侧的帧提交时间和 GPU 侧的执行时间对齐看。如果 CPU 提交一帧只花 6 毫秒，GPU 执行要 18 毫秒，那 GPU 就是唯一瓶颈，你在 CPU 上做任何优化都是白费。反过来，如果 CPU 提交就要 20 毫秒而 GPU 只花 8 毫秒，GPU 有大半时间在等命令，这时候优先做的是减少 draw call 数量、合并状态切换、把资源更新挪到空闲时段，而不是去抠着色器。

3.3 三个最容易踩的误判

第一个误判是把垂直同步的等待当成性能问题。开了垂直同步之后，帧时间会被硬性对齐到刷新周期，16.6 毫秒和 33.3 毫秒会交替出现，看起来像剧烈抖动。做性能分析时先把垂直同步关掉，测完再打开验证实际体验。

第二个误判是把后台程序的干扰算到目标程序头上。浏览器、录屏软件、杀毒软件的实时扫描都会抢 GPU 和磁盘，我的习惯是测试前把能关的都关掉，至少保证两次对比测试的环境一致。

第三个误判是用平均帧率掩盖卡顿。平均 60 帧但每秒都有一次 30 毫秒的长帧，用户感受到的就是"明明显示 60 帧但就是不跟手"。Monitor 的时间曲线能看出这种尖峰，但更可靠的手段还是 Trace Analyzer 的长窗口录制，把尖峰和当时的系统事件对应起来。

4. Frame Analyzer：一个 draw call 一个 draw call 地抠

4.1 从哪个视图开始看，顺序很重要

打开一个捕获文件，Frame Analyzer 会给出好几个视图。正确的阅读顺序是：先看按 GPU 时长排序的 draw call 列表，把总时长的大头找出来；再看Render Target 视图，确认有多少个渲染目标和多少个 pass；最后才进到具体的着色器和像素级别。

这里有个基本判断原则：GPU Duration 是一个相对值，不是一个绝对值。单次 draw call 的时长在不同驱动、不同硬件上差异很大，你要看的是它在整帧中的占比。一个 0.5 毫秒的 draw call 在 20 毫秒的帧里占 2.5%，可以放一放；同样的 0.5 毫秒在 5 毫秒的帧里占 10%，那就必须处理。列表里排前五的 draw call 加起来通常能占到整帧 GPU 时间的 50% 到 80%，先把它们解决掉，收益最明显。

Render Target 视图能帮你发现结构性问题。如果一帧里有十几个中间渲染目标，每个都要写一遍再读一遍，带宽开销会非常吓人。这里可以做个粗略估算：一个 1920×1080 的 RGBA8 渲染目标，单次全量写入是 1920×1080×4 字节，约 8.29 MB；如果开了 4 倍多重采样，写入量变成约 33.18 MB，再加上解析（resolve）时的一次全量读取，就是约 66 MB 的往返流量。按 60 帧算，仅这一个大小的渲染目标每秒就要吃掉将近 4 GB 的显存带宽。中间目标越多，这个数字越夸张，这也是为什么"少用中间 RT、能合就合"几乎是所有图形优化的共同结论。

4.2 Erg 实验：用二分法把开销定位到具体 pass

Erg 是 Frame Analyzer 里最像"外科手术"的功能。它的核心思路是保持画面结构不变，只改动某一个维度，然后观察 GPU 时长的变化量。常用的实验类型有：禁用某个 draw call、把像素着色器替换成输出纯色、把纹理替换成 2×2 的纯色、降低渲染目标的格式精度、缩小渲染目标尺寸、关闭混合、关闭深度测试。

二分法的具体做法是这样：一帧有 800 个 draw call，你先按顺序禁用前 400 个，看 GPU 总时长掉多少；如果掉得很多，说明问题在前半段，再把前 400 个拆成前后各 200 个继续测；如果掉得很少，就把范围切到后 400 个。这样每轮砍一半，十轮之内就能定位到具体那几十个 draw call。实际做的时候不用这么机械，因为列表已经按 GPU 时长排好序了，直接从最贵的几个开始做单点禁用通常更快。

几个我常用的实验组合和它们能回答的问题：

• 禁用整个 pass：这个 pass 值不值这些时间？能不能降频执行、能不能挪到低分辨率缓冲里做？
• 把像素着色器替换为纯色：这个 draw call 的时间到底花在着色上还是花在光栅化和带宽上？替换之后时间大幅下降，说明是着色器算术或纹理采样的问题；几乎没变化，说明瓶颈在填充率、深度测试或者带宽。
• 把渲染目标降到 1×1：几乎能直接量化出这个 pass 的"帧缓冲写入 + 混合"开销，因为它把填充压力压到了最低，但保留了顶点处理和状态设置的成本。
• 把纹理替换成纯色：专门验证纹理采样的开销。如果替换后时间明显下降，接下来就该去看纹理的尺寸、格式、mipmap 是否完整——一张没有生成 mipmap 的 2048×2048 纹理，在远处表面被采样时会严重浪费纹理缓存，这是移动端和集显上非常常见的性能黑洞。

注意事项：Erg 实验会改变渲染状态，画面会出现各种奇怪的结果，这是预期行为。判断依据是 GPU Duration 的变化量，不是画面好不好看。另外，做连锁实验时要一次只改一个变量，改两个以上你就无法判断是哪个改动的贡献。

4.3 Pixel History 和着色器反汇编的实战用法

Pixel History 解决的是"这个像素到底被谁写了"的问题。在渲染结果上点任意一个像素，工具会列出这一帧里所有影响过它的 draw call，以及每次操作的结果：通过、被深度测试丢弃、被模板测试丢弃、混合后的颜色值。我遇到过一次典型的过度绘制问题，画面上一块半透明 UI 区域看起来平平无奇，Pixel History 一拉出来发现有 11 个 draw call 都在往上叠，每个都做了完整的混合，把这块区域改成一次绘制之后省了 1.4 毫秒。这种问题靠看代码是发现不了的，因为代码逻辑完全正确，只是效率低。

着色器反汇编视图能直接看到编译后的指令序列。看的时候别逐行读，抓几个关键信号就行：指令总数是否异常多、有没有出现大量的分支、纹理采样指令是不是集中在循环里、精度限定符（比如 mediump 和 highp 的混用）是否合理。有个很实用的判断方式，把反汇编里的采样指令数和实际纹理绑定数对一下，如果采样指令数远超预期，说明代码里有冗余采样或者在循环里反复采同一张图。

反汇编视图还有一个高阶用法：结合 Erg 的"替换着色器"实验，你可以把原着色器换成一个手工精简版，逐步加回原有逻辑，每加一步测一次 GPU 时长，最终找出到底是哪几行代码吃掉了时间。我靠这个办法在一个后期处理着色器里找到过一个被反复调用的噪声函数，把它换成预计算的纹理查表之后，单个 pass 从 2.1 毫秒降到 0.6 毫秒。

5. Trace Analyzer：抓那些抓不到的单帧

5.1 长时段录制对付偶发卡顿

单帧捕获只能看一个瞬间，但很多性能问题是概率性的：每隔三五秒卡一下，或者切场景的时候卡半秒。这时候要用 Trace Analyzer 的流式录制模式，它记录的是连续的时间窗口而不是单帧快照，文件里包含了这段时间内所有的 API 调用、资源创建销毁、GPU 队列提交和 CPU 线程活动。

录完之后的第一件事是看时间线上的帧时间曲线，把超过预算的帧标出来。第二件事是看这些长帧附近发生了什么：有没有大批量的资源创建、着色器编译、纹理上传、管线状态对象创建。我遇到过的几次典型情况都是这样：帧率本身很稳，但每隔几秒就有一个 40 毫秒的长帧，一查全是新出现的材质在触发着色器编译和管线对象创建。解决办法也很直接，把这些创建操作挪到加载阶段预生成，运行时就再也没出现过。

录制窗口的设置有个经验值：先用 10 秒做粗筛，找到长帧出现的大致位置后，把窗口缩到问题帧前后各 1 秒，也就是 2 到 3 秒的精查窗口。窗口越小，记录密度越高，细节越清楚，同时对目标程序的扰动也越小。

5.2 CPU 和 GPU 时间线对齐：找同步点

Trace Analyzer 最有价值的用法是把 CPU 线程活动和 GPU 执行队列画在同一条时间轴上。画出来之后你会发现很多"看起来并行其实串行"的问题：CPU 提交完一批命令后必须等 GPU 回读某个资源，GPU 执行完之后 CPU 又要等一个查询结果，两边交替等待，整体利用率上不去。

典型的三种模式和对策：CPU 提交一阵停一阵，节奏和 GPU 执行块对齐，说明存在同步回读，去查有没有查询结果等待、有没有资源被同时读写；CPU 一直在提交但 GPU 队列很空，说明提交过于细碎，每次提交的命令量太小，考虑合并批处理；GPU 一直在干活但 CPU 有明显的空隙，说明 CPU 侧有别的开销在挤占时间，比如资源加载、脚本逻辑、物理计算。

交叉验证这一步很关键。工具给你的时间数据本质上是驱动上报的估算值，如果有条件，在代码里自己埋 GPU 时间戳查询做对照，两边对得上，数据才可信：

// DX12：在关键 pass 前后打时间戳，和 Frame Analyzer 的 GPU Duration 交叉验证 D3D12_QUERY_HEAP_DESC heapDesc = {}; heapDesc.Type = D3D12_QUERY_HEAP_TYPE_TIMESTAMP; heapDesc.Count = 2 * kMaxPasses; // 每个 pass 需要起止两个时间戳 device->CreateQueryHeap(&heapDesc, IID_PPV_ARGS(&timestampHeap)); // 提交时在 pass 开始和结束各插一次 commandList->EndQuery(timestampHeap.Get(), D3D12_QUERY_TYPE_TIMESTAMP, idxBegin); // ... 该 pass 的绘制命令 ... commandList->EndQuery(timestampHeap.Get(), D3D12_QUERY_TYPE_TIMESTAMP, idxEnd); // 解析回读之后换算成毫秒 UINT64 freq = 0; commandQueue->GetTimestampFrequency(&freq); double ms = (endTs - beginTs) * 1000.0 / static_cast<double>(freq);

Vulkan 侧的写法思路一样，用vkCmdWriteTimestamp在关键阶段前后各写一次，注意timestampPeriod的单位换算就行。手工埋点的好处是能拿到连续多帧的数据，用来看某个 pass 的耗时是否稳定；而 GPA 给的是单帧的精确分解。两者结合，判断会可靠得多。

6. 踩坑实录：问题、原因和怎么绕过去

6.1 抓不到帧、挂不上进程的速查表

这类问题占了日常使用的绝大部分时间，我把遇到过的整理成一张表，按顺序排查基本都能解决。

这里单独说下"权限级别"这个坑，它在实际工作里出现的频率高得离谱。Windows 上，如果目标程序以管理员身份运行，而 GPA 以普通用户身份运行，注入基本一定失败，而且失败得悄无声息——你只会看到列表里那个进程灰着，点也点不动。养成习惯，两边用同样的权限级别启动。

还有一个隐蔽情况是嵌套注入冲突。如果你同时开了其他图形调试或者录屏工具，它们可能都在往目标进程里注入库，互相打架的结果就是崩溃或者数据错乱。做性能分析时，一次只开一个工具。

6.2 数据好看但手感不对，怎么解释这个矛盾

这种情况我遇到过很多次，原因基本落在三个方向上。

一是测试帧不代表典型帧。抓到的恰好是一个刚加载完、缓存全热、粒子特效还没起来的帧，自然漂亮。解决办法是连抓多帧做分布对比，看中位数和最差的那些帧，而不是看最优解。

二是帧率稳但输入延迟高。帧率只反映单位时间内出图的次数，不反映从玩家操作到画面更新之间的时间。如果应用有 2 到 3 帧的缓冲队列，帧率依然能到 60，但操作感觉滞后。排查思路是看 CPU 提交和 GPU 呈现之间的队列深度，把缓冲帧数降下来。

三是特定硬件上的行为差异。集显和独显的带宽差距可能有好几倍，在独显上占比 3% 的 draw call 换到集显上可能变成 15%。做优化时目标硬件是什么，就用什么测，不要拿高配机的结果去代表低配机。

实操心得：建立自己的基线库。同一个场景在固定的硬件、固定的驱动版本、固定的设置下跑三次，取中位数记下来。以后每次优化之后对比这个基线，比看绝对数字靠谱得多，也能立刻发现"这次的改动其实让某些 pass 变慢了"。

6.3 我自己用下来最省时间的几条经验

第一条，抓帧之前先写清楚你要回答的问题。是想知道哪个 draw call 最贵，还是想知道某个特效值不值，还是想知道某次改动有没有效果。问题不同，抓的帧、看的视图、做的实验都不一样。我以前经常抓一大堆帧然后挨个翻，最后发现真正有用的只有两三个，浪费的时间比分析本身还多。

第二条，优先处理结构性问题，再抠微观细节。把一个 15 个中间 RT 的流程合并成 6 个，收益通常远大于在某几个着色器里抠零点几毫秒。我做过一个项目，前期花了大量时间优化单个着色器，累计省了 2 毫秒；后来把渲染流程重新梳理，砍掉了四次全屏往返，一下省了 7 毫秒。工具能帮你精确测量，但先看结构再看细节，这个顺序不能反。

第三条，每次只改一个变量，改完立刻测。图形管线的各个阶段高度耦合，你同时改了纹理格式和混合模式，最后快了 1 毫秒，你根本不知道是哪个起了作用，更不知道哪个可能反而拖了后腿。把改动拆成单变量，用 Erg 快速验证，效率反而更高。

第四条，把 GPU 时间戳埋点当成常规工程实践，不要只在出问题的时候才临时加。稳定的、随构建一起走的性能埋点，能让你在没有分析工具的机器上、在用户的实际环境里也拿到数据。GPA 是显微镜，埋点是体检报告，两样东西各管一段，缺一不可。

第五条关于文件管理的小技巧：捕获文件里包含了完整的资源和状态信息，体积往往不小，一个大型场景的单帧捕获轻松上百兆。给捕获文件起名的时候带上日期、硬件型号和场景名，比如"20240512_集显_主城多人_60fps目标"，过几天再回头对比的时候会感谢自己，不用对着一堆capture_001.gpa猜哪个是哪个。