其实Arm前一阵已经正式发布了TCS23（Total Compute Solutions 23）平台，以及对应的IP产品，包括Cortex-X4、A720、A520这些Armv9架构的CPU IP，最新的Immortalis-G720——也就是基于Arm第五代GPU微架构的新IP，以及更新后的DSU。毫无疑问的，这些IP会成为接下来1-2年手机AP SoC的焦点。
最近Arm特别在中国的媒体技术日上，花较多篇幅去谈这些IP及TCS23平台的组成细节。这应该是Arm自疫情之后，睽违了多年、面向媒体的高抽象层级的技术解析会。Arm从解决方案、CPU/GPU及相关IP、软件、安全四个方面做了比较大篇幅的分享。
几个核心IP应该是普罗大众最关心的，包括全面彻底迁往AArch64的CPU IP，新一代同样支持光追、加入了Deferred Vertex Shading特性的Immortalis-G720 GPU，以及作为hub、最多支持14核的DSU-120（DynamIQ Shared Unit）。这几个组成部分，我们将另外撰文做详述。
国内读者对“TCS”这个概念的熟识程度应该是远不及上述几个名头响亮的IP的。实际上Arm推的TCS23解决方案也已经是第3代了。大部分人对于“解决方案”于Arm IP这套生态的理解，应该就是将IP打包发售。但实际上，TCS是从设计角度，更综合、整体的范围去提升性能和效率的存在。
具体如上图所示，大部分人关心的是处在中间的环节，即Armv9架构及其上的存储与互联一致性、各种核心IP。实际TCS还包括图中的软件、开发工具，以及以先进工艺做Arm IP实施的物理IP。
Arm终端事业部产品管理高级总监Kinjal Dave说：“我们之所以要在解决方案层面做构建，是因为要满足高效性能的新需求，变得越来越难、成本越来越高。所以我们需要采用这种整体性的方法。”
Kinjal说Arm这些年来始终努力在benchmark和真实使用场景之间做平衡：“我们会去看如何在个别IP层面去提升技术，然后我们会看如何确保我们的设计在系统层面协同工具，给合作伙伴完整的性能实现。”随摩尔定律的放缓，以及设计层面各种经典技术的全面上线，这两年单独IP微架构层面带来的性能和效率提升也远不及此前那么大了，从更系统的角度来做考量也是半导体链条上各个玩家的共识。
所以这篇文章我们就从TCS23整体的角度来看看这一代平台的改进，其中会涉及到上述IP，但不会过多深入。另外很难得的是，Arm特别用一个主题演讲的章节去谈了软件改进，包括编译器、SVE2指令、Android动态性能框架等，本文也会略有涉及。我个人觉得，Arm聊TCS23及其软件改进，整体还是比较泛的，着力点还是在“结果”上——但这些内容绝对是移动AP SoC科普的好机会。
本文篇幅较长，可选择性阅读：
Part 1，Arm的TCS23参考设计；
Part 2，系统级解决方案做了哪些改进；
Part 3，软件和工具的优化；
Part 4，这代设计的性能提升幅度情况。
本文就不多提单独IP的性能与效率变化了，包括Cortex-X4相比X3性能提升15%，Cortex-A720相比A715能效提升20%，Cortex-A520相比A510能效提升22%，DSU提升动态功耗表现、针对闲置与低负载场景的新功耗模式，Immortalis-G720性能提升15%、带宽用量降低40%等等；这是另一篇文章将详谈的部分。
不过Arm针对TCS23就FPGA级别做了参考设计，用Kinjal的话来说是representative of real silicon devices。Arm做参考设计的原因“很简单”，一是IP组件越来越复杂，“从单核走向多核，到多agent”；其次是系统中的许多特性是需要跨IP的，比如说这次Arm一直在谈的MTE（memory tagging extention）安全特性；
另外，终端使用场景变得极为多样化，光是需要支持的app就有几十亿，在做设计的时候需要各种取舍、权衡。“所以我们打造了这样的系统设计，加速合作伙伴产品的上市时间，降低采用复杂技术的风险。”
上面这张图就是Arm的TCS23参考设计。大框架上CPU、GPU都用了这一代最新的IP，“以高性能、高效的方式，在运行频率方面选择推荐的CPU集群配置方案”。其中不同核心组成的CPU集群连接DSU-120；借助system cache（SLC）所在的CoreLink CI-700，一边连接到Immortalis-G720 GPU——中间有个MMU-700（memory management unit）单元——图上有两个MMU-700实例，作为translation buffer，也参与Android虚拟化框架支持和DRM内容保护。
这里CoreLink CI-700作为一致存储系统的核心，是所有I/O流量的交汇点（也用于实现MTE）。除了CPU和GPU模块之外，借助NI-700也将所有其他流量，接到DRAM主内存；“提供QoS机制”“不会出现串流、阻塞、抢占的情况”。
参考设计的CPU部分，是1x Cortex-X4, 3x Cortex-A720, 4x Cortex-A520的配置；DSU-120配了8MB L3 cache。Arm认为1+3+4是性能和效率可达成均衡的配置方案。不过实际在多线程性能对比时，Arm也有基于1+5+2的搭配呈现。而且从芯片设计企业的传言信息来看，基于TCS23的设计未来可能会有更为多样化的大中小核规格出现。
Kinjal没有细谈这部分的配置。不过这里主要看的还是系统级别的工作。他强调CPU到内存通道的表现很重要，所以要“优化到DRAM的延迟”。“我们优化了静态延迟和动态延迟。”“动态延迟，是指系统中的多个’initiator’对共享存储资源的竞争。”
“静态延迟优化，是关注DSU的配置选择以及时钟，还有floorplan——优化到内存控制器的路径（原话是minimize the register stages between the system cache and the memory controller）。”“动态延迟方面，我们考虑加载内存系统场景下的动态优先级，也就是GPU、摄像头、多媒体管线同时访问内存的情况。”
CPU模块部分，有两点是Arm着意强调的。其一是“计算集群”的优化。“第一点，利用CPU微架构提升，包括Cortex-X、A7x、A5x微架构，怎么提供最为广泛的动态范围（dynamic range）。第二点，在利用CPU IP支持的电源模式和时钟选择时，提供完整的解决方案（full solution context）——包括L3 cache的功耗降低选择，以及DSU支持的一些逻辑。”
这里“广泛的”“动态范围”应该是指DVFS动态调整，适配各种负载场景、应对不同的性能目标。Kinjal在此强调说，Arm的计算集群达成了很广泛的动态范围，“这对于系统级别的控制固件堆栈（controlled firmware stack）与scheduler配合，达到最佳的运行点（operating point selection）很关键。”这句话的意思是指以最为优化的效率，来针对不同的运行场景，“运行点”自然包括了分配多少CPU资源，如频率、响应、哪些核心参与等等。
如上图所示，TCS23解决方案中的系统控制处理器固件（system control processor firmware）能够与传感器控制框架（sensor control framework）协作，对于CPU核心、DSU集群而言，在不同的“运行点”之间做切换时，亦考量温度与功耗限制。这其中不仅是频率变化，还包括clock gating、时钟调制机制等，在整个CPU集群上做到动态功耗的节约。
虽然谈得还是很泛，但这显然对于我们理解移动CPU的工作过程及其设计是有价值的——而且这些并不是单个IP可体现的。后续文章谈DSU的部分可以关注下不同负载下，CPU工作上的差异。
其二是系统级别，细粒度的电源模式——这也是当代低功耗设计的精髓所在。上面这张图每种颜色代表了针对该模块的电源轨。则很自然地，Arm在此的工作之一就是管理供电的复杂性，其中包含新版DSU的特性。Kinjal说细粒度的power gating（电源门控），核心、集群层面的，都由电源控制固件来管理——这个固件跑在系统控制处理器上。
“跑在系统控制处理器上的固件，与scheduler、操作系统电源管理软件配合工作。”
图形计算相关的部分，Arm强调了3个解决方案层面的关注点，分别是带宽、能效，与GPU和MMU配合对于DRM保护内容、Android虚拟化框架的支持。其中的某些部分，也会在我们后续的IP文章GPU相关部分做更详尽的介绍——比如节约带宽的Deferred Vertex Shading延后顶点着色。
从大方向来看，节约带宽方面的工作包括AFRC与AFBC无损压缩——管线不同阶段的数据压缩始终是GPU IP不变的话题之一，它对于DRAM访问需求的降低，提供更大的发热空间都有价值；还包括CoreLink CI-700支持的IO并发，达成cache维持开销的降低；以及利用较大的system cache容量，并且有个所谓的“memory allocation hints”存储利用优化，“对需要存储在SLC里的内容进行优先级排序”。
能效优化部分，一方面是利用针对每个shader核心的power gating，以及到核心群组的节电模式等。“TCS23解决方案提供了一套完整的参考：Immortalis-G720驱动如何与我们的参考固件堆栈协同，实现电源控制、动态电压与频率的调节。”
另外，“我们在GPU中也实施了积极的clock gating方案，用以管理动态功耗。这套解决方案提供时钟和复位生成逻辑（reset generation logic）的参考，来达成对应的目标。”
而GPU与MMU-700合作，则如前所述，实现对DRM保护内容的安全处理，并对Android Virtualization Framework虚拟化框架做出支持。
解决方案层面，尤可体现成效的是带宽吞吐，以及功耗的降低。“我们在TCS23上，提供了互联方面提升的参考配置，相比于前代提供了通往内存的低延迟和高效的途径。”
结合（1）CPU和整个系统的cache容量增加，包括L2, L3, 和system cache；另外Kinjal似乎提到一嘴，CoreLink的system cache也是独立的电压供电，则在持续工作状态下，“我们编译SRAM实例来控制漏电，提供最佳能效”；（2）前文提到的连接至DRAM的静态和动态延迟优化；
（3）以及floorplan布图规划上物理级实施方案，优化system cache到内存控制器的路径（minimize the register stages between the system cache and the memory controller）；（4）和对于最新一代LDPPR5X-8533内存的支持，达成68GB/s峰值带宽……参考设计达成综合的带宽吞吐，相比于前代提升了33%。
所以在总结性发言里，Kinjal再度强调的一点就是基于TCS完整计算解决方案，“迈的步子是大过IP本身的”，“着眼于端到端系统优化”。这是TCS存在的核心价值。
除了这些比较多人关注的IP之外，如文首所述，TCS作为解决方案还涵盖了工具、软件、物理/POP IP等。这里我们再谈一谈工具和软件，TCS23不仅升级了IP，也升级了软件与工具。Arm终端生态与工程高级总监Geraint North说Arm的工程师中，超过45%都是软件工程师，比较低层级的部分涵盖了驱动程序、Linux内核，往上则有软件框架、性能分析工具、开发者教学、最佳实践等。
软件自然是位于硬件之上的层级，这部分Geraint主要谈了64bit完全迁移、compiler编译器性能提升，以及ADPF（Android自适应性能框架）带来的软件层面的性能提升。
实际上就软件相关的主题演讲，Arm还特别花篇幅去谈了安全，包括MTE、PAC/BTI技术及对应生态——谈到与谷歌、Unity在安全特性上的合作，甚至在MTE（Memory Tagging Extension）技术上，还特别找来快手、联发科、vivo这些合作伙伴站台。不过这次我们不会把笔墨放在安全问题上，即便这个问题就当代移动技术而言正变得格外重要。
有关64位生态迁移的话题，桎梏并不在芯片和操作系统厂商身上，而在最上层的App开发者身上。自11年以前，CPU层面提供64位支持（Cortex-A57/A53），以及2年后Android操作系统跟进，一直到今年Pixel 7作为仅64位Android配置的手机问世，这仍然是个相当漫长的过程。而TCS23是彻底构建起仅64bit支持集群的一代，包括所有的大中小核。
从安全和性能两个角度来看，64位都显然是个更好的选择。安全方面，64bit提供更大的内存地址空间，在地址空间布局随机化（ASLR）等特性实现上会更为有效；也为Arm多番提及的MTE和PAC（Pointer Authentication）提供了实现基础。
而在性能方面，Arm给出了上面这张图。Cortex-A7x系列核心，从A76到A720的SPECint2006性能变化情况：32位与64位应用的性能差别是在逐步扩大的。至Cortex-A710这一代性能差距扩大至33%，且后续的IP上AArch32似乎不再能获得性能红利。Geraint说，这方面的差异很大程度在于Arm将更多的时间、芯片面积用在了64位的优化上，软件层面亦有体现。
“过去几年，我们生态内编译器优化、库优化主要都集中在了64位上。所以如果开发者还选择构造32位程序，那就得不到我们在软件工作上的性能提升了。” Geraint还特别谈到了Arm在64bit生态推进上的努力，包括与谷歌、OEM厂商、不同App Store应用商店的合作，以及在中国国内App Store分散化的情况下，也基本完成了64位迁移的目标。即便历史遗留问题多少都还在，TCS23应当也意味着移动平台的64位攻坚战进入了尾声——下一步Arm准备将64位全面带到数字电视和机顶盒市场。
编译器方面，Geraint说过去3年时间里，LLVM获得了12%的性能提升（基于SPECint2007），从去年到今年则在编译方面得到了性能6%的提升。所以“开发者用最新的工具链重新编译app，则无论用户设备是基于Armv8还是v9，都能获得性能提升”。
不过Geraint还是强调，Arm在LLVM上的投入有很大一部分是集中在了SVE2指令的性能提升的——也就是Armv9架构引入的矢量扩展。
Arm对于SVE2真正产生价值的目标是，“确保完成出色的矢量化工作，包含LLVM已经能够做到的，和LLVM矢量化此前做不到的工作”。也就是在LLVM可实现矢量化工作的基础上，做得比NEON更好，比如scatter/gather指令和predicted指令。
另一方面LLVM 16版本引入了Funtion Multi-Versioning，达成NEON和SVE2代码的共存，并且runtime会自动进行两者间的选择。所以开发者不需要做两份binary或者自己去做CPU检测。这是为兼容性所做的考量。
不过我们知道，现阶段SVE2面临的一个实际问题还是在于利用率，和移动平台是否真正需要SVE2。所以Geraint特别提到SVE2对于图像处理非常适用。
他举了iToF（indirect Time-of-Flight）的例子，即用基于相位差的ToF方法来构建深度图——iToF前些年在手机上的应用还比较广，包括手势、人脸识别等。用Halide在高层级写图像处理算法（以LLVM为“co-generator”），都用Cortex-A720分别在FP32和FP16精度下来跑，则SVE2相比NEON，分别有10%和23%的性能领先。这和SVE2的scatter/gather指令有很大的关系，也就是从内存不连续的部分获取数据的效率。
软件相关的提升，还有个有趣的部分是Android Adaptability Framework动态性能自适应框架（ADPF）。ADPF为开发者提供了一些API，包括ADPF Hint API，Thermal API，Game State API等。比如其中的Hint API，可让操作系统以更快的速度来进行CPU频率、资源的调节，达成性能需求或者节能；而Thermal API显然是温控相关的。
比如具体到PerformanceHint API，这个API存在的价值在于，它能为操作系统提供应用或游戏目标负载的更多信息，那么CPU可以更精准地调控资源——它比Linux内核的scheduler行为更高效。比如DVFS governor需要200ms从闲时状态拉升到最高频率，而在工作结束后，频率还有个缓慢回落的过程。这些行为不够高效。
从应用或游戏直接把负载预期持续时间、目标发给操作系统，调度策略就会高效许多，可以减少掉帧、提升能效。Geraint说，PerformanceHint会话“is aware of core layout”，可确保对应的工作放在正确的核心上，而不需要靠猜。
据说Android将ADPF应用到了SurfaceFlinger（Android负责绘制应用UI的服务），减少了50%的掉帧、节电6%。实际上PerformanceHint API早在Android 12就已经为开发者提供了，而Android 14成为必选项；Unity游戏引擎中，它也作为Adaptability Plugin插件存在。
还有个ADPF Thermal API，Geraint也做了分享，包括在游戏《Candy Clash》里的测试结果。其本质都在为达成更好的游戏体验，基于设备的热状态（thermal state），动态适配游戏画面渲染质量（包括帧率、分辨率、LOD、贴图），则即便是老手机也不会发生过热，而且可稳帧、降低功耗，测试结果是平均帧提高25%，CPU功耗降低最多18%。
ADPF以及Unity的自适应性能特性显然是需要和Arm IP配合的。当然了另一方面这也需要开发者去使用对应的API。这类API理所应当的，不仅成为软件层面性能提升的组成部分，也是Arm加强生态粘性的关键。
就软件和工具，Kinjal聊到了当前市场需求热点之一的AI，机器学习。Arm在这方面的中间件和库主要是Arm NN与Arm Compute Library。
这两者是可基于Arm平台不同处理器——包括CPU、GPU、NPU等来加速机器学习负载的工具。Kinjal说Arm是以季度为单位来发布这方面的软件优化的。今年1月份，Android NN和ACL已经可以在谷歌应用商店下载；到2024年，两者都可以直接在GMS（Google Mobile Services）上直接访问——在更广的范围内，成为Android的NN标准。虽然这两点跟国内用户的关系似乎都不大。
Geraint说，Arm NN和Arm Compute Library进入到GMS，和SVE2面向开发者尽可能做到技术部署的透明，令新技术对开发者而言更简单是异曲同工的。
开发工具相关的，有个促成软件优化的改进，Profile Guided Optimization的性能提升，即开发者通过构建profile来了解应用在真实使用环境下的负载行为，以便更清晰地了解其瓶颈所在，如何做优化。
Armv9架构通过名为ETE（Embedded Trace Extention）和TRBE（Trace Buffer Extention）的扩展，来捕捉这些数据，达成了“基于硬件的追踪”。最终在程序的binary size、追踪捕获数据对性能方面都达成了影响最低。
还有图形相关的开发工具，Kinjal也谈到了，但整体比较泛，这里就不多说了：常规的GPU工具、与游戏引擎合作、为开发者撰写最佳实践文档和培训——据说还都是基于和游戏工作室的合作，分析时下流行游戏的内容。
最后来谈谈可能更多人关心的性能提升数字，其中的绝大部分应该都是上述参考设计的表现提升，也要考虑进软件层面的提升。既然是系统层面的，那就是高层级的系统测试了，对于反映未来手机性能变化应该相比IP层面的性能和能效提升数字更有价值。
首先这个对比是不同游戏，每一帧的DRAM带宽需求缩减。Arm测试了包括吃鸡、原神在内的多款游戏。相比TCS22，最高可达成44%的带宽缩减，平均缩减幅度30%。换句话说就是片外主内存的依赖更低了，这对提升游戏能效表现是很有价值的。
这也对应地带来了20%的功耗节省（测试这些游戏在60fps下持续性能发挥）。“合作伙伴可以自行决定是要选择节能，还是将这部分余量应用到更高的性能上。”Kinjal说。
前文也部分提到了图形计算目标之一的带宽缩减，主要是DVS延迟顶点渲染技术的加入，以及system cache分配策略优化。后续Immortalis-G720 GPU解析文章还会有更详细的阐释。
在GFXBench系统性能测试里，两个比较知名的测试项Manhattan 3.0和Aztec Ruins High中，TCS23分别有21%和20%的性能提升。这是更高的频率、更多的shader核心，外加系统级优化带来的。Kinjal说：“我们预期今年的GPU解决方案，在我们合作伙伴和终端设备上，会有非常惊艳的性能表现。”
需要注意的是，很多同学倾向于将GFXBench的3D图形测试完全归于GPU算力测试。实际上这种高层级的系统性能测试，对SoC上的其他IP，以及整个系统都有占比不低的利用。
CPU方面，Arm主要给的是Geekbench 6多线程测试，和Speedometer 2.1网页浏览测试。需要注意的是，GB6的这个测试，TCS23这边的CPU搭配方法是1+5+2，所以这就不是参考设计了；多线程性能提升27%。
Kinal解释说之所以这样搭配，是因为“多线程测试被越来越多地做对比，也是我们合作伙伴着眼优化的项目之一。包括3A游戏在内的很多场景都要求更多的高性能线程”。“这里我们展示了，新IP及工艺方面的进步令效率提升，可以在TCS23上做到这样的CPU集群配置”。
Speedometer这边是1+3+4，其中还加入了软件优化——即Arm与谷歌就Chromium的合作，开启PAC/BTI安全特性。软件优化达成的更高性能提升，应当有一部分是基于PAC/BTI这类特性占用资源可以非常少。
还有个CPU的对比，是比较CPU的机器学习性能，具体到对象识别、分类、人体姿势追踪等；比的主要就是Int8推理。不同核心的性能提升幅度，相比TCS22如上图所示。
图中右边是GPU的AI超分性能提升达成了4倍。这里面除了CPU、GPU算力加强，也在于Arm NN和Arm Compute Library的进化。
以上就是从解决方案层面Arm阐释的TCS23了。不过Kinjal提到，TCS23是个可伸缩的平台，面向广阔的客户端设备，不只是高端手机设备。比如说Immortalis-G720弹性缩放有下设Mali-G720/G620可选配；而在CPU集群方面，Cortex-A720核心有着对应的可伸缩选项。这些就留到后续具体的IP解析文章中再谈吧。
“我们发布的这些产品将赋能下一代智能手机。”Arm产品营销副总裁Ian Smythe说。实际上他在开篇还展望了未来的TCS设计，如上图，包括名为Blackhawk、Chaberton、Hayes的大中小核，以及名为Krake的GPU，“我们也着眼于未来，接下来几年我们还将在这些IP上努力，来满足合作伙伴的需求。”
文章来自：https://www.eet-china.com/
