针对 Apple GPU 优化高端游戏

欢迎来到WWDC开发者大会 嗨 我是乔纳森梅茨加 我是Apple Metal生态系统团队的 成员 我们会与游戏开发者合作 帮助他们利用我们Apple的 图形处理器 达到最佳的图形效能 我和达斯汀将会展示我们如何优化 Apple图形处理器上的高端游戏 在这个视频中 我将会介绍我们优化游戏的程序 然后 我将会展示在《博德之门3》 与《地铁：离去》这两款游戏中 所使用的各种优化方式 最后 达斯汀将利用 《神界：原罪2》 这款游戏进行工具演示 他会同时介绍Xcode 13的 图形处理器时间表 让我们开始深入探讨优化 所以在过去一年中 我们和拉瑞安工作室 以及4A Games一同合作 寻找针对Apple图形处理器 调整游戏图形效能的方法 我相信您会很高兴能了解这些细节 我想花点时间感谢 拉瑞安工作室与4A Games 允许我们在本次报告中 展示开发素材 回顾过去一年来 我们分析了许多游戏 并确认了会影响图形效能的常见情况 您可能有兴趣找机会 优化您自己的游戏 所以我们在此会议中 强调了我们的图形处理器 是如何特别有助于 查出这些问题的范围 并提出解决的建议 而我想特别分享一些 我们团队所运用的守则 帮助开发者优化他们的游戏 当我们在优化图形软件时 抱持着定义、如何解决特定问题的 一套特定的方法或一组守则很重要 所以 让我为您展示 包含四个步骤的流程 首先 您要先选择搜集 或测量哪些数据 这会帮助您了解 游戏中所发生的情况 一旦您开始测量数据后 您必须选择一些效能上的目标 或是您测量结束后的目标 您可以决定在游戏中的位置 获取图形处理器的帧图像捕捉 与Metal system trace 场景复杂性、图形设定 以及其他对你而言很重要的指标 如帧生成时间 然后您分析数据 以了解引擎的行为 深度分析能帮助您 找到瓶颈所在 一但您知道造成瓶颈的原因 您就可以修改游戏 但通常您一次仅会挑选一到两个部分 这样您才能了解每次改变 所带来的影响 最后 将新的测量结果 与旧的进行比较 以验证您修改的结果 由于优化是一种程序 您会不断重复这个过程 直到达成您的效能目标 对于这些游戏 我们使用 Xcode的Metal Debugger 帮助我们了解它们的效能 以及它们的帧图建构方式 我们也使用Instruments中的 Metal System Trace 来了解游戏效能随时间的变化 保存GPU trace的文件 与Instruments trace的文件 是个很好的主意 您就能保有您的前后数据 包含优化前后的数据 所以 我列出了一个您能在游戏中 考虑或寻找的事物的清单 正如我所提到的那样 Xcode和Instruments 是帮助您更了解您的 Metal应用程序的良好工具 优化是指在各个不同方面 从着色器效能 到内存带宽 达到最佳的成果 另一方面则是让您的顶点、片元 与计算的工作量 之间呈现良好的重叠情况 在渲染飞行中的几帧时 某些Apple图形处理器 能重叠这几帧的工作量 我将会展现一些指标 帮您处理资源的依赖项 这可能会防止前述重叠的发生 由于一些开发人员在着色器上 会使用自定义作业流程 我会展现编译器的设置 将如何影响效能 最后 我将谈谈如何 减少冗余绑扎的影响 让我们从拉瑞安工作室的 《博德之门3》开始谈起 《博德之门3》是一款基于20年 游戏历史的RPG游戏 其电影般的视觉效果非常突出 我们与拉瑞安工作室的合作 让我们了解他们是如何 针对Apple图形处理器 优化他们出色的渲染引擎 首先 我们从图形处理器的 帧捕捉开始 如我们在此看到的被破坏的海滩场景 然后 我们将场景分解成一个帧图 帧图是每个渲染通道的 顺序与目的分解 高端游戏有许多专门用于 实现某种视觉效果的渲染通道 如环境光遮蔽、阴影映射 后期处理等 《博德之门3》的帧图很复杂 所以这是一个简化过的版本 通过Xcode的Metal Debugger 我们能捕捉图形处理器的轨迹 通过它看到游戏中所有的渲染通道 点击显示依赖项 会出现一个可以平移缩放的 可视化界面 它显示了您的渲染通道 是如何依赖于前一个结果上 让您理解发生了什么事 举例来说 我正在放大这个延迟贴花渲染阶段 以获得更多细节 接下来 我会展示Instruments工具 我们花时间利用Instruments trace Metal System Trace 或Game Performance模版来分析游戏 若您想专注在图形处理器的 执行与排程分析上 那么Metal System Trace会是最佳选择 Game Performance则于此基础上扩展 能帮您解决线程阻塞 或散热通知等问题 让我们选择Metal System Trace 来看看我们的引擎 从一帧到另一帧的行为 Instruments让您能沿着时间轴 查看多个数据通道 在此我们发现了第一个问题 渲染通道的工作量过大 过大的工作量可能意味着 我们必须要优化着色器 举例而言 我们看到了一个 长形的计算着色器 占用了帧图的其余部分 我们称这些间隙为“泡泡” 让我们切回GPU trace 并进一步研究这个问题 这是使用GPU trace“之前”的状况 让我们将分组从调用API 更改为管线状态 您可能会发现管线状态 是依执行时间所排序 让我们来看看第一个计算管线 我们可以展开计算功能的细节 以便更仔细地查看它的统计信息 您会发现此处有超过 4500个操作说明 这是个庞大的数量 那么 还有什么？ 让我们看看这个计算功能 正在使用哪些资源 根据输入的数据来看 这个功能最多使用了120个纹理 来产生输出的结果 然而我们发现在90%的时间内 只使用了6到12个纹理 那么 让我们来谈谈 如何改进这个着色器 需要处理许多不同条件的着色器 可以保留更多的寄存器 如此可以减少并行运行的线程量 将您的工作量分割得更小 分派到更集中的着色器去 这样的着色器不需要那么多寄存器 而且可以提高着色器核心的使用率 所以当您发布 图形处理器的工作量时 您应该选择适当的着色器排列 而不是在着色器中选择适当的算法 此外 使用太多寄存器的着色器功能 会导致寄存器压力 当执行单元耗尽快速寄存器内存时 就不得不使用设备内存 这就是在适当的时候使用 如half的16位元类型的原因之一 因为它们相对如浮点 那样的32位元类型 只使用了一半的寄存器空间 在这种情况下 拉瑞安工作室 已经优化了他们的着色器 使用半精准浮点 并决定建立专用的着色器变量 那么 让我们看看发生了什么事 当比较左边框中之前的数字 和右边框中的数字时 操作说明数量减少了84% 分支减少了90% 寄存器减少了25% 纹理读取减少了92% 此着色器变量使用了90%的时间 我们也可以在 Metal System Trace看见这点 注意这里 在trace之前 我们之前所看见的泡泡 而在这里 在trace之后 泡泡被最小化 拉瑞安工作室能够 平均将这个着色器减少8毫秒 这是个巨大的胜利！ 如果您观察您最大量的 管道状态对象与着色器 你可能会发现一个 可以简化的复杂着色器 这在这个着色器的结果 被后面的通道 所使用的情况下这尤其正确 这对于游戏而言是个巨大的改善 但却未达到开发者的效能目标 我们刚刚提到了内存问题 我们图形处理器的一个特性是 在某些条件下可实现的无损压缩 所以 可能是我们不小心设置了标志 或者忘记设置标志了 无损压缩 在它们从图块储存到设备内存时 有助于减少带宽通过压缩纹理 如果您查看Summary页面上的 Bandwidth Insights 您可能会注意到一些纹理的 无损压缩警告 它们会告诉你这些纹理 不能被无损压缩 您必须负一点带宽损失 Metal Debugger也能让您知道为何 无法进行无损压缩 在此我们看到这个是由于标示了 ShaderWrite的使用标志 通过进入内存部分 我们可以看到所有的使用标志 一旦进入渲染部分 我们可以以渲染目标为条件筛选 然后 右键单击表格页首 选择纹理 然后点选使用 现在 我们可以通过使用条件排序 并找到使用了ShaderWrite的纹理 若您在建立纹理时设置了ShaderWrite 或PixelFormatView的标志 您将无法使用无损压缩功能 让我们更详细地来看看这些标志 Unknown、ShaderWrite 和PixelFormatView这三种标志 让您的纹理不会被无损压缩 一般的经验法则是只在有需求的时候 使用这些标志 举例而言 若您使用write()方法 在一个片元或计算功能的纹理中 储存数值 就会使用ShaderWrite标志 渲染一个绑扎为颜色附件的纹理 不需要使用ShaderWrite标志 如果你只需要 以不同的顺序读取组件值 就不要设置PixelFormatView选项 相反地 我们使用swizzle pattern 建立一个纹理视图 来指定新的顺序 同样地 若您的纹理视图只在 线性空间和sRGB之间转换 那就不要设置PixelFormatView选项 查看文件以了解更多信息 优化着色器和无损压缩 是帮助我们解决问题的两种技术 但另一个问题在于 如何让顶点、片元和计算渠道之间 进行良好的重叠 让我们看看两种优化 跨渠道工作量的方法 首先 我们再次看看 我们的Metal System Trace 在此我们可以看到 顶点、片元和计算渠道的低重叠度 如果能改进一下 让图形处理器忙起来就会很好 一种解决这个问题的方法 是看我们能否在帧图中重组编码顺序 换言之 我们想把这个工作 转移到顶点阶段占用率很低的地方 我们希望更早处理这些顶点 以及早期渲染通道的片元阶段 我们可以把帧图 看成是一个渲染任务的列表 就像这个伪代码的例子一样 达到良好的重叠情况 可以像改变帧图中 渲染任务的顺序一样简单 某些任务可能会依赖早先的任务结果 但并非总是如此 事实证明 CascadedShadowBuffer阶段 这个大量运用顶点着色器的阶段 可以提前被移到前几个任务去 因为它有较少的相依性 现在 我们看到我们的低重叠区域 在顶点和片元通道的利用上变得更佳 让我们又获得了另一个一毫秒 但我们还可以试试 另一种优化 游戏通常在飞行模式会有二到三帧 因此 我们基于图块的延迟渲染 或者说TBDR架构的图形处理器中 一个很酷的特性在于 当两个帧之间没有资源依赖时 可以重叠它们的工作量 那么 我将告诉您如何 优化这样的可能性 让我们再看看Instruments中的 图形处理器轨道 你可以看到对于这些帧的处理 几乎是连续性的 这是由使用blit编码器 更新恒常缓存所造成 比如每一帧的动画数据等等 更新恒常修正数据 为了有效使用独立图形处理器 我们从CPU上的共享缓存blit 到图形处理器上的私有缓存 这将用于渲染帧图 这种策略对于具有独立内存的 图形处理器来说很有效 这也是您这样做的前提 如果您的设备有一个统一的内存架构 那么就没有必要使用blit编码器 来复制您的数据到私人缓存中 但当你在环形缓冲区 使用共享缓冲器时 要注意同步处理的问题 因为当中央处理器 写入其正在读取的数据 就会发生图像损坏的状况 我们实际操作示范 在图表中我们可以看到 帧编码与帧渲染模式 我们用不同颜色区分 在帧起始时更新的共享缓冲器 蓝色代表缓冲器一 绿色代表缓冲器二 而黄色是缓冲器三 环形缓冲区一般是用来执行队列 尤其是需要占用紧凑的内存时 这样的安排下 数据的竞态条件不会发生 因为共享缓冲器数据的写入与读取 是互斥的 帧编码与帧渲染在执行时 期间很常出现迟延的情况 这在帧渲染开始的时候 会造成移位 只要迟延的状况不会太久 竞态条件就不会发生 可是如果迟延的现象持续加剧 那就会造成数据的竞态条件 也就是图形处理器执行帧渲染时 线程同步更新共享缓冲器 此时如果帧的组件与此数据息息相关 就会损害图像质量 以《博德之门 3》为例 移除专用缓冲器与位图编码器 则会消除同步点 不过也会导出竞态条件 这会影响专用缓冲器与位图编码器的 时序抗混淆渲染传递 那么 来看看该如何避免这种状况 要避免竞态条件的产生 你需要确保你所写入的资源 与图形处理器正在读取的 是不同的资源 例如你可以使用 完成处置器 等到安全时 才在你的编码线程更新共享缓冲器 这里向各位说明如何避开等待过程 在维护完成处置器的同时 在环形缓冲区外加一个缓冲器 就可以不用等待 在底端的图表中 外加的缓冲器以紫色显示 内存损耗与使用离散的 图形处理器时相同 如果你需要保存到内存 而中央处理器的等待时间 不会影响游戏的帧速率 你就能使用三个缓冲器 我现在用代码 跟各位说明如何轻松决定 需要产生几个共享与专用缓冲器 此代码片段显示如何在初始时间 选择共享与专用缓冲器的数量 缓冲器一旦产生了 接着是检查缓冲器的 内存是否统一 再确认是要产生另一个共享缓冲器 或是要使用专用缓冲器 此额外的缓冲器能有效减少 等待时间对完成处置器的影响 也借此避免数据竞态条件的发生 现在看看来自前一帧的片段工作量 如何与来自下一帧的顶点工作量重叠 视场景而定 大致上多出一到两毫秒的时间 这个方式不仅能运用在 这案例中看到的常数缓冲数据 也适用于所有 从中央处理器移转到 图形处理器的数据 我们来复习一下 通过以下的优化步骤 拉瑞安工作室达到预期中的理想效能 优化运算量 让最大的着色器减少磁泡 采用保真压缩来提升 带宽 与顶点和片段工作量重叠 借此强化图形处理器的使用效能 并检查 会防止帧重叠的资源相依性 完成上述步骤 拉瑞安工作室不仅 效能达标 在游戏的帧时间上 也进步33% 现在来看不同的优化模式 以《地铁：离去》这款游戏为例 《地铁：离去》以史诗般的剧情著称 这款游戏的电玩系列 需要强大的视觉效果 在采用我们建议的优化模式后 4A Games也达到预期中的效能表现 来看看《地铁：离去》的 游戏场景 《地铁：离去》运用定制的工作流程 将渲染命令转换为Metal API命令 这在跨平台游戏中很常见 他们使用的转换层 已优化Metal 但当两个复杂的系统一起运作时 仍会有问题产生 因此需另外调谐系统效能 以期能达标 跟前一款游戏的相同 也是先了解帧渲染是如何执行 新款的渲染器具备不同的技术 首先要了解的是高阶帧图 我们也先分析图形处理器追踪 这能有效帮助我们了解游戏效能 首先从图形处理器时间开始 这部分的效能与开发者的预期有落差 现在我们来找出着色器或是管线 这是最费时的步骤 我们一样依照管线状态分类 并从运算量最庞大的管线开始 这边很快看过它的统计 与总体数量比较 看得出来算术逻辑单元指令数量庞大 意思是此着色器计算程度很复杂 同时看到着色器所使用的缓存器 数量也挺高 由特定着色器所运作的缓存器数量 会直接影响着色器运作时 工作负载的衡量 缓存器数量越高 图形处理器同步 所需进行的工作量就越少 有时这就是个复杂的着色器 例如这个案例中的 屏幕空间环境光遮蔽就需要大量的 计算与缓存器 但是有时候 编译器的设定会影响指令的产生 还有缓存器的配置 这个是着色器编码程序的选项 结果显示这个着色器 是在快速计算旗标关闭时编译的 快速计算能让着色编译器 优化各项指令 同时也默认允许 Metal着色编译器 不过有时也会发生 利用定制着色器的工作流程 来关闭编译旗标 我们发现这个案例中 4A Games用来调用编译程序的转换层 把不使用快速计算设成预设动作 什么是快速计算？ 快速计算是一系列优化 浮点算数的设定 用来换取速度与正确度 例如我们可以假设没有网络应用节点 无限大或负零可以是结果或自变量 快速计算优化 也能用在代数等价变换 这可能会影响浮点结果的精准度 但绝大多数的情况下 快速计算是游戏的首选 能显著提升性能 尤其以算术逻辑单元为主的 案例更显著 会建议你先检查编译器的选项 确认启用快速计算 特别是如果你的着色器 并没有我刚才所提到的相关设定

