为何M1实测远不及理论性能？ Apple Silicon的性能死结初窥 ...

DungDaj · 发表于 2022-4-25 17:19

来自新西兰的hishnash，一位优秀的Data Scientist和苹果开发者，最近发表了一篇文章，让人很受启发。
所以我想由这篇文章提到的Apple Silicon GPU TBDR构架延伸来谈一谈个人的分析。
为何M1芯片的实际表现远不及理论性能？目前Apple Silicon GPU性能的死结究竟在哪？
其实答案很简单，就是TBDR构架，或者更精确地说是软件对Apple Silicon上的TBDR GPU优化不足。
一： IMR or TBDR ？两大渲染流派终将正面较量？

在苹果2020年宣布Mac全面转向Apple Silicon时，绝大多数媒体都只关注到：Apple Silicon 的CPU 要从x86架构转移到ARM架构。但很少有媒体提及，Mac的GPU也将进行从IMR架构到TBDR架构重大转换。
TBDR作为移动领域的绝对主流，如今却正式进入了消费级桌面GPU的战场。这个战场上目前TBDR阵营的玩家寥寥无几：第一位是苹果（Apple Silicon），第二位是高通（Windows on ARM 所用SOC），还有一些PowerVR IP核授权的显卡商。他们需要从IMR阵营“红绿蓝”三位GPU大厂的虎口中夺食。
此外，Apple Silicon也是目前唯一一个成功进入高性能领域的TBDR架构GPU（上一个冲击高性能显卡失败的还是intel特殊的TBR架构GPU——Larrabee ）

Intel Larrabee 显卡

1.1 “马上渲染模式”——IMR

IMR渲染管线

IMR（Immediate Mode Rendering）就如字面意思一样——提交的每一个渲染要求都会马上开始，这是一种简单而又粗暴的思路。长处缺点都非常明显。假设不用为性能担忧，这样的方式会非常省事。通常IMR的渲染实行的是无区别对待，那些遮蔽处理的部分依旧会被渲染处理（overdraw），这种无意义的读写操作，会浪费性能和带宽。
IMR GPU架构简单直接，但有一个重要缺点就是其渲染命令在执行需要随时读写frame buffer，depth buffer和stencil buffer，buffer位于内存/显存上，这带来了大量的内存带宽消耗。在桌面GPU领域，因为不受功耗带宽制约，IMR一统江湖。
1.2 聪明的“贴图渲染”——TBDR

Apple GPU渲染管线

如果IMR大力出奇迹的做法不可取，那么就有了取巧的方式——TBR（Tile Based Rendering，贴图渲染），它将须要渲染的画面分成一个个的区块（tile），每一个区块的坐标通过中间缓冲器以列表形式保存在系统内存中。这样的渲染方式的优点就是相对IMR降低了不必要的渲染任务，但是需要中间缓冲器。
TBDR（Tile Based Deferred Rendering，贴图延迟渲染）算是TBR的进化，它跟TBR原理相似，但是通过HSR（Hidden Surface Removal，隐藏面消除）操作，可以用极少的系统开销彻底解决overdraw的问题，且不需要在软件层面对物体进行排序，还降低了带宽需求。IMR虽然也可以利用early-z来尝试解决overdraw，但可能需要预渲染z-buffer，综合效率和开销节省仍然不如使用HSR的TBDR。
而在移动平台上，访问片外内存是最消耗电量和最耗时的操作。TB（D）R的低带宽消耗，低功耗正好满足移动设备需求，因此与其在PC端的待遇相反，在移动GPU领域TB(D)R几乎一统江湖。

苹果的官方文档中是这样阐述自己的TBDR GPU的优势：

着色器核心和Tile Memory之间的带宽，比 GPU 和设备内存之间的带宽高出许多倍，并且会随着着色器核心的数量而线性缩放。
Tile Memory 的内存访问延迟比访问设备内存的延迟低很多倍。
Tile Memory 消耗的功耗明显低于设备内存。

换一种理解方式，在架构上，IMR和TBR，是非常典型的的“同一份半导体面积，到底是应该多给缓存，还是应该多给计算单元？”的决策，TBR选择了前者，而IMR选择了后者。
使用同样数量的晶体管，缓存越大，虽然效率提高，但计算单元会减少，峰值性能会降低。桌面端的独立显卡GPU，不在乎功耗，最大限度追求峰值性能，肯定选IMR。而移动端要用电池的设备，大概率会选择TBDR。
1.3 优化难度陡升阻碍Mac专向TBDR

