上月底AMD在中国发布了期待全新的RDNA4架构GPU，我有幸从蓝宝提前拿到了9070XT 氮动与9070 极地为大家带来第一时间的测试。

9070XT氮动：

9070极地：

AMD RDNA4架构分析：

在RDNA4发布之前，我其实对它的架构细节做过很多猜测，包括寄存器缓存的改进，硬件traversal，以及已经在RDNA3.5上使用的TBIMR之类的，但是最终，大多数都落空了。所以我们来具体看一看架构上有哪些改进。

CU：

RDNA4的CU相对于RDNA3有几项重大改进。

动态分配寄存器

在之前几代里，寄存器是在Shader执行初期就按最大需求来固定分配，但实际在执行过程中，可能只有少部分代码才需要实际用到这么多寄存器，所以固定分配实际会在代码执行过程中造成一些浪费。RDNA4，引入了动态分配机制，仅仅在需要时才分配寄存器，这为CU维持更多的硬件线程提供了可能性。AMD同时提到，CU内加了独立的寄存器块搬运单元，用来加速函数调用时的上下文切换，这个在光追里面非常有用。

实际测试时，我发现PIX已经支持RDNA4的反汇编了。当我在测试代码中分配了过量的寄存器之后，从反汇编可以看到，RDNA4在面对大量寄存器时与前一代并没有表现出行为差异，依然是正常的通过scratch_load与scratch_store将寄存器换进换出。不同的是，RDNA4生成的指令包含了大量暂存提示，这也是RDNA4在访存方面的改进之一，当然这也让它的指令长度从之前的8字节变成了12字节，对于指令缓存的压力会更大一些。另外RDNA4的另一个改进，更加精细的长延迟操作屏障在这里也得以体现，RDNA3中访存操作统一使用vmcnt来计数，而RDNA4中对于buffer load指令使用的是更加细化的loadcnt。最后，我不知道这些是否就是AMD提到的改进，又或者是我测试方法不够完善？等之后RGP更新了，我再详细一些的测试。

标量ALU

CU的第二点改进是标量ALU，RDNA4给标量ALU添加了简单的浮点指令支持，这个改进其实在RDNA3.5中就已经有了。硬件线程中通常包含了很多条软件线程，但是多个软件线程也有时会共用一组数据，这时候用SIMD来计算就不太划算了，所以AMD在GCN时期就引入了一个由四个SIMD共享的标量ALU，用于一些简单的整数计算和控制逻辑。RDNA时代，变成了一组SIMD一组标量ALU，标量ALU比例变高之后，利用率自然下去了，所以这次加入浮点指令，也是为了进一步提高标量ALU的适用场景。

标量ALU的浮点指令支持大部分简单浮点操作，但像除法，超越函数之类的并不支持。浮点操作的延迟基本为4周期，与标量ALU的整数指令相比高了一倍，但相对于SIMD来说还是低了1周期，并且可以和SIMD并行，提高性能。标量ALU的并行表现比较怪异，指令级并行并不能完全掩盖它的延迟，同样线程级并行也不能。多条无依赖的标量SALU指令并发时，平均延迟下降也并不线性，之后有时间再继续研究。

标量ALU的另一个显而易见的好处是功耗。这里我简单测试一下：

再各自理想的工作状态下，RDNA4使用SALU，在更高的频率下仅仅使用84w就接近了RDNA3在150w下才能达成的吞吐率。

光追加速器

AMD在2020年RDNA2发布之后就招募了一批人来做硬件遍历单元。在RDNA3上添加硬件遍历的期待落空之后，大家都把目标瞄准了RDNA4。在去年AMD也确实发布了多个硬件遍历单元的专利。于是在几乎所有人都认为RDNA4一定会有硬件遍历的时候，RDNA4再次的没有加上。不过RDNA4的光追加速器其实也有很大的提升。

首先是硬指标，包围盒与三角形求交单元数量翻倍从4、1，来到了8、2。

第二则是BVH8的应用，实际上前面的吞吐率翻倍之后使用BVH8也是顺理成章的事，BVH8可以减少求交次数，同时降低BVH的内存消耗。

然后是方向性的包围盒，之前生成的包围盒都是同向的，比如遇到某些比较扁平的几何物体，恰好朝向又与包围盒不同，就会导致包围盒巨大而空洞，光线命中包围盒与命中三角形的比例被拉的很大，浪费性能。而RDNA4生成包围盒时会尽量与几何物体同向，尽量减少包围盒的体积，减少无效的包围盒命中。

最后，上面寄存器部分提到的东西，其实几乎都是为了光追量身打造的。光追在求交之后，会调用不同的函数来处理不同的命中结果，并且寄存器使用量在求交前后差距很大，寄存器的高效上下文切换以及动态分配就是为了应对这种场景。

WMMA

RDNA4将WMMA执行单元的宽度加倍了，同时对8bit浮点的支持。在RDNA3中，随着数据位宽下降，性能却没有得到应有的增幅。在RDNA4中，这点也得到了修补，以16bit为基准，8bit下的性能翻倍，4bit再次翻倍。另外稀疏矩阵也得到支持，吞吐率与对手一样，都是相对于密集矩阵翻倍。