快速计算旗标是以 前后端编译器模式运作 当你在建立着色器来源时 前后端编译器会选择快速计算功能 这会运用于中间代码 这样能提示前后端编译器 产生更多最佳的图形处理器机器码 你可以看到 左边的指令与缓存器的计数器 在着色器重新编码后的改进 显示在右边的方框中 因此在变更转换层的行为 启动所有着色器的快速计算后 运用内建游戏基准 在测试工作量时帧时间减少21% 接下来我想讲的是冗余连结 回到概述页面 重温一下对API的理解就能知道 在执行帧渲染时 有许多冗余连结 冗余连结可以是资源 例如贴图 缓冲器和取样器 或是渲染状态 例如深度模板状态与视埠组态 重复出现的连结状态 给编码带来负面影响 但冗余渲染 状态的变更也可能 会影响图形处理器的时间 这里看到的是Metal System Trace的 编码与图形处理器时间 一个特定帧需耗费8.5毫秒 将所有的指令编码 另外图形处理器需花费22毫秒 渲染这幅帧 在调查冗余连结的成因时 我们发现可以修改转换层 以减少冗余连结 这里通过一个代码的案例 跟大家说明 如何检查并减少冗余连结 先不将贴图直接连结到编码器 取而代之的是提前快取贴图 只在它们变更时才连结 若要最小化与API的交互作用 可以通过“设定片段贴图”的方法 设定所有的贴图 而不是将贴图依序设定在循环中 此外 你也可以同样运用 在其他着色器阶段与连结型态 像是缓冲器、取样器和渲染状态 一起了解Metal System Trace 发生的情况 视场景而定 4A Games能减少 30%到50%的编码时间 这是因为转换层无需不断 连结同样的资源与渲染状态 但图形处理器时间也减少 约三毫秒 整体而言 它们游戏基准的速度提升了15% 如果出现几个冗余连结的警告 这问题不大 不过成千上百的冗余连结 肯定会产生影响 所以避开冗余连结 能再额外减少15%的平均帧时间 这两点改进后 A4 Games便能 达到原先预期的效能目标 我概述一下刚刚所学到的概念 包括为Apple的图形处理器 优化《地铁：离去》 首先如果你使用的是 着色器的定制工作流程 请先检查编译器的设定 以确保Metal应用程序 是使用最佳选项 如果Metal Debugger出现很多 冗余连结的警告 告诉你一个技巧 减少编码与图形处理器时间的负荷 也能将此技巧运用在引擎 或是你正在使用的转换层上 现在把时间交给达斯汀 由他来跟各位解释《神界：原罪2》 同时示范Xcode图形处理器 新时间线的功能 谢谢乔纳森 嗨 我叫达斯汀 我任职于Apple图形处理器软件小组 今天来跟大家示范 如何优化 拉瑞安工作室推出的热门游戏 《神界：原罪2》的早期组建 去年拉瑞安工作室宣布 其广受好评的 角色扮演游戏《神界：原罪2》 玩家将能够在iPad上享受 拉瑞安工作室去年用尽洪荒之力 将游戏优化 通过Apple图形处理器 让游戏顺畅运作 也让玩家尽情享受游戏 成效显著是因为拉瑞安工作室善用 Metal Debugger 与Metal System Trace的工具 今年在Xcode 13新增的图形处理器 更是提升这些工具的使用效能 我先从《神界：原罪2》的 一幅帧说起 是我稍早截取的 现在的概述页面里的帧总览 在各位接下来游戏除错与优化时 会引导大家 从概述页面我们可以很快找到 Metal Debugger所有好用的工具 其中包括最新的图形处理器时间线 只要在效能页面轻松点击 就能存取 我现在开始示范 介绍最新的图形处理器时间线 时间线的设计 参考了Apple图形处理器独特的架构 能让每个图形处理器 管线阶段同时运作 为了达到最大效能 我们必须 最大化重叠让所有管线阶段满载 新的时间线能让你轻松检视 时间线由两个区段组成 上方是图形处理器区段 每个管线阶段 图形处理器由各自的磁轨组成 这样大家能方便检视 哪些阶段正在执行或同步运作 下方是计数器 包括筛选过的重要计数器组 例如着色器占用率、带宽 效能限制器 这些能让我们 深入了解在整个工作量期间 图形处理器系统效能的变更 图形处理器磁轨中的编码器具备 大量有用的信息 轻松点击就可取得 点击渲染编码器 就会带出时间线的侧边列 显示目前已选取对象的信息 这里的侧边列显示 渲染通路信息 像是贴图细节 载入储存动作 还有绘制调用的次数 要注意的是渲染编码器 是由两个着色器具阶段组成 顶点和片段阶段都有加强显示 假如选的是片段阶段 侧边列包含所有时间线中的编码器 可依照时间排序 此外 由于我们能够延伸片段磁轨 以显示着色器的时间线 而时间线则显示 执行期间 所有编码器使用的着色器 这样也能快速辨别长期执行的着色器 还有哪些着色器平行运作 片段磁轨也有 两个额外的磁轨能执行载入存储动作 这个功能让用户有效了解 图形处理器何时在局部和主要存储器 加载和存储附件贴图 这是重要的考量 尤其是为了减少带宽的使用 选择着色器能在时间线中 标示出所有的区域 我们也能从侧边列中的编译器统计 与执行期效能度量得到更多的信息 延伸着色器时间线会显示 每个着色器所在的磁轨 这很有帮助 能让人了解图形处理器工作量流程 以及着色器执行次序 现在各位应该比较了解 最新图形处理器时间线的功能 并思考之后能如何全程运用 我现在为大家示范如何轻松 使用图形处理器时间线找出效能瓶颈 许多因素会导致着色器的效能不彰 其中一个是缓存器压力 当出现这个状况 图形处理器的快取暂存内存 就会不敷使用 需换用主存储器 一组高数值的算术逻辑单元限制器 不足以显示 效能瓶颈 最多只能显示着色器的复杂运算 不过若同时发生 着色器占用率低的情况 可能是着色器出现缓存器压力 使得着色器运作变慢 这是我今天想要示范的重点 所以我把算术逻辑单元磁轨 和着色器占用磁轨 钉选在时间线顶端 点击左边的“增加”就行了