了解了IMR 和 TBDR GPU的设计架构后，虽然看起来TBDR GPU是一种很有竞争力的架构，但一切没有看起来没那么简单。
因为多年以来TBDR GPU上只运行大量手机等移动端的软件和游戏，这些程序对GPU性能的需求非常有限。而有高性能GPU需求的软件和3A游戏全部被IMR GPU“垄断”，所以这些程序和游戏一开始就基于IMR GPU开发，且只对IMR架构进行优化。桌面软件大量相关的从业者也只熟悉IMR GPU，而缺乏对TBDR GPU的优化经验。
所以Mac转向TBDR的第一道也是最大的一道门槛就是：如何让原本运行在IMR GPU上的桌面软件能够运行在Apple Silicon TBDR架构的GPU上，且保证性能不损失。苹果推出的Rosseta 2解决了软件能运行的问题，但是能否让软件充分利用TBDR GPU全部的性能，仍完全取决于软件开发者的优化水平。
让一个软件从IMR GPU完美迁移到TBDR GPU上，难度有多大？开发者可能需要回到软件的图形绘制底层，大刀阔斧地改动渲染管线。下面用两个例子来说明，IMR和TBDR优化存在的巨大差异：

在IMR中，Clear操作会对FrameBuffer中的每个像素进行一次写操作，是一个非常高消耗的指令，因此开发者常常会根据实际情况避免使用这个指令。但在TBDR中，由于所有写入FrameBuffer的数据都来自于FrameData，Clear 操作非常高效且能提升渲染效率，所以在有需要的场景中，反而大力提倡使用Clear。如果直接套用IMR的逻辑进行减少Clear的优化操作，在TBDR中甚至会造成帧率严重下降的“反效果”！

TBDR中还要特别注意避免在一帧过程中频繁更新操作使用frame buffer，从而减少中间数据的保存，否则可能会增加耗时，造成GPU核心 Stall。

苹果官方显然也知道TBDR存在相当的优化难度，所以推出了大量官方文件和指导视频，进一步帮助Mac软件开发者降低难度，加快适配TBDR（Metal）的进度。

苹果官方给出的一部分优化建议

上文提到的很多TBDR 优化不足的问题，影响着全部M1系列芯片（从7核GPU到64核GPU）的性能发挥。此外，还有一些TBDR有关的问题可能会导致GPU性能更严重的衰减，但目前主要影响64核GPU的M1 Ultra芯片，这个问题将会在第二章节详细讨论。
1.4 如何判断软件游戏对TBDR优化的好坏？

通常衡量显卡GPU的实际性能表现，人们习惯用跑分软件或者软件自带的benchmark。但衡量软件对GPU的适配优化程度，却没有现成的benchmark。
不过还是有个简单直接的判断方法：实际功耗/标称功耗。如果一个GPU密集型程序让GPU功耗满载，它不一定优化的好；但如果GPU密集型程序的GPU功耗比满载低很多，那么这个程序一定优化不好。
说到完全不对TBDR做优化的软件或游戏，首先当属《古墓丽影：暗影》
这款游戏原本只是适配的intel时代的Mac（x86 CPU + IMR GPU），现在则完全通过Rosetta 2运行在M1芯片上。M1 Max在2K分辨率的基准测试中，帧数低于入门显卡6500XT，查看GPU功耗仅有15瓦，甚至不到60瓦最高功耗的1/4，GPU的性能发挥非常差。所以类似《古墓丽影：暗影》这样完全通过Rosseta 2转译的且依赖GPU性能的程序，体验会非常糟糕。

《古墓丽影：暗影》帧数对比：一度让众多媒体指责M1 Ultra GPU性能造假

除了游戏，3D建模软件和部分Adobe软件对GPU的性能也存在刚需。
Blender 3.1 虽然已经号称完全适配Apple Silicon，但实际在使用M1 Pro 16核GPU渲染BMW27项目时，GPU功耗只有8、9瓦，大约只有满载功耗的三分之一，渲染速度也很慢。不过Blender也诚实地在公告中说明，针对M1的适配优化尚才开始，渲染速率成倍提升和利用NPU降噪都在开发计划之内。单单最近提交的一个补丁，就让Blender在M1 上的渲染速率提升了足足40%！（P.S. 该补丁由 Apple 公司自己的软件工程师制作并提交给Blender审核）

ADOBE AE适配M1的版本性能大幅提升

ADOBE AE在刚发布的2022版中适配了M1，性能实现了大幅提升。从2020年11月M1 芯片发布算起，AE花了近一年半的时间才完成适配。以下是一些Adobe软件正式版适配M1的时间节点：

After Effects （2022年4月）
Premiere Pro（2021年7月）
Photoshop（2021年3月）
Lightroom（2020年12月）