这也为FSR4以及neural shader打下了坚实的基础。除开FSR4，AMD在之前的技术演示中也展示了NRC（neural radiance cache），radiance cache其实就是UE5的Lumen同款光照技术，NRC看成是神经网络加持版Lumen也没什么问题。对手Nvidia的neural shader重点演示的也是这个技术，未来这个技术估计会大展拳脚，所以目前买卡我认为就算付出一点传统性能性价比的代价，也尽量买新不买旧。

FSR4图像质量对比：

可以看到FSR4的图片上，两边的草皮清晰度大幅高于FSR3.1，其他地方的纹理细节也更高。对于空中纸片的纹理动画，伪影也更少。

内存

屏障

在现在的GPU设计中，为了应对超长延迟的操作，比如访存，都配置了显式的屏障。用户可以在访存指令发出之后、数据返回之前，继续执行其他不需要该数据的指令，以掩盖访存时的延迟，在最终需要该数据时，设置一个屏障，用于确保数据已经返回。

AMD的屏障使用SALU指令s_waitcnt来完成。比如前面CU部分代码中的s_waitcnt vmcnt(0)，对于RDNA3来说就是表示还在等待中的读内存操作归零之后可以越过这个屏障。再更早的GCN中，屏障只有三种，vmcnt对应所有vector mem指令的访存，lgkmcnt对应lds、gds、constant、message的访存，expcnt对应export。这样的分法非常的粗狂，每种屏障都对应了大量不同的操作，比如vmcnt下肯定至少有读或者写这两种操作。当同一类屏障的不同操作，同时发出时，通过计数这种方式，就很难分清到底哪个操作完成了，最终导致大家一起等它归零，限制了指令并行的可能性。所以从RDNA开始，vmcnt被细化为vmcnt和vscnt，vmcnt对应读，vscnt对应写。RDNA4进一步细分为dscnt、loadcnt、storecnt、samplecnt对应纹理单元、bvhcnt对应光追的BVH。

暂存提示

GPU的内存层次结构相当复杂，访存操作本身复杂度也相当的高，单纯依赖硬件来管理缓存时不现实的，所以RDNA4极大的加强了访存指令中的提示词，让程序员或者编译器得以准确的将数据放在想要的位置。LLVM中列出了如下几种

TH = 0x7, // All TH bits
TH_RT = 0, // 静态
TH_NT = 1, // 非临时
TH_HT = 2, // 高临时
TH_LU = 3, // 最后使用
TH_RT_WB = 3, // 静态(CU, SE), 高临时性带回写 (MALL)
TH_NT_RT = 4, // 非临时 (CU, SE), 静态(MALL)
TH_RT_NT = 5, // 静态(CU, SE), 非临时 (MALL)
TH_NT_HT = 6, // 非临时 (CU, SE), 高临时 (MALL)
TH_NT_WB = 7, // 非临时 (CU, SE), 高临时性带回写 (MALL)
TH_BYPASS = 3, // 跳过

涵盖了大部分可能的状态，为RDNA4提高缓存利用率打下了基础。

L1和L2

RDNA4的缓存也有了一些调整，L2从已经多年不变的1MiB/64bit显存位宽调整为了2MiB/64bit，总容量8MiB，同时L2可以被配置为SE私有模式，也许正因如此，L1缓存现在被改为了L1缓冲，简单的充当CU与L2之间的桥梁。实际上通过观察7800XT上的L1缓存命中率，可以发现它在大部分游戏中都低于20%，基本不能起到一个正常缓存的作用，改为缓冲也更符合它的定位。

稍微测了一下延迟：

整体上来看，如果排除频率因素，按周期来计算延迟的话，实际RDNA4与RDNA3的差别不大，但是L1这一级被移除，让32KiB-256KiB这一节直接落入了L2缓存。不过这个只是理论测试，如果结合L1本身的低命中率来看，可能影响并不大。

压缩

RDNA4支持了更大block的差分压缩，有利节约带宽，不过我手头没有测试工具，现写已经来不及了，等以后再测吧。

命令处理器

AMD在RDNA3上将任务调度器从f32指令集的自定义处理器更换为了risc-v魔改指令集rs64的处理器，跑在了相当高的频率上。改用rs64之后，AMD第一次在Windows上提供了完整的硬件加速，同时对于MDI也有了硬件支持。不过RDNA3对于一般图形任务的调度能力却因此有了一些下降，特别是在早期驱动上，大幅落后于RDNA2，后来经过驱动迭代之后，最终接近了RDNA2的调度能力。RDNA4的实现目前尚不清楚，但是通过3dmark的api overhead测试，可以明显看出比RDNA3有了长足的进步：

D3D12和Vulkan进步高达40%左右。

能耗比