现在快速检视这两组磁轨 我首先注意到的是 在这个区域 可看到算术逻辑单元电路产生尖波 而着色器占用率则同时降低 这边特别强调时间线上的一个区域 看看需要多久才会执行动作 请注意当我这么做时 侧边列的计数器 会依照所选取的区域更新动态 这个区域花费3.7毫秒执行动作 现在放大画面仔细看 我们遇到的问题 是与环境光遮挡传递的 前四个编码器有关 这边我们从着色器的时间线 来看看使用了哪些着色器 刚才的问题与这个着色器有关 因为只有它在运作 侧边执行期效能度量显示这组着色器 除了算术逻辑单元运算密集之外 浮点运算也很密集 一起来看看 浮点利用率磁轨 可以看到 当我把光标移到这个磁轨时 这组着色器只有使用浮点指令F32 浮点指令F16则是0% 我们可以从时间线 直接游移到右边的着色器来源 然后点击打开着色器 在这个来源编辑器里 有着色器来源的示范简化版 我们也能在来源 通过着色器分析工具 看到每行成本的信息 把光标移到着色器分析工具饼图上 图表确认了这个功能 有可能造成缓存器压力 因为此功能的算术逻辑单元 和浮点运算都很密集 这种情况就适合使用浮点指令F16 可以让缓存器数量加倍 这样就不需要 浮点指令F32的完全精确 这能有效降低缓存器压力 Metal Debugger让这类操作很好上手 可直接在来源编辑器里变更原始码 我来这里做变更 使用更新版的着色器 这个更新版本混用了 浮点指令F32与浮点指令F16 改好后 点击重新“加载着色器” 底端的按键会触发 着色器更新 这样就能 重新编译和分析着色器 也能更新每行着色器成本 来看看这个改变所带来的影响 回到时间线 我首先想观察 环境光遮挡传递的前四个编码器 要花费多少时间