由此可见，对GPU调用效率要求越高，性能需求越大，那么软件迁移适配TBDR GPU的难度越大，适配所需时间也越长。
那么有没有优化较好的程序呢？
答案：真的有！比如一些用Unity引擎制作的Apple Silicon原生游戏。（《极乐迪斯科》《Tunic》等）
以《Tunic》为例，4K分辨率最高画质，出生点附近，M1 Pro 70多帧；M1 Max 140多帧；RTX 3090 270多帧。M1 Max 的CPU功耗不到3瓦， GPU功耗40W；而RTX 3090的功耗则为400瓦，换句话说《Tunic》中，M1 Max以十分之一的功耗，实现了RTX 3090 50%以上的游戏性能。

《Tunic 》小狐狸大冒险

其实这些游戏在M1上表现的如此之好，并不难理解。因为Unity Engine本身就是一个跨平台游戏引擎，很早就适配了ios设备和Metal图形API，且在移动平台（TBDR架构GPU的大本营）上大放异彩。所以Unity 对TBDR GPU早就有了不错的支持，只要开发者愿意，让Unity制作的游戏在Mac的TBDR GPU上高效运行，并没有那么难。
当然除了Unity以外，一些虚幻4引擎制作的Apple Silicon原生游戏对TBDR GPU适配的也算不错。比如AlexKidman：或许这才是测试苹果M1系列芯片GPU——实际游戏性能的最佳游戏！这篇文章中虚幻4引擎制作的《Myst 神秘岛》，这游戏从一开始就分别基于Metal 2.1和DX12原生开发。不但支持Nvidia的RTX光追和DLSS；还支持在Mac上开启AMD的FSR技术。
对于Mac传统的强项领域，TBDR GPU的适配工作比较乐观。但是M1 Mac想要扩张更多的应用领域，需要突破众多竞争对手的重重包围。不过好在EPIC虽和Apple对簿公堂，但仍积极地为M1 Mac适配UE引擎；Apple更是少见地亲自招聘软件工程师来协助Pytroch社区，加快Pytroch适配Apple Silicon，意图拓展机器学习领域的版图。种种迹象表明，苹果对IMR GPU转移到Apple Silicon TBDR GPU这条路线，十分果决，毫不犹豫，且正在全力以赴......

苹果招聘软件工程师加速PyTorch适配

二：M1 Ultra不够Ultra？百密一疏还是乐观过头？

64核GPU的M1 Ultra应该是目前消费级市场上规模最大的TBDR架构GPU了。但是在大量Mac软件中，却出现了性能衰减问题。这可能是一个跟硬件设计相关的问题，牵扯到UMA架构，还可能和M1 Ultra 如何协同片上“成对”的硬件单元有关。
2.1 UMA架构下M1的特别之处

M1 是UMA架构设计，很多技术细节官方不曾透露，但在Asahi Linux 开发者在适配Linux到M1的过程中，有了很多有价值的发现：
1，M1系列的芯片的页表是16KB的大小，且只为16K系统设计的。MacOS本身始终以16K页面运行，只有Rosetta 2的应用程序最终处于4K模式，所以M1+MacOS没有真正的混合页面大小。
2，M1 的UMA架构实现了I/O透传，因此M1上所有DMA设备（CPU、GPU、NPU等）都可直接访问DRAM。因此存在一个IOMMU由所有DMA设备共享，会比MMU多streamID，Stream Table Entry和CContext Descriptor等特性。
可以合理猜想：为了实现UMA架构，M1 CPU的MMU和和IOMMU可能共享相同的地址空间，指针能够在所有DMA设备之间传递，而IOMMU可能在系统缓存SLC之前。而M1 IOMMU的“快表”—IOTLB因此也与CPU中MMU的TLB有一些不同之处。
3，hishnash原文中提到的“32MB TLB”的表述令人困惑，因为一般TLB大小会用条目描述，我想或许他想表达的是TLB Reach的有关概念，也或许只是一个误用。
而MacOS下虽然无从得知M1 IOMMU页表数据结构，页表级数等等信息；M1 CPU部分的L2 TLB和IOMMU的IOTLB的联系机制也未知。不过A站曾得公开过A14的TLB相关信息：从A13到A14，CPU部分 L1 TLB从128条增加到256条，L2 TLB从2048条增加到3072条。（作为参考Intel Haswell架构 L1 TLB 4K为128+64 条； L2 TLB 4k+2M为1024条。）
这里推测，为保证M1上所有DMA设备同时对大容量DRAM高速访问，IOMMU的IOTLB条目很可能会比A14的TLB条目数要多很多。
2.2 IOTLB miss 如何影响64核GPU？