AMD在RDNA3上最令人诟病的一个地方就是功耗过高，换用5nm之后，能耗比相对于RDNA2来说也没有什么进步。RDNA4采用了4nm工艺，理论上4nm只是5nm工艺的小改进，差别不会太大，但明显RDNA4的能耗比却有了长足的进步，所以我们来慢慢分析一下。

SIMD部分

通过限制频率让两张显卡尽可能的达成一致的浮点吞吐率（RDNA4的SIMD依然没有完善的寄存器缓存机制，所以不存在因为架构改良而导致能耗比提升）。结果是9070在CU更少需要更高频率的不利条件下，仍然比7800XT低了40w以上，能耗比硬生生的提升了20%。

TMU部分

TMU部分我使用了压力较大的128bit纹理，两者在同一水平，4nm的些许优势抵消了9070少4个CU的劣势。

ROP部分

ROP部分整体功耗较低，而且9070拥有128ROP，我虽然尽力拉低了频率，但依然难以让双方平手。最终是9070用108w实现了366GPixel/s的吞吐率，7800XT则是129w才实现了248GPixel/s的吞吐率。虽然这样对比起来不太公平，不过考虑到9070的频率依然是高于7800XT的，也可以简单算一下能耗比。结果是9070领先了176%，比较惊人。

几何部分

几何部分和ROP部分很类似，所以还是简单的算下就是了。结果是9070领先了181%，同样比较惊人。

Infinity Cache部分

RDNA3采用chiplet将Infinity Cache外置，但由于Infinity Cache的高带宽这样必定会导致访问Infinity Cache的功耗暴涨。RDNA4的Infinity Cache移到了GPU内部，我使用以前我写的OpenCL工具仅仅测出来1.6TiB/s的带宽，不知道是实际就这么多，还是工具对于RDNA4不太合适，所以这个对比也不太公平，不过也是依然可以大致算一下。结果是RDNA4的能耗比提高了150%，十分惊人。

主存访存部分

这项差距比较小，因为速率不高，但9070依然领先大约百分之十四。

性能测试

测试平台

3DMark

Spec2020

AMD的显卡驱动几乎不会针对专业软件的预览进行过分的帧数限制。我简单测一个Spec2020，来看一下这些专业软件的预览性能。

游戏测试

测试均采用可能的最高画质，游戏如果可以使用路径追踪，则光追测试为路径追踪。

总结

RDNA4架构，AMD通过架构优化，大幅提升了等效频率下的性能。同时通过工艺、物理设计、大幅提高了图形固定单元的频率上限，仅默认状态上就可高达3.42GHz，可以说是当之无愧的第一款突破3GHz的GPU。频率上限提高的同时，这些固定功能单元以及Infinity Cache的能耗比也得到了极大的提升。从游戏测试来看，按照以往RDNA3的落差幅度，在传统光栅化游戏上，能耗比较好的9070得以追上Ada与Blackwell的能耗比。

在光追方面，9070XT相对与类似规格的7800XT绝对性能几乎翻倍，进步十分显著，但和对手Nvidia比起来依然还有很大的差距，希望下一代架构能补上这个缺憾。

传统游戏方面，提升也是令人满意的，接近40%的提升和隔壁挤牙膏模式形成了鲜明的对比。

AI方面，目前的驱动还没有条件测试，但从理论性能来看也是无可挑剔的。

我个人认为结合4499 4999的定价，RDNA4这代显卡是目前最为值得购买的显卡。

在RDNA3第一波Navi31发布半年之后，RDNA3的第二波Navi33在近日正式发布。我也有幸借到了搭载完整版Navi33的RX 7600做个简短的测试。

架构

Navi33和Navi31都属于RDNA3架构，但两者之间还是有一定的区别。

第一个区别是工艺，Navi31采用昂贵的5nm工艺，Navi33则是相对便宜的6nm。

第二个区别是寄存器容量，Navi31的寄存器相对于Navi2x来说增加了50%，Navi33则保持和Navi2x一致。

其余的改进基本都得到了保留。

测试平台

CPU ： Ryzen 7950X3D

内存 ： DDR5 6000 * 2

主板 ： ASUS ProArt X670E-CREATOR WIFI

显卡 ： 撼讯 AMD Radeon RX 6650 XT 竞技 ， 蓝宝 AMD Radeon RX 7600 白金版

硬盘 ： 致钛TiPlus 7100 2T

6650XT和7600大体上具有完全相同的规格，所以是个非常完美的对比对象。

游戏测试

总结一下，测试中，一共用过两版驱动，成绩差异巨大。即便在第二版驱动优化之后，虽然理论上7600的性能基本不可能输给6650XT（唯一的纸面规格劣势大概只有NGG Culling之后的多边形吞吐率比Navi23低一半，但基本不会有实际影响），但依然出现了不少成绩严重倒挂的游戏。说实话，驱动比7900XT首发的时候还要烂。不过考虑到和目前6650XT一样都是2099的售价，在未来驱动BUG修复之后性能提升起码能再提升5%的基础上来看，相对上一代产品，还是非常值得购买的。

同频3DMark测试

难得的能对比不同架构效率的机会，不能错过。

