在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更是可以实时显示性能计数器的值并生成曲线，非常的爽。