关于M1 Ultra 64 cores GPU ，hishnash的文章给出了一个比较合理的方向来解释其性能衰减的原因——LTB miss
简单来说，64核GPU性能衰减的根源，来自于本应避免出现在TBDR的架构上的操作——对全局内存过于频繁的IO。（采用TBDR架构的重要出发点之一就是减少GPU对全局内存IO，从而降低带宽需求和降低能耗。）
如果一个重度依赖GPU的Mac桌面程序，简单地移植IMR模式到GPU上运行且忽略对TBDR架构的适配优化，那么本应只在GPU Tile Memory中完成的读写，却可能带来大量额外的全局内存IO。
一方面，全局内存的读写速度本身要比GPU上的Tile Memory要慢得多。另一方面，M1 Ultra 64核规模的GPU在短时间内出现大量全局内存IO时，将通过IOTLB加速地址翻译，而一旦超过了IOTLB 当初设计的极限，会出现大量的miss，就需要通过IOMMU硬件去内存访问多级页表，这会带来非常高的延迟（TLB Penalty）。况且一旦TLB miss，造成的后果可能比物理地址cache miss后果还要严重一些，甚至可能需要多出3～4次的内存IO，才能完成地址翻译。
这两个方面叠加将导致严重的GPU访存瓶颈，进而导致64核GPU中相当一部分核心出现stall，GPU性能会因此严重衰减。（理论上M1 Ultra 拥有两个IOMMU，分别位于两片M1 Max 上，但可能两个IOMMU目前复杂的协同机制做不到1+1=2 ，至于ultrafusion技术是否在此过程中带来了负面效应依然未知，所以不在此讨论）
反而M1 Ultra 48 Cores GPU可能因为更小的GPU规模，即使出现了大量全局内存IO，也未突破M1 Ultra IOTLB的设计极限，所以没有出现严重的TLB Miss。这也可以合理解释，为什么M1 的GPU 在沿着8 cores—16 cores—24 cores—32 cores—48 cores 的规模扩大时，都能保持较为线性的性能增长。而64 cores 的GPU，却在一大部分软件中出现了严重的性能衰减，甚至跟48 cores的性能差不多。
2.3 64核GPU 的实际性能因“程序”而异

Blender可能是典型的IOTLB miss导致性能衰减的程序之一，同一个渲染项目下，64核GPU比48核GPU仅快了百分之十左右。

Blender渲染，64核GPU比48核GPU仅快了13%

当然不同程序的渲染管线可能千差万别，全局内存频繁IO的程度也不同，64核GPU性能衰减的程度自然也大不相同。
比如Redshift GPU 渲染的中，M1 Max 花费11:08；M1 Ultra 花费06:10。M1 Ultra 64核GPU实现了M1 Max 32核GPU 1.8倍的GPU性能。

Redshift GPU渲染时间

3DMark Wild Life EXtreme的跑分中，64核GPU的性能衰减程度也比Blender要小得多。

不同GPU规模下，3DMark Wild Life EXtreme的帧数

当初，在M1系列设计时，
或许是百密一疏，低估了64核GPU所需要的IOTLB上限；
或许是乐观过头，高估了两年过渡期后Mac软件对TBDR适配的进度。
总之，因为可能存在的IOTLB Miss的问题，M1 Ultra 64核GPU的表现让人难掩失望。
也许，这个“软硬结合”产生的问题终将会通过软件的改进（TBDR适配优化）而得到彻底解决。
但就目前来看，大批的头部开发者仍未能拿到搭载M1 Ultra 得Mac Studio，又何谈开始软件优化呢？毕竟“巧妇也难为无米之炊”。
三、总结

有关TBDR相关的问题，按照对M1芯片影响范围的不同，可分成两大类
第一类：影响M1 全系列芯片（Pro/Max/Ultra）不同规模的GPU，GPU的性能发挥严重低于理论值。
第二类：只影响M1 Ultra 的64核GPU版本，在很多Mac软件中，GPU性能未能跟随GPU规模线性增长。
这样看来，即使对开发者的号召力强如Apple，在完成x86（intel）到ARM（Apple Silicon）、IMR架构到TBDR架构这样重大的“调头转向”时，依然面临着软件适配的种种困难，重重挑战。
然而这样的过程，也不是市场上随便一个“玩家”都能玩得起，玩得溜的。所以对wIndows on arm，我们也不必过于苛责了，不是么？
只能期待未来在Mac软件生态彻底解决TBDR适配问题后，Apple Silicon能作为引领TBDR架构GPU的代表，和代表IMR架构的“红绿蓝”三家桌面GPU，真正展开一场史无前例却又精彩绝伦的较量！

显卡优化内容部分翻译自网站文档：OpenGL Insights

fwalker · 发表于 2022-4-25 17:25

文中关于M1芯片使用CPU的MMU和IOMMU来实现UMA架构的猜想，因为没有资料可查，所以参照了AMD的 hUMA 统一内存的实现方式，不一定完全准确。
如果有人知道更多的技术细节，欢迎指正。

Ilingis · 发表于 2022-4-25 17:33

感谢。

		自动登录	找回密码
密码			立即注册

为何M1实测远不及理论性能？ Apple Silicon的性能死结初窥 ...

本帖子中包含更多资源