这里可以看到纯粹的架构提升还是蛮大的。除开DX11的老测试，别的提升至少都有16%。

这里顺便测了一下API开销测试，基本上游戏测试时驱动的问题在这里就表露无疑了。Vulkan的性能甚至接近腰斩，不过从Navi31的经验来看，通过驱动大概能修补到接近RDNA2的水平的。可能AMD的驱动开发人员还没有适应RDNA3上新的脱耦的任务前端。

完

本人有幸拿到了蓝宝石的7900XT超白金送测，这里为大家带来RDNA3架构的解析和实际测评。

架构部分

CU

RDNA3在CU部分做了极大的改进，所以把CU部分摆到了第一位。

RDNA3的CU整体框架与RDNA2差别不大。L1I总计32KiB大小，指令拾取单元从L1I取指之后会将指令放入两组指令缓冲，两组指令缓冲分别对应着两组SIMD。每组指令缓冲最多可以存放对应16个硬件线程的指令，每条硬件线程都有自己对应的程序计数器。之后缓冲中的指令由线程调度器通过一系列条件（比如数据缓存的命中率，或者标量ALU的指令控制），挑选出最多7条硬件线程的指令送往下面的执行单元。执行单元有两个SIMD单元，两个标量ALU，一个访存/纹理/光追加速单元，一个LDS，一个GDS/Export单元，这些单元可以同步执行来自7个不同硬件线程的指令，也就是说可以实现最多7发射，但对于一个硬件线程来说依然是单发射。

RDNA3相对于前代最大的不同点在于它的SIMD。一直以来AMD这边所说的SIMD其实不是一个单独的SIMD，而是多个不同类型SIMD的合集，类似于Nvidia现在架构中Math Dispatch下面挂的那一堆SIMD。

在RDNA3的SIMD中，新添加了一个FP32 SIMD32，和两个用于AI加速的SIMD64（分别对应Dot2和Dot4）。RDNA系列的前两代中，SIMD只有一个发射端，在Wave32模式下，可以刚好喂饱其中的其下的一个FP32 SIMD32，在Wave64模式下，FP32 SIMD32需要两周期才能完成一条FP32 SIMD指令。

而RDNA3中，因为新加了一组FP32 SIMD32，单发射的发射端如果使用正常的指令，在Wave32模式下只能喂饱其中一组，所以AMD为RDNA3的Wave32模式添加了VOPD指令格式。该指令格式可以将两条指令打包成为一条VOPD格式指令，这样就能通过仅有的一个发射端，同时驱动两个FP32 SIMD32。VOPD在性质上来说就类似于VLIW指令，但它的编码格式没有增加最大指令长度，也没有增加指令延迟，例如VOPD的双FMA指令延迟和正常FMA指令一致为5周期。VOPD指令虽然能解决驱动两个FP32 SIMD32的问题，但它也有极多的限制，它需要编译器或者汇编程序员来处理数据依赖，两条指令的常量、立即数和标量寄存器只能使用同一个，目标寄存器需要是一个奇数号一个偶数号，源寄存器需要使用不同的Bank，甚至支持的指令也是有限的，第一个SIMD支持16条指令，第二个SIMD只支持13条。如此多的限制下，VOPD驱动的第二组FP32 SIMD32可能仅仅是一个锦上添花的东西。

实际测试中，利用我自己写的OpenCL测试程序测得Wave32模式下，VOPD的两条指令中，最多在各自使用一个源向量寄存器时，在我手上这块7900XT 超白金上可以达到61.5TFlops的浮点吞吐率，有效频率大约2.86Ghz。使用其他任意格式均会导致吞吐率下降到一半水平。

在Wave64模式下，和AMD PPT上写的不同，RDNA3采用单发射端交替发射的模式喂饱两个SIMD32。这样，对于需要吞吐率的应用，在Wave64下可以较为轻松的利用起增加的SIMD，限制上少很多，延迟上也与上代保持一致，为7个时钟周期。不过Wave64模式下，寄存器压力较大，所以前一代中AMD都只在相对可能更简单的Pixel Shader中使用Wave64模式，RDNA3中AMD将寄存器堆容量增加了50%，L0也增加了一倍，应该就是为了应对Wave64模式下，寄存器压力较大的问题。

通过PIX Profile D3D程序可以得知，Direct3D下所有Shader都已经采用Wave64模式。所以使用我自己写的D3D12程序可以测得，无论何种格式的FMA指令，在Wave64模式下都至多只能获得5/6的峰值吞吐率，而常用的格式下甚至更低。稍微评价一下RDNA3这次增加一组SIMD的做法，大概就是硬塞了一组进去的感觉，寄存器方面完全没有做任何准备，比较令人失望。

接下来说下CU新增的WMMA，也就是矩阵加速器，从LLVM的代码可以看到AMD的WMMA指令，除了名字和Nvidia Tensor Core的WMMA指令一样以外，内容也差不多。回到硬件本身，AMD的Dot2 WMMA指令支持FP16、BF16和INT8，Dot4则支持INT4，宽度都为64。用FP16来算的话，DOT2等效于两个乘法操作加上两个加法，也就是每周期256个浮点操作，从单CU的性能上来看，大约和Nvidia图灵架构的差不多，对于一般AI方面的应用而言，其实是非常足够了，而且考虑到AMD之后会引入赛灵思的AIE，这种规模完全合情合理。