这个区域花费大约2.6毫秒 来执行动作 刚才的变更 让着色器的执行时间 改善一毫秒多或者30% 这是很大的进步 看一下稍早的一些计数器 算术逻辑单元运算数值仍旧很高 就一个运算复杂的着色器看来 这是预料之中的事 但要注意的是 目前的缓存器压力比较低 而着色器占用率 则提升将近双倍 这是因为混用了浮点指令F32和F16 也就是使用了 浮点利用率磁轨 图形处理器时间线让我能轻松 判断问题 游移到问题点 然后解决 图形处理器是很好用的工具 不仅能判别着色器效能的问题 也能判断内存带宽与其他问题 希望各位喜欢 全新图形处理器时间线的示范 并且已经开始思考 你将会用来优化游戏的所有方式 让游戏能在Apple图形处理器中 运作得更好 谢谢 请继续观赏最后的WWDC 我们把时间交给乔纳森 谢谢达斯汀的示范 真是太棒了 谢谢各位的收看 很高兴能与各位分享 我们如何与 拉瑞安工作室和4A Games合作 运用Apple图形处理器的功能 这些功能提供许多提升效能的方式 例如保真压缩、重叠着色器工作量 我们的工具像是Metal System Trace 还有Xcode内新图形处理器时间线 能大幅提升各位的游戏效能 最后我还想补充 完整的帧渲染很重要 这能最大化游戏效能 我们的工具在这方面很有帮助 如果各位想了解更多细节 请收看相关的视频 今年WWDC推出的 “Metal debugging 分析与资产生成工具” 或是WWDC20的 “图形处理器计数器 与Metal应用程序的优化” 谢谢收看 我们下次见！ [音乐]