光追加速器方面，AMD主要增加了对Ray Flags的硬件支持。Ray Flags是DXR的Shader中通过TraceRay内联函数传递给求交之后的处理函数的光线特性覆盖标志。通过这个标志可以实现一系列高级操作来减轻复杂光追的开销。LDS也新增了一条指令，取代了以前需要由多条ALU和LDS指令配合完成的复杂操作，让每个遍历操作中减少了50条指令，降低了4倍的L0总线开销。同时增加的1.5倍寄存器，也让光追Shader的寄存器压力降低很多，实现了更高的计算单元的利用率。这块我不熟，就不测了。

调度上，RDNA3为SALU增加了s_delay_alu指令用于提示调度器接下来的指令相关性以及延迟等信息，改善了线程切换的准确性提升了CU的性能和功耗表现。这里多讲一点，GCN的调度模式是每周期都切换线程，所以GCN没办法使用寄存器缓存，每次计算都需要重新到主寄存器堆取数据。主寄存器堆很大，工作功耗会很高。而Navi开始加入了s_clause指令用于提示调度器接下来的指令可以不切换的连续执行，这样前后指令需要的数据可以被放在一块很小的操作数缓存中，写出的结果也可以通过结果缓存让后面的指令使用，大大降低了寄存器访问功耗，这也是Navi与GCN能耗比差距巨大的根本原因。同时通过软件辅助的调度器本身功耗也可以更小一些。

缓存

RDNA3的缓存结构与RDNA2保持一致，但在容量上有了一些变化。

首先是L0缓存的大小翻倍，来到了32KiB。AMD和Nvidia的CU私有缓存容量差异很大，这导致了很多优化方向上的差异，在上一代RDNA2中L0仅有16KiB，而Nvidia从安培开始增加到了64KiB，AMD也增大L0可以让这种差异减少。

然后是AMD独特的SE内共享的L1缓存，AMD认为L1缓存作为SE内的数据交换中心可以极大的降低互联的复杂性和数据交换的功耗。通过AMD的RGP工具观察多个游戏L1命中率可以发现128KiB确实有点捉襟见肘了，很多时候只有百分之十几的命中率。所以RDNA3上AMD也直接将它翻倍了。

L2没有什么亮点，配合位宽增加而增加。

Infinity Cache就很有意思了，AMD将他的容量减少了一些，从128MiB降低到了96MiB，但双向总带宽增加到了5.4TiB/s，同时在指令编码中的DLC位改为了对于IFC的控制位，方便程序员或驱动将不需要缓存的数据绕过IFC，AMD表示这样可以将有效带宽拉到3TiB/s以上，这个提升还是非常可观的。

实际测试中，我只测了单向带宽，缓存内能达到2.5TiB/s。

顺便测了点延迟，RDNA3相对于RDNA2，L0、L1、L2延迟周期基本保持一致，但IFC的延迟从85ns左右降低到了55ns，除开AMD PPT上提到的频率提升之外，本身访问特性上可能也有了很大的改进。

图形专用硬件

MDIA

Multi Draw Indirect是图形API中的功能，简单的理解就是可以将多个DrawCall合并为一个，从而减小CPU开销。RDNA3加入的Multi Draw Indirect Accelerator可以在GPU处理指令数据，从而让MDI的性能更好。

实测使用Tellusim的DrawMesh测试来进行，在DX12下79XT大约获得了20%的提升，Vulkan下更好一些，有50+%。但DX11不知道因为什么原因，反而有了大幅的退步，难以理解。

硬件Primitive Culling

在RDNA2中NGG生成的Primitive Shader最后，会附加一段用于Primitive Culling的Shader代码，对于Navi21来说可以实现最高2倍的Culling后Primitive 吞吐率，Navi22则是4倍。但利用Shader来实现，始终是有额外开销的。RDNA3中AMD使用硬件来实现这个效果，为RDNA3中本来寄存器压力就很大的Primitive Shader减少了一些负担。

实际测试中，我们可以在69XT和79XT上都看到超过两倍的提升，原因是在非NGG状态下，所有芯片都无法达到理论值的多边形吞吐，但在NGG生效之后，可以几乎完美达到理论吞吐率。

有意思的RDNA的硬件Primitive Culling不止减少了Primitive Shader的开销，顺便还降低了功耗。NGG生效非生效状态下，69XT功耗差距有将近30W，而79XT仅仅0.9w。

随机顺序非透明导出

GPU在Pixel Shader完成后，像素会进入ROP进行Blend步骤，有透明度的像素的Blend顺序会影响最终色彩，所以AMD之前设置了一个重排序缓冲区（没错就是类似CPU上那个重排序缓冲区）来保证像素输出顺序的正确性。但是对于非透明或者非重叠的像素来说，这个步骤显然是多余的。只需要一个简单滑动缓冲区就可以搞定，不用保存巨量的结果。对于Pixel Shader来说效率也可以得到改善。

物理设计

频率

之前传言说RDNA3的设计频率极高，确实如此，RDNA3的设计目标频率在3Ghz，但为了更佳的能耗比，AMD把频率压得比较低。我手上这块7900XT超白金的最大功耗只有400W，电压最高只有1.1v，不足以让我摸到RDNA3的频率上限，但我大致测试了一下。和前面一样，使用自制的OpenCL FP32吞吐率测试程序给CU压力，然后往上拉频率，最终在3.5Ghz、1.1v、 400w下达成了75TFlops的浮点吞吐率。

并且我简单的测试了频率/功耗曲线：

在2.8Ghz附近电压就已经到了1.1v，不再上升，所以之后的功耗上涨非常平缓，直到3.5Ghz。在面板中将频率继续往上拉的话，会卡死，即便这时候没有负载。这应该不是RDNA3架构的上限。

需要注意的是，当前仅仅是CU有压力，而图形流水线中还有其他部分。实际图形负载的话，因为TDP，TDC，和电压的三方限制，最多在游戏中可以看到3.25GHz左右。如下图所示的情况为电压限制。

AMD之前提到RDNA3将任务前端频率与Shader频率分开了，实际测试中确实如此，任务前端频率总是比Shader频率高0.2Ghz左右，Shader运行在3.5Ghz的时候，任务前端已经达到了3.7+Ghz。AMD将任务前端分频原因我猜测可能与它现在需要负责6个SE的任务调度有关，更多的SE需要更强的性能。

除开任务前端分频，实际6个SE的频率也已经是分开的了，最显而易见的好处是，在低负载时，可以将任务全部放在一个SE，而别的SE轻易通过时钟关断等手段来降低动态功耗。同时我认为这与AMD之后将要实现的更细的Chiplet设计有关，可能以后就是任务前端一个Chiplet，每个SE一个Chiplet。

Chiplet

说到Chiplet，Navi31将Infinity Cache和显存控制器以及PHY，这几个性能或面积对于工艺提升不敏感的器件做到了6nm的小芯片内存缓存晶片（Memory Cache Die）中，其余需要高性能高密度的部分则使用5nm工艺做成图形计算晶片（Graphic Compute Die）。最终一片图形计算晶片与六片内存缓存晶片通过高级封装互联在一起成为Navi31芯片。这样让昂贵的5nm用到了刀尖上，最终为玩家带来了实惠的价格。

实测

首发测试只有两张卡的成绩，测试平台如下：

CPU	Ryzen R9 7950X	Ryzen R9 7950X
内存	GSkill DDR5 6000 16G * 2	GSkill DDR5 6000 16G * 2
主板	MEG X670E ACE	MEG X670E ACE
显卡	蓝宝石RX 7900 XT超白金OC	AMD RX 6900XT
硬盘	致态 TiPLUS 5000 2T	致态 TiPLUS 5000 2T

跑分测试

游戏测试

专业软件

总结

从成功的RDNA2架构发布至今，时隔两年AMD迎来一次激进但不算完美的架构更新，潜力巨大，任然需要在架构上的进一步完善。实际产品上，7900XT在游戏方面带来了相对于上代26%的性能提升，通过合理的价格定位，让这款显卡的购买价值依然优秀。

Intel在上月末终于发布了它近年来的第一张正式零售的独立显卡，Arc A380。本人有幸在消息灵通的六副总的及时通知下，以冤大头价拿下了世界第一张零售的Arc A380。经过一周多的把玩之后为大家带来这篇测试。

Xe-HPG架构

Arc A380是炼金术士（Alchemist）系列或者说DG2系列的低端显卡之一。炼金术士系列是Intel新世代独显中的第一个系列，后续还有战斗法师（Battlemage），天人（Celestial），德鲁伊（Druid）。Alchemist系列的架构代号是Xe-HPG，按Gen的代号来看是Gen12，具体版本号是Gen 12.71。与它同代的架构还有核显和DG1独显使用的Xe-LP/Gen 12.1，Arctic Sound数据中心显卡使用的Xe-HP/Gen 12.5（据三哥的说法，已经取消发布，只有Intel自家的OneAPI的开发云上部署了），Ponte Vecchio数据中心显卡使用的Xe-HPC/Gen 12.72。我们今天当然主要关注Arc A380的Xe-HPG。

Xe Vector Engine

Xe-HPG中最小的独立处理单元为Xe Vector Engine（XVE），曾今叫做EU，它的存在类似于Nvidia架构中SM里面的SubCore。

Xe-HPG的每个XVE同时最多可以维持8条硬件线程（Wave，Xe-LP为7条）。8条硬件线程共享XVE中的资源，和大多数GPU一样，执行资源通过分时共享，储存类的资源则是容量共享。通过这种方式，可以让它掩盖掉一些比如访存之类的长周期的操作延迟。Intel的Wave对应的数据宽度是灵活可变的，宽度可以为2、4、8、16、32。Wave的指令存放在他们各自对应的指令缓冲中，解码之后，通过记分牌调度决定是否发射。

计算部分总计有四个发射端，分别对应着浮点，整数，1超越函数和矩阵运算引擎。浮点和整数部分的执行单元为宽度为8的SIMD，超越函数是宽度为2的SIMD，矩阵运算单元则是1024bit。XVE比较特别的是，相邻的两个XVE可以共享调度单元，通过拼接的方式来将两个SIMD8组合成一个SIMD16。这样的两个EU被称为Dual EU。虽然听起来像是Dual CU的感觉，但完全不是一个概念的东西。DG2的执行单元的宽度与AMD和Nvidia的比要窄很多，而且原生Wave宽度同样也要窄很多，这意味着在相同的计算能力下，DG2在指令方面的开销要大很多，是两家对手的4倍。当然好处也不是没有，对于分支多的任务，比如光追，来说更友好，对于软件线程数少的任务更加友好。但总的来说，对于目前的图形任务，我认为粒度还是过细了。

Xe Core

Xe Core是Xe-HPG架构中一个完整的计算单元，它类似于Nvidia架构中的SM或者AMD架构中的CU/DCU，因为LDS或者叫SLM被安排在这一级，所以它是最小的Work Group处理单元，同一个Work Group只能在同一个Xe Core中运行。

分配到Xe Core的线程指令首先被放在一个96KiB大小的L1i中，然后通过线程调度器分配给下面XVE。Xe Core中的XVE执行单元宽度很窄，所以Xe Core中包含了16个XVE，算下来总计128 Lane的FP32 SIMD，相比之下AMD和Nvidia的DCU和SM都只有4个Subcore，每个32 Lane的FP32 SIMD，总计也是128 Lane。

Subcore访存相关的操作都由Xe Core中的LSU来执行，Work Group中的数据交换则是SLM来负责。Intel的SLM设计与Nvidia的类似，都是L1D和SLM共享容量，可以按一定比例配置。与访存强相关的纹理单元和光追单元也都放在这儿附近。纹理单元每个Xe Core有8个，与目前AMD架构的比例一致，比Nvidia的高一倍。光追方面，按IMG在去年划定的一个光追标准等级，如下图：

AMD目前处于第二级，Nvidia和Intel处于第三级。可以说Intel的架构至少功能上是实现全了。

Slice

更上一级的Slice是一个具有完整图形功能的部件，他的地位类似Nvidia的GPC和AMD的SE，Xe-HPG中Slice的固定功能单元有几何单元，Hierarchical-Z单元，光栅器和渲染后端，以及处理各种Shader的Xe Core。几何部分主要是一些输入组装，图元组装，以及向后传递的Buffer之类的，光栅器则是负责图元的光栅化，每周期可以吞吐一个图元。Hi-Z则是输出层级化的Z Buffer。渲染后端包含了16个Color ROP和32个Z/Stencil ROP，负责色彩与深度/模板的输出。

Arc A380

将两个Slice组合起来，加上任务接收与调度相关的Command Processor，加上显示输出和媒体处理部分，加上4 MiB的L2缓存，加上3个32 Bit的内存控制器，通过Xe Fabric互联起来就是一个Arc A380的核心了。这里列出一下我手上这块的规格：

核心频率	2450 Mhz
流处理器数量	1024
纹理单元数量	64
光追单元数量	8
计算核心/Xe Core数量	8
光栅器数量	2
ROP数量	32
渲染分片/Slice数量	2
总浮点算力（以FMA计）	5,017.6 GFlops
总纹理采样速率	156.8 GTexel/s
总色彩像素填充率	78.4 GPixel/s
总深度/模板像素填充率	156.8 GPixel/s
总图元填充率	4.9 GTri/s
二级缓存大小	4 MiB
GDDR6 频率	15.5 Ghz
总内存带宽	186 GiB/s
PCIe规格	x 16@3.0

基础指标性能测试

DX12时代，要找到一个合适图形方面的底层测试软件很难，之前流行的大部分理论测试软件都是DX9时代的，由于当时的测试代码已经远远跟不上显卡和API的进化，基本要么因为API支持问题无法运行，要么就因为测试规模太小，无法让显卡满载。所以我在拿到卡之后尽可能的自己写了点代码。

浮点计算能力测试

指令	GFlops
MAD/FMA Vec4	4904
MAD/FMA Vec1	4907
MUL Vec4	2476
MUL Vec1	2462
ADD Vec4	2475
ADD Vec1	2460
LOG Vec4	618
LOG Vec1	619
SIN Vec4	621
SIN Vec1	622
SQRT Vec4	621
SQRT Vec1	622
EXP Vec4	620
EXP Vec1	622

不像AMD和Nvidia的架构，DG2的峰值浮点性能不是很容易实现，有极多细节方面的东西会影响它的吞吐率，最终费劲心思我也只达成了4907 GFlops，距离理论值5017.6 GFlops还有一些距离，SIMD8的指令几乎都是如此，我一度怀疑是SIMD8的指令延迟过长引起的，但仔细一算，实测结果又太高了点，通过PIX分析之后，发现Wave占用率始终只能保持在97%左右，算下来刚好是实测值，观察反汇编代码之后发现编译器似乎在寄存器分配上有一点点过量，之后会试试直接用汇编来写看看能否跑满。

纹理与ROP吞吐率测试

纹理测试峰值非常接近于理论值，测试纹理分辨率为800*800。观察一下的话可以发现，线性过滤在BC7格式下，Shader的纹理采样数大于6就开始下滑，稍微算一下的话，采样数为6的时候，纹理总容量为6*800*800 = 3840000，接近4M的L2容量，调整纹理分辨率可以达到同样的效果，这里可以看出DG2的纹理性能还是比较依赖于L2，这在A卡和N卡身上是基本见不到的。在各向异性过滤测试中，峰值性能基本直接砍半，这同样在A卡和N卡上见不到，各向异性过滤几乎都是免费的（但受制于显存带宽），这也可能是DG2在某些游戏中表现很差的直接原因之一。

当然AF的效果还是很棒的，非常圆滑。

色彩填充率	62 GPixel/s
深度填充率	153 GPixel/s

色彩填充率离理论值78GPixel/s相差非常远，但是在用PIX或者GPA分析之后可以发现ROP其实都满载了，不知道是什么造成的这种现象，测试96EU的Iris Xe的时候也有同样的现象出现，1.1GHz的频率无论如何都只能达到21 GPixel/s。另外当渲染目标为屏幕的时候，DG2也启用了差分色彩压缩，避免了显存带宽成为瓶颈，在这之前，只有AMD的显卡可以做到这一点。

深度填充率，最传统的应用是改善高倍MSAA下的性能，从G80/RV770开始，深度填充率都是像素填充率的4倍，但是最近几年随着forward渲染的逐渐消失，硬件MSAA已经是个罕见的技术了，反而VRS这种“逆向”MSAA逐渐兴起，所以现在的显卡架构又改回了1：2的配置。Intel也不例外，深度填充率峰值达到了色彩的两倍多，但仅能在D16格式下实现，而D24S8或者任意32位格式下即便不启用模板，也仅仅能达一半不到的吞吐，大约72G Pixel/s，比较怪异。之后有时间我会慢慢研究。

不同倍率下的MSAA的采样点。基本都是这样的了，没啥意思。另外不支持EQAA，当然这也是理所当然了。

多边形吞吐率

三角形吞吐率

4.38G Triangles/s

多边形吞吐率比较接近理论值，算是不错的发挥，目前除了AMD在NGG Culling下可以完美达到双倍理论值的吞吐率外，别的情况下没有任何卡可以完美达到峰值，特别是Nvidia的显卡，比如GA104，理论值6每周期，实际最多做到4.69。

光栅化

Nvidia在Maxwell 2上引入了Tile Based光栅化，实现了Tile Based Immediate Mode Render，随后AMD也用自己的方法实现了，AMD称之为Draw Stream Binning Rasterizer，和一般的Tile Based Render不同，这种实现并未将流水线分为两个阶段，而是将图元打包好一个块之后直接送给光栅器，然后前端Shader的输出则通过Parameter Cache送给后面的Pixel Shader，而不用全部生成好写回显存，比TBR进一步节约了显存带宽。当然，一些TBR有的缺点，这种模式也有，所以AMD只在了APU上启用了DSBR。

Intel在Gen11上引入了Position Only Shading Pipeline（POSh），这是一个简化版的前端Shader流水线，它由驱动生成，Shader方面只包含Vertex Shader，然后分块输出可见性信息到显存，然后正常的渲染流水线使用可见性信息先进行剔除，再完成整个渲染。可以算是一个非常特别的TBR与IMR的结合。这个流水线一直使用到了DG1。

POSh的劣势显而易见，虽然可以从开始就剔除一些图元，但毕竟多一个Render Pass，到底能不能节约资源还很不好说，同时正常的渲染流水线没有Tile Based，POSh还要浪费带宽，带宽节约无从谈起，所以DG2上POSh流水线被移除了。取而代之的是类似Nvidia和AMD的一样的TBIMR，如上图所示。Tile只有一级，它大小会根据Render Target的格式以及采样点数不同而调整，以确保可以放入L2缓存中。

目前的理论测试就到此为止，离我拿到卡已经快过去了一个月，大部分时间都花在了编程上面，后面等我有富余的时间，会再写一些测试程序，架构方面也会慢慢补充一些。顺便表扬Intel一点，就是他的软件非常给力，PIX支持很完美，不仅仅暴露了巨量的性能计数器给开发者，而且反汇编也提供，Nvidia虽然性能计数器也多，但是反汇编不开放给一般群众，AMD倒是开放反汇编，但是计数器也太敷衍了。Intel的GPA更是可以实时显示性能计数器的值并生成曲线，非常的爽。