Vol.1 建立了 GPU 的公约数模型（SIMT、Scoreboard、Memory Hierarchy 那套结构性共性）。Vol.2 把这个模型落到 NVIDIA 的硬件里，从 Tesla 到 Blackwell 追了近二十年。NVIDIA 的路径体现的是"持续高投入 + 先发生态锁定"的组合策略。但单一技术路线不足以概括 GPU 架构的全部设计空间。AMD 走的是另一条路：在有限资源下的非对称创新、图形与计算架构的战略分叉、从 VLIW 到标量 SIMT 的被迫转型。

AMD GPU 架构从 TeraScale 到 RDNA 4 / CDNA 的完整演进，核心关注的结构性问题如下。

TeraScale 采用 VLIW（Very Long Instruction Word）执行模型，依赖编译器静态挖掘 ILP（Instruction-Level Parallelism）。这一选择在峰值 FLOPS 上具备竞争力，但面临编译器 ILP 挖掘能力与实际控制流/访存模式之间的结构性失配。该矛盾贯穿 TeraScale 三代（R600/Cayman），最终迫使 AMD 放弃 VLIW，转向 GCN（Graphics Core Next）的标量 SIMT 架构。

GCN 确立了 AMD GPU 的通用计算战略，引入 ACE（Asynchronous Compute Engine）和标量/向量双轨 ISA，将性能来源从单线程 ILP 迁移到多 wavefront 的 TLP（Thread-Level Parallelism）。GCN 架构持续迭代七代，成为 AMD GPU 此后十年的架构基线，但也积累了 Wave64 分支分歧代价、低 occupancy 场景效率不足等结构性问题。

RDNA 架构回应了上述问题：引入 Wave32 降低分支分歧损失，通过 WGP（Work Group Processor）重构计算单元组织，以 Infinity Cache 弥补显存带宽约束。RDNA 与 CDNA 的分叉决策（图形架构与计算架构分离）则反映了 AMD 在资源有限条件下对两大市场的差异化应对。

技术线索：

• TeraScale VLIW 的编译器依赖瓶颈及其对后续架构的约束
• GCN 标量化转型的 ISA、调度与执行单元重构
• RDNA Wave32/WGP 的延迟优化与游戏工作负载适配
• CDNA 的计算专业化与 MI 系列加速卡的技术路线
• 贯穿各代的 Memory Subsystem（缓存层次、Infinity Cache/HBM）演进

一、Tera Scale

AMD TeraScale 是 ATI/AMD 在统一着色器模型时代推出的 GPU 微架构系列，覆盖 Radeon HD 2000 至 HD 6000 系列（2007–2011 年）。这一架构将顶点、像素、几何等着色功能统一到以 wavefront 为执行单位的并行流处理器阵列中，完成了从固定功能图形加速器到统一可编程处理器的转型。

TeraScale 的核心设计选择是 VLIW（Very Long Instruction Word）：每条指令静态封装多个并行操作，由编译器在编译期完成调度，硬件不做动态重排。VLIW5 配置下，每个 ALU group 包含 5 个槽位（4 个通用 FP32 ALU + 1 个超越函数/INT32 乘法专用槽）。该设计在峰值吞吐上具备竞争力：R600 全芯片 320 个流处理器在 742 MHz 下提供约 475 GFLOPS 单精度峰值。但性能实现高度依赖编译器对 ILP（Instruction-Level Parallelism）的挖掘能力：实测中典型图形着色器的平均 ILP 约为 3～4 个独立操作，VLIW5 的平均槽位利用率约为 60%～80%，第五槽在常规图形 workload 中频繁空置。

这一根本矛盾（峰值 FLOPS 与实际 workload 利用率之间的 gap）贯穿了整个 TeraScale 时代。当控制流分歧发生时，Execution Mask 屏蔽部分 lane，进一步降低有效 slot 利用率；当访存延迟导致 wavefront 切换时，编译器静态安排的 ILP 打包被打断。这些约束直接导致了 GCN 的架构转向：放弃编译器主导 ILP，转向硬件主导 TLP。

1.1 ISA

TeraScale ISA 的核心结构是三层嵌套：CF（Control Flow）层、Clause 层、ALU Group 层。这一层次结构服务于 VLIW 执行模型的两个核心需求：编译器静态调度的最大化，以及硬件在 clause 边界进行 wavefront 切换以隐藏延迟。

CF / Clause / ALU Group 三层结构

CF（Control Flow）指令控制程序的整体流向，包括条件跳转、循环、调用，以及 clause 触发。一个 CF 指令可以触发一段 ALU clause 或一段 Fetch clause（纹理/内存访问）。这种分离的硬件含义是：ALU clause 内部不允许出现内存访问，编译器可以在 clause 内部做完整的静态调度（确定哪些操作可以并行打包到同一 VLIW slot）；Fetch clause 则是一段连续的纹理/内存取指序列，硬件可以在 Fetch clause 执行期间将对应的 wavefront 移入等待队列，切换到其他就绪 wavefront。

Clause 边界是编译器静态调度与硬件动态调度的交接面。在 clause 内部，编译器拥有完全的控制权：它决定 ALU group 的长度、各 slot 的分配、NOP 的插入位置。在 clause 边界，硬件获得调度自由：它可以选择下一个执行哪个 wavefront 的 clause，利用多 wavefront 的 TLP 隐藏访存延迟。这种"编译器管内、硬件管间"的分工是 TeraScale 应对 VLIW 刚性的一种折中：编译器无法预测运行时的 cache miss 或纹理采样延迟，因此将延迟隐藏推迟到硬件层，通过 clause 粒度的 wavefront 切换实现。

每个 ALU group 是一个 VLIW 指令束。TeraScale 1/2（R600 至 Juniper）使用 VLIW5，每个 ALU group 有 5 个槽位：4 个同质的标量 ALU 槽（x/y/z/w 通道，支持 FP32 MAD/ADD/MUL 等常规运算），加 1 个特殊函数槽（T-slot，支持 sin、cos、log、exp、rcp 等超越函数，以及 INT32 乘法）。T-slot 在内部采用更宽的数据路径以支持 INT32 整数运算，R600 上 INT32 乘加可以单周期完成，这一精度能力同期的 NVIDIA G80 需要多拍。

TeraScale 3（Cayman/Northern Islands）改为 VLIW4，去掉了 T-slot，将 4 个槽统一为通用 ALU，各槽均可执行常规 FP32 运算，超越函数与整数乘法仍有专门数据路径和吞吐限制。VLIW5 → VLIW4 改动的微架构因果链如下：

• 前代瓶颈：VLIW5 第五槽（T-slot）的超越函数和整数乘法在典型图形着色器中出现频率有限，典型 workload 下第五槽利用率低于前四槽。
• 硬件改变：去掉 T-slot，4 个槽位统一化，均可执行常规 FP32 运算，超越函数与整数乘法通过复用部分数据路径实现但存在延迟与吞吐限制。每流处理单元的理论峰值从 5 ops/cycle 降至 4 ops/cycle。
• data path 改变：去掉 T-slot 的专用数据路径，ALU 阵列面积缩减，对称设计简化了 operand routing。
• 编译器不再需要为 T-slot 做特殊调度，ALU group 打包的约束减少，编译器调度复杂度降低。
• 代价是峰值 FLOPS 基本持平（Cayman 1536 lane × 2 × 880 MHz ≈ 2.70 TFLOPS，Cypress 1600 lane × 2 × 850 MHz ≈ 2.72 TFLOPS），但每 SP 理论操作数从 5 ops/cycle 降至 4 ops/cycle；槽位利用率提升可部分抵消峰值损失，稳态吞吐更接近实际 workload 需求。

ALU group 的长度是可变的，编译器根据指令间的独立性决定每个 group 打包几条指令，未填满的槽位由 NOP 占位。VLIW 的"峰值吞吐"只在编译器能持续找到足够 ILP 时才能实现。NOP 填充率直接反映编译器的调度质量，也是衡量 VLIW 架构效率的核心指标。

取指与发射模型

TeraScale 的取指和发射以 SIMD 簇为单位。一个 SIMD 簇内的所有流处理单元共享同一条取指路径，每个周期取一个 ALU group，发射给簇内所有流处理单元并行执行。Wavefront 在 SIMD 内以锁步方式推进：64 个 lane 同时执行同一条 ALU group，每个 lane 使用独立的寄存器数据。由于 wavefront 宽度为 64，而每个 SIMD 簇有 16 个流处理单元，完整执行一个 wavefront 的一条 ALU group 需要 4 个周期（64 lane ÷ 16 = 4）。在这 4 个周期内，SIMD 簇可以连续执行同一 wavefront 的后续 ALU group（若无依赖），或切换到另一个就绪 wavefront。

该模型形成了 TeraScale 执行路径的雏形：CP → UTDP 分解 workload → SIMD Sequencer 选取就绪 wavefront → 发射 ALU group 到 16-wide SIMD → 4 周期完成 64-lane wavefront → 遇访存则切换 wavefront。这一路径在 GCN 时代被继承并标量化：CP/ACE → CU Hardware Scheduler → SIMD issue → wavefront 切换隐藏延迟。

ISA 功能扩展

图形 API 演进推动 TeraScale ISA 持续扩展。TeraScale 2（Evergreen）引入符合 IEEE 754-2008 标准的 FMA 指令，相比此前的 MAD（先乘后加，中间结果截断）减少一次舍入误差。为配合 DirectCompute 11 和 OpenCL 1.x，指令集增加了原子操作、屏障同步等并行编程原语，以及 FP64 支持（HD 5870 的 FP64 速率为 FP32 的 1/5，HD 6970 Cayman 提高至 1/4）。

Gather4 指令（一次获取相邻 4 个 texel 的某通道）并非 TeraScale 首发，DX10.1 已包含 GatherRed 等前身，DX11 规范化后 Evergreen 完整实现。SAD（Sum of Absolute Differences）指令用于加速视频编解码中的运动估计。

1.2 Scheduling

TeraScale 的调度分两层：前端/队列调度由 UTDP（Ultra-Threaded Dispatch Processor）负责；SIMD 簇内部的 wavefront 调度由 Sequencer/Arbiter 负责。这一双层模型在 GCN 时代被继承并扩展：UTDP 的职责被 CP + ACE 取代，Sequencer/Arbiter 演进为 CU Hardware Scheduler。

前端调度：CP 与 UTDP

UTDP 位于 GPU 前端，接收来自 CP（Command Processor）的工作负载（Draw Call 或 Dispatch Call），将其分解为 workgroup 和 wavefront，按负载均衡原则分派给后端多个 SIMD 簇。UTDP 维护不同着色阶段（顶点、几何、像素、计算）的 wavefront 队列，支持混合调度。

CP 负责解析命令缓冲区中的 GPU 命令，驱动状态机切换（着色器阶段切换、渲染目标绑定等），并向 UTDP 提交工作单元。CP 与 UTDP 的分工使命令解析和线程分发可以并行推进。

UTDP 是 TeraScale 前端的唯一任务分发枢纽，图形与计算的并发调度依赖 UTDP 的时间片分配。这一设计在图形 workload 占主导的场景下工作良好，但在计算 workload 与图形并行时成为瓶颈：UTDP 无法像 GCN 的 ACE 那样提供独立的计算任务队列和硬件级异步调度。GCN 引入 ACE 的直接动因即在于此：将计算任务的分发从 UTDP 的单一队列中解放出来，实现图形与计算在 CU 层面的并发。

SIMD 内部调度：Sequencer/Arbiter

每个 SIMD 簇内的 Sequencer/Arbiter 追踪所有驻留 wavefront 的状态，维护就绪队列（下一条指令已满足数据依赖且资源可用）和等待队列（等待内存访问、纹理采样完成或同步操作）。

每个周期，Sequencer/Arbiter 从就绪队列中选取一个 wavefront，将其下一个 ALU group 发射给 SIMD 簇内所有流处理单元。当一个 wavefront 发出内存请求后，它被移入等待队列，调度器切换到另一个就绪 wavefront。切换以周期级速度完成，不保存/恢复上下文，因为每个 wavefront 的寄存器状态始终驻留在寄存器文件中。

R600 每个 SIMD 簇可同时管理大量 wavefront（具体数量受 GPR 容量与 wave slot 等物理资源约束）。通过维持高 occupancy，硬件理论上可将数百个时钟周期的内存延迟隐藏在调度缝隙中。这是 TeraScale 延迟隐藏的核心机制：不依赖单线程 ILP 填充流水线，而是依赖多 wavefront 的就绪选择保持 ALU 繁忙。该机制在 GCN 中被完整继承并标量化：GCN Hardware Scheduler 同样通过 wavefront 切换隐藏延迟，但 issue 的粒度从 VLIW ALU group 变为单条标量/向量指令。

分支分歧处理

Wavefront 内 64 个 lane 遇到条件分支时，硬件通过 Execution Mask 机制处理分歧：满足条件的 lane 激活执行，不满足条件的 lane 被屏蔽。两个分支路径串行执行，直到 reconvergence 点汇合。

分歧代价在 VLIW 架构中被放大：分歧不仅浪费被屏蔽 lane 的执行周期，还打乱编译器静态安排的 ILP 打包。编译器在 clause 内精心安排的 4-5 条并行指令，在分歧导致部分 lane 屏蔽后，实际有效操作数减少，VLIW 槽位的 NOP 填充率上升。分歧越严重，有效槽位利用率越低。这是 VLIW 架构在控制流密集型 workload 下的固有代价，也是 GCN 转向标量 ISA 的动机之一：标量架构下每条指令只对应一个操作，分歧仅影响 lane 利用率，不影响指令打包效率。

ILP 与 TLP 的双层模型

TeraScale 的性能来源于两层并行的叠加：

• ILP 层：编译器在 ALU group 内静态打包独立操作（同一 wavefront 的多条指令并行执行），理想情况下 5 槽全部填满。
• TLP 层：硬件在 wavefront 间动态切换（多个 wavefront 轮流占用 SIMD，用就绪 wavefront 覆盖阻塞 wavefront 的延迟）。

当 ILP 充足（运算密集型图形着色器），VLIW 槽位利用率高，峰值吞吐接近理论值；当 ILP 不足（控制流复杂、访存密集），TLP 成为主要延迟隐藏手段，但 VLIW 槽位空置直接拉低稳态吞吐。ILP 层效率受编译器能力约束，TLP 层效率受 occupancy（同时驻留 wavefront 数量）约束。Occupancy 又受 GPR 用量、LDS 用量、wavefront slot 数量等物理资源限制，这些约束将在 1.4 节详细分析。

Instruction Dispatch 与 Resource Allocation

Sequencer/Arbiter 发射指令时需要进行资源分配检查。内存访问指令需确认 Load/Store 单元有空余槽位；纹理采样指令需确认 TMU（Texture Mapping Unit）可接受新请求。目标功能单元已满时，就绪 wavefront 的指令不会发射，等待下一周期重试。这种资源感知的发射机制避免功能单元的结构冲突，但也意味着：即使 wavefront 处于就绪状态，功能单元争用仍可能导致发射气泡。

1.3 ExecutionUnit

TeraScale 的 Execution Unit 以 SIMD 簇为基本单位。以 R600 为例，全芯片 4 个 SIMD 簇，每簇 16 个流处理单元，每单元含 5 个子 ALU（VLIW5）。一个 SIMD 簇每周期最多完成 80 条标量 MAD 操作（16 × 5），全芯片理论峰值 320 ops/cycle。

VLIW5 的 4+1 配置

VLIW5 的 5 个子 ALU 中，前 4 个为同质标量管线，每周期各完成一条 FP32 MAD/ADD/MUL；第 5 个为特殊函数单元（T-slot），支持超越函数和 INT32 乘法。T-slot 内部采用更宽数据路径，R600 上 INT32 乘加单周期完成。

VLIW5 的结构性问题在于：前四槽的 FP32 运算需求在图形 workload 中普遍，第五槽的超越函数出现频率有限。槽位利用率数据见 1.1 节，第五槽的空置是利用率损失的主要来源。

VLIW4 的改动

Cayman 将每流处理单元的 ALU 数从 5 减至 4，4 槽统一为通用 ALU，各槽可执行常规 FP32 运算，超越函数与整数乘法仍有专门数据路径。峰值 ops/cycle 从 5 降至 4，换取更高的实际槽位利用率和更低的编译器调度难度。

VLIW5 → VLIW4 的代价-收益分析：

有效稳态 FLOPS 的差距小于峰值差距，这是 Cayman 设计的核心判断：牺牲峰值换取更可预期的稳态性能。VLIW4 的对称 ALU 设计也更接近标量架构：编译器不再为不同槽位做差异化调度，为 GCN 的完全标量化积累了经验。

执行流程

每个周期，Sequencer/Arbiter 选定一个就绪 wavefront，将其当前 ALU group 发射给 SIMD 簇内所有流处理单元。每个流处理单元执行该 ALU group 中属于自己 lane 的操作。64-lane wavefront 在 16-wide SIMD 上需 4 周期完成。这 4 周期内，SIMD 可连续执行同一 wavefront 的后续 ALU group（无依赖时），或切换到另一就绪 wavefront。

该执行流程与 GCN 的关键差异在于：TeraScale 每周期 issue 的是一个 VLIW bundle（包含 4-5 个并行操作），GCN 每周期 issue 的是单条标量/向量指令。TeraScale 的 issue 带宽更高但填充率不稳定，GCN 的 issue 带宽更低但利用率更可预期。

精度与特殊运算支持

TeraScale ALU 支持 FP32。早期 FP64 通过多条 FP32 指令组合模拟，效率低；Evergreen 后高端型号引入 FP64 硬件单元（速率见 1.1 节）。整数运算方面，各 ALU 支持 INT32 加法、比较和逻辑操作，T-slot 额外支持整数乘法、除法和位移。

R600 的高峰值 FLOPS 与实际性能之间的差距，根源在于 VLIW 槽位填充率受 workload ILP 供给的约束。不规则或分支密集的代码导致槽位利用不充分，实际性能低于理论峰值。这一经验直接影响了 GCN 的设计决策：放弃依赖编译器静态打包的 ILP，转向硬件动态调度的 TLP。

1.4 RegisterFile

TeraScale 的寄存器文件设计以支撑高 occupancy 为首要目标。大量 wavefront 同时驻留 SIMD 簇内，每个 wavefront 的寄存器状态必须始终保留在片上，不能溢出到显存，因为 GPR spill 到显存的延迟代价（数百周期）会完全抵消 wavefront 切换的延迟隐藏收益。

GPR 容量与 Occupancy 的关系

R600 ISA 定义每个 wavefront 最多可用 128 个 GPR（General Purpose Register），每个 GPR 宽度为 4×FP32（RGBA 四分量向量格式，对应图形管线传统）。GPR 容量直接约束 occupancy：设每个 SIMD 簇的 GPR 文件总容量为 C_GPR，每个 wavefront 占用 G 个 GPR，则最大驻留 wavefront 数 = C_GPR / G。

这一约束在 VLIW 架构中尤为紧张：编译器为了提高 ILP 需要展开循环、保留更多临时变量，导致 GPR 用量上升；GPR 用量上升则压低 occupancy，减少可用于延迟隐藏的 wavefront 数量。VLIW 架构因此面临一个结构性 trade-off：编译器试图用更多 GPR 换取更高的 ILP（更多独立操作打包到 VLIW slot），但 GPR 用量增加反而降低了 TLP（更少 wavefront 可驻留）。这个 trade-off 在 GCN 标量化后得到缓解：标量指令不消耗 VGPR，且单指令 issue 降低了对 GPR 展开的需求。

R600 每个 SIMD 簇拥有多 bank 寄存器文件，物理面积超过簇内 ALU 阵列。为降低频繁寄存器读写延迟，R600 在寄存器文件前端增加了多端口寄存器缓存（约 8KB），缓存当前执行 wavefront 所需的一小部分寄存器内容。缓存命中时寄存器读写延迟极低；未命中时从后备寄存器阵列加载，引入额外周期。AMD 未公开具体替换策略，设计目标为保证活跃 wavefront 的寄存器数据驻留在缓存中。

RF 端口/Bank 约束

VLIW5 架构中，一个 ALU group 最多需同时读取 5 组源操作数并写入 5 个目标寄存器，对 RF 端口数量要求很高。实际实现通过 bank 分割减少端口冲突：将寄存器文件分成多个独立 bank，不同 slot 的操作数尽量分配到不同 bank。当多个 slot 的操作数落在同一 bank 时产生 bank conflict，该 ALU group 需额外周期完成读取。

Bank conflict 对 VLIW 打包构成约束：编译器在指令调度时不仅要考虑指令间的数据依赖（哪些指令可以并行），还要考虑操作数的 bank 分配（并行指令的源/目的寄存器不能映射到同一 bank）。这进一步增加了 VLIW 编译器的复杂度，调度问题从"找独立指令"扩展为"找独立指令 + 无 bank conflict 的寄存器分配"。GCN 标量化后，单指令 issue 减少了对多端口同时读写的需求，bank conflict 相应缓解。

LDS 的引入

TeraScale 2（Evergreen，DX11 世代）引入 LDS（Local Data Share）。HD 5870 每个 SIMD 核心配备 32KB LDS 和 8KB L1 数据缓存。

LDS 是软件可编程的 Scratchpad Memory，供同一 workgroup 内 wavefront 读写共享数据。与 cache 不同，LDS 在容量命中且无 bank conflict 时延迟远低于全局内存且可预测，但 bank conflict 会导致访问串行化。适合对延迟一致性要求较高的线程协作算法（并行前缀和、直方图、矩阵分块乘法）。

LDS 引入的微架构因果链：

• 前代瓶颈：TeraScale 1 时代，workgroup 内 wavefront 的数据共享只能通过显存进行，延迟高且不确定，限制了协作并行算法的效率。
• 硬件增加：每 SIMD 簇增加 32KB LDS，提供低延迟、确定性的 intra-workgroup 数据共享路径。
• data path 改变：LDS 与 ALU 之间有专用数据通路，不占用纹理/显存访问路径带宽。
• DX11 Compute Shader 可利用 LDS 实现 tile-based 光照累积等高级效果；OpenCL workgroup barrier + LDS 成为通用计算的基础原语。

Evergreen 还提供全 GPU 共享的 64KB GDS（Global Data Share），支持跨 SIMD 簇的全局原子操作（全局计数器、工作分发等）。GDS 延迟高于 LDS 但低于显存访问，用于需要全芯片协同的任务。

一致性与专用缓存

除寄存器文件和 LDS 外，TeraScale 内存层次包含：

• 纹理缓存：只读，每 SIMD 簇配备，服务 TMU 的纹理采样请求。
• 常量缓存：缓存常量内存数据，各 SIMD 簇共享或独立配置。
• L2 缓存：TeraScale 2 引入的分区 L2（详见 1.5 节）。

TeraScale 中纹理访问路径（Texture Path）和全局 Load/Store 路径（Global Load/Store Path）在 L1 层面分离：纹理访问经 TMU → 纹理缓存，全局 Load/Store 经 L1 数据缓存 → L2。两条路径共享 L2 和显存控制器，但在 L1 层面互不竞争。这种分离设计让纹理采样和全局内存访问可以并行进行。

三条数据路径的雏形

TeraScale 已建立 AMD GPU 三条核心数据路径的雏形：

1. 纹理访问路径：ALU → TMU → 纹理缓存 → L2 → 显存
2. 全局 Load/Store 路径：ALU → Load/Store 单元 → L1 数据缓存 → L2 → 显存
3. ROP 帧缓冲路径：像素着色器输出 → ROP → Color/Z Cache → L2 → 显存

三条路径在 L2 汇聚，共享显存控制器和显存带宽。L2 的带宽分配和仲裁策略直接影响三条路径的并行效率。GCN 继承了这一路径结构，并扩展了标量缓存路径（SALU → Scalar Cache → L2）。

1.5 MemorySubsystem

TeraScale 内存子系统经历了从环形总线到分区缓存架构的演进，核心驱动力是带宽需求增长和多客户端并发访问模式。

R600 世代：环形总线架构

Radeon HD 2900 XT（R600）采用 512-bit 外部显存总线，搭配 GDDR3/4 显存，提供约 106 GB/s 带宽。内部使用 1024-bit 双向环形总线连接内存控制器与各功能单元：512-bit 读环 + 512-bit 写环，围绕芯片串接 8 个 64-bit 内存控制器、着色器簇、纹理单元、ROP 等模块。

环形总线的通信拓扑特征：

• 并发传输：多个单元可在不同环段上并发传输数据，环段间互不干扰。
• 延迟固定：数据从源到目的需经过中间节点，每经过一个节点引入少许延迟。延迟与节点间距离成正比，不可预测路由。
• 拥塞模式：负载高度不均衡时，环段上某节点的流量超过环段带宽，产生拥塞。拥塞沿环传播，影响下游节点。
• 增加节点（内存控制器或功能单元）只需在环上插入新节点，架构扩展方便。

R600 的 1024-bit 环形总线在 80nm 工艺、720M 晶体管规模下提供了充裕的内部带宽，支撑 320 个流处理器和 16 个 ROP 的并行作业。但环形拓扑对长距离通信延迟固定，且不均衡负载下的拥塞模式难以通过软件优化避免，因为 GPU workload 中着色器簇的访存模式天然不均衡（某些簇访存密集，某些簇计算密集）。

Evergreen 世代：分区 L2 缓存

TeraScale 2（Evergreen）引入分区内存控制器架构：每个 64-bit 显存通道搭配专属 L2 缓存和 ROP 单元。HD 5870（Cypress）拥有 256-bit 显存接口（4 个 64-bit 通道），片上 4 个独立 L2 分区，公开资料称每分区 512KB、总容量 2MB（具体 die 配置待确认）。每个 L2 分区与对应的内存控制器和 ROP 单元直接相连，形成 memory partition。

Memory partition 的层级关系：

• ROP：执行混合、深度测试等像素输出操作的功能单元
• RBE（Render Backend）：包含 ROP 和相关缓存的后端模块
• Memory partition：L2 缓存分区 + 内存控制器 + ROP 的组合

任意 SIMD 簇可访问任意 memory partition 的 L2 缓存，通过片上交叉开关实现。分区架构的硬件含义：每个显存通道拥有独立的 L2 和 ROP，ROP 的帧缓冲访问优先命中本地 L2，减少跨分区流量；着色器全局 Load/Store 均匀分布到各分区，利用聚合带宽。

分区架构相比环形总线的改进：L2 缓存过滤了大部分显存访问请求，只有 L2 miss 才需要访问显存，显存带宽压力降低；各分区的 L2 可并行服务不同客户端（不同 SIMD 簇或 ROP），吞吐提升。代价是 L2 一致性需要在分区间维护，增加了交叉开关的复杂度。

显存技术演进

TeraScale 世代显存从 GDDR3/4 跨越到 GDDR5。R600/RV670 需 512-bit 总线宽度弥补 GDDR3/4 的低数据率；RV770（HD 4870）首发 GDDR5，QDR 传输使 256-bit 总线即可提供 115+ GB/s 带宽，总线宽度缩减降低功耗和成本。

GDDR5 引入对显存控制器的新约束：更高的时钟频率和访问延迟要求更深的请求队列和更激进的预取策略，以维持高带宽利用率。Evergreen 对显存控制器的预取算法和队列管理进行了相应优化。

带宽优化技术

TeraScale 实现多种显存带宽优化技术：

• HyperZ：层次 Z 剔除 + Z Compression + Fast Z Clear（详见该节末尾"HyperZ 技术演进"），减少无效像素着色和深度缓冲带宽。
• Color Compression：MSAA 模式下减少多重采样存储压力。
• EQAA（Enhanced Quality Anti-Aliasing）：ROP 对样本掩码的可编程操作提升子像素采样质量。

这些技术的共同目标是在不增加显存物理带宽的前提下，提升有效数据吞吐。HyperZ 系列技术对深度/模板缓冲路径的优化尤为关键，因为深度缓冲访问在图形 rendering 中占显存流量的大部分。

1.6 FunctionFeature

Graphics

Tessellation 单元

TeraScale 自 R600 起内置专用曲面细分引擎，负责按细分因子生成新顶点/图元。Bezier 曲面、NURBS 等曲面表示的计算以及置换映射（displacement mapping）属于 HS（Hull Shader）和 DS（Domain Shader）的可编程职责，tessellator 是固定功能单元，两者协作完成完整曲面细分流程。

DX10 未标准化 tessellation，AMD 提供 API 扩展供开发者调用。Xbox 360 的 Xenos GPU 具备类似细分能力。DX11 于 2009 年将曲面细分纳入标准后，Evergreen（HD 5000 系列）完整支持 HS/Tessellator/DS 管线。Cayman 配置双曲面细分单元，与双图形引擎配合实现每时钟处理两个图元，增强高细分率场景的吞吐。

着色器模型演进

TeraScale 支持 Shader Model 4.0/4.1（DX10/10.1），率先支持 Shader Model 5.0（DX11）。R600 支持 Geometry Shader 阶段，UTDP 调度器相应增加几何线程管理。Evergreen 增加 HS/DS 阶段配合硬件细分，并支持着色器可编程插值，像素着色阶段的插值精度和模式由开发者控制。Cypress（HD 5870）移除了传统专用插值器硬件，改由流处理器执行插值计算，SIMD 簇内大量 ALU 可并行完成插值而不成为瓶颈，简化了硬件。

光栅化和像素输出

Cayman 拥有双光栅器和双三角形设置单元，每时钟处理 2 个图元。ROP 单元增强了并发输出能力：HD 4000/5000 系列提升为每时钟每 ROP 输出 2 个像素（与像素格式相关）；Cayman ROP 数量达到 32 个（256-bit 总线），每通道 8 个 ROP，超出"每 64-bit 2 个"的先前配置，体现了提升像素输出率的设计意图。

TeraScale ROP 支持 MSAA 采样存储与解析。R600 的 CFAA（Custom Filter Anti-Aliasing）利用着色器实现滤波（如"Narrow/Wide Tent"滤波），通过对邻近像素加权计算颜色实现比标准 MSAA 更平滑的边缘。HD 5000 系列的 EQAA 技术依赖 ROP 对样本掩码的可编程操作和颜色合并改进。

纹理单元

TeraScale 每个 SIMD 簇绑定纹理单元组。R600 每 16 个 SP 共享 4 个 TMU；后续代际中 TMU 数随 SP 数同比增长（HD 5870 拥有 20 组 TMU，总计 80 个纹理单元）。TMU 支持 FP16 纹理全速过滤，以及改进的各向异性过滤质量。

纹理单元配备多级只读缓存（每簇 L1 纹理缓存 + 全局 L2 纹理缓存）。纹理压缩格式由 TMU 内专用解压缩逻辑硬件解压，对着色器透明：TMU 从纹理缓存读取压缩数据，解压缩后过滤计算，不引入额外延迟或吞吐损失。TeraScale 从 R600 起完整支持 BC1/2/3（DXT1/3/5），TeraScale 1 支持 BC4/BC5，Evergreen 支持 BC6H/BC7。

Compute

并行计算接口

AMD 早期推出 CTM（Close-to-Metal）和 Brook+ 框架供 GPU 通用计算。OpenCL 1.0（2009）和 DirectCompute 11（2010）标准出现后，Evergreen（HD 5000 系列）成为 AMD 第一代完整支持这些 API 的 GPU。硬件上支持 LDS 可编程使用、UAV（Unordered Access View）、原子操作等 OpenCL 1.1 所需特性。

双精度浮点

TeraScale 1（R600/R700）FP64 主要通过软件模拟或多指令组合实现。TeraScale 2（Evergreen）高端型号引入 FP64 硬件支持：HD 5870 的 FP64 速率为 FP32 的 1/5，HD 6970（Cayman）提高至 1/4。这一硬件支持对需要 IEEE 754 双精度浮点的科学计算领域是必要条件，但 1/5～1/4 的速率与同期 NVIDIA Fermi 的 1/2（高端型号）相比处于劣势。

计算着色器与线程协作

DX11 Compute Shader 通过 LDS 支持 workgroup 内共享数据，实现并行排序、扫描、归约等算法。全局原子指令集（add/min/max/compare-and-swap）提供跨 workgroup 同步机制。位反转、位对齐等高级位运算指令加速密码学 hash 等应用。

TeraScale 没有 ACE 硬件，图形与计算的并发依赖驱动层面的时间片分配。UTDP 将 GPU 周期在图形和计算 workload 间轮转，计算任务利用图形管线的空闲周期执行。这种方式的并发粒度粗（帧级或子帧级），无法达到 GCN ACE 在 CU 层面的细粒度任务交错。

性能边界

TeraScale 通用计算性能存在明显的工作负载依赖性：数据密集、并行度良好、控制流简单的算法（向量线性代数、图像滤波）可接近理论峰值；控制流复杂或内存访问模式不规则的内核，VLIW 槽位利用率下降，实际吞吐与峰值差距大。这一特性使 TeraScale 在 GPGPU 竞争中处于结构性劣势：NVIDIA 同期 Fermi 的标量 SIMT 架构在 irregular workload 下维持稳定的 IPC，不受编译器 ILP 挖掘能力的约束。

1.7 小结

TeraScale 在 2007–2011 年完成了从固定功能图形加速器到统一可编程并行处理器的转型，引入了 wavefront 执行模型、LDS、分级缓存体系，并在图形侧率先部署硬件曲面细分。这些设计中的大部分被 GCN 继承，成为 AMD GPU 架构的长期基础。

TeraScale 的根本约束是 VLIW 的软件负担与控制流/访存现实之间的失配。编译器需要在静态调度时预知所有指令间的独立性，但实际着色器和计算内核中分支、依赖和不规则访存普遍存在。当 ILP 不足时 VLIW 槽位空置；控制流分歧时 Execution Mask 进一步降低有效 lane 利用率。NVIDIA 同期标量 SIMT 架构（Tesla/Fermi）虽单周期只发射一条指令，但能在任意 workload 下维持稳定的 IPC，避免了 VLIW 的最差情况。

GCN 直接回应了上述问题：放弃 VLIW 转向标量 ISA，性能来源从单线程 ILP 迁移到多 wavefront TLP，引入 ACE 提升前端调度能力。TeraScale 的遗产（wavefront 宽度 64、LDS 组织、分级缓存思路）与 GCN 的变革（标量 ISA、简化 issue 模型、ACE）构成了 AMD GPU 架构演进的第一个完整周期。

架构演进补充

TeraScale 从 R600 到 Cayman 经历三个主要世代：

R600（TeraScale 1）是统一着色架构起点，设计重心在于图形管线统一化和 UTDP 调度。通用计算能力有限，主要通过 Brook+ 等早期框架访问。

RV770（HD 4870，TeraScale 2 早期）率先采用 GDDR5 显存，制程推进到 55nm，800 个 SP 提供约 1.2 TFLOPS 峰值。这一代 AMD GPU 计算能力进入 TFLOPS 量级，为 GPGPU 应用打开大门。

Cypress（HD 5870，TeraScale 2 成熟期）完整支持 DX11，引入 LDS 和分区 L2，1600 个 SP 在 850 MHz 下提供约 2.72 TFLOPS。Cypress 是 AMD 第一代将 DX11 图形能力、通用计算支持、LDS 与完整缓存组织整合到同一高端 GPU 的产品。

Cayman（HD 6970，TeraScale 3）是 VLIW 架构最后一代。VLIW5→VLIW4 的改动、双曲面细分单元、改进的 FP64 支持（1/4 FP32 速率）均为 GCN 转型铺垫。VLIW4 的对称 ALU 设计更接近标量架构，编译器调度难度的降低为后续 ISA 重构积累了经验。

TeraScale 在 GPGPU 竞争中的位置

TeraScale 与同期 NVIDIA Tesla/Fermi 的竞争揭示了两种 GPGPU 设计哲学：

• NVIDIA 标量 SIMT：每 SM 内多个 CUDA Core，每 Core 每周期执行一条标量指令，硬件动态调度保证稳定 IPC。CUDA 生态的先发优势、稳定性能表现、低优化门槛使其在 HPC 和 AI 市场占据主导。
• AMD VLIW：编译器静态打包实现更高峰值吞吐，但性能高度依赖 workload 特征。图形渲染场景下差距不大（图形着色器 ILP 通常足够填满大部分 VLIW 槽位），通用计算场景下处于结构性劣势。

峰值吞吐不等于实际性能，编译器友好性和工作负载适应性是架构竞争力的核心要素。AMD 在 GCN 中放弃了 VLIW 的软件负担，转向标量 SIMT 设计。

Stream Output 与几何着色器

TeraScale 引入 Stream Output 机制，允许顶点着色器直接将结果写入显存，绕过 ROP，供后续渲染或计算任务复用。Geometry Shader（DX10 引入）从 R600 起完整支持：GS 在图元级别生成新顶点和图元，UTDP 调度器通过 GS 输出阶段临时缓冲区处理可变数量输出，避免下游光栅化阶段产生流水线气泡。

HyperZ 技术演进

HyperZ 包含三个核心组件：

• Hierarchical Z（Hi-Z）：粗粒度深度剔除。深度缓冲划分为 tile，每 tile 记录最大/最小深度值。新图元深度在 tile 范围内不可能通过测试时，整 tile 提前剔除。场景几何复杂、遮挡关系明确时效果最突出。
• Z Compression：深度缓冲无损压缩，压缩率 2:1 至 4:1，减少深度缓冲读写显存带宽。
• Fast Z Clear：Hi-Z 层面标记缓冲区"已清除"，清除开销从 O(分辨率) 降至 O(tile 数量)。

TeraScale 2（Evergreen）增强了 HyperZ 与 MSAA 的协同，支持多重采样模式下的 Hi-Z 剔除和 Z Compression。

显存控制器与仲裁策略

TeraScale 显存控制器管理来自着色器全局 Load/Store、纹理采样、ROP 帧缓冲读写、DMA 传输等的并发请求。仲裁综合考虑请求紧迫程度（ROP 帧缓冲写入优先级通常高于着色器全局读取）、访问模式（顺序访问更易合并，带宽利用率更高）、各单元队列深度（避免队列溢出）。GDDR5 引入后，Evergreen 对显存控制器优化了预取算法和队列管理，以在高延迟条件下维持高带宽利用率。

二、GCN

Graphics Core Next (GCN) 是 AMD 在 2012 年推出的 GPU 微架构，覆盖初代 Southern Islands（HD 7970/Tahiti 等）和第二代 Sea Islands/Hawaii（R9 290X 等）。这一架构将 GPU 的执行模型从以 Instruction-Level Parallelism (ILP) 为主的 VLIW 模型，彻底迁移到以 Thread-Level Parallelism (TLP) 为主的标量 SIMD 模型。

GCN 的核心判断是：TeraScale 的问题不在于峰值算力不足，而在于 VLIW 的软件负担与现实工作负载的 ILP 供给之间存在结构性失配。当着色器分支密集、访存不规则时，VLIW 槽位大量空置，编译器无法静态填满。GCN 的回答是：放弃让编译器挖掘 ILP，转而让硬件在多个 wavefront 之间动态选择就绪指令，用 TLP 覆盖延迟。这一转变的代价是单 wavefront 的 ILP 利用率不再是性能来源，收益是对更广泛工作负载的稳态吞吐更加可预期。

2.1 GCN 1.x-2.x

2.1.1 ISA

GCN 放弃了 TeraScale 的 VLIW 指令集，转向精简的标量 ISA。每条指令不再是多个操作的静态捆绑，而是执行单一的标量或向量操作。指令格式采用 32-bit 或 64-bit 变长编码，可附加 32-bit 立即数。

标量/向量双轨 ISA 与寄存器分工

GCN ISA 的核心区分是标量指令（SALU/SMEM）与向量指令（VALU/VMEM）的分离。这一区分贯穿执行单元、寄存器文件、数据路径和调度机制，是全局性的设计决策。

SALU（Scalar ALU）指令作用于整个 wavefront 内所有 lane 共享的 uniform 数据，包括：地址基址计算（如全局内存访问的基地址）、循环计数器、分支条件判断、workgroup/线程索引的 uniform 部分。这些数据存储在 SGPR（Scalar General Purpose Register）中，每个 wavefront 拥有独立的 SGPR 集合（编程模型上最多 102 个，实际可用受物理容量约束），由 CU 内独立的标量寄存器文件和标量 ALU 处理。

VALU（Vector ALU）指令作用于 wavefront 内每个 lane 各自的数据，即 per-lane 的线程私有数据，存储在 VGPR（Vector General Purpose Register）中。每个 SIMD 配备独立的 VGPR 文件（约 64KB），由该 SIMD 内的 16-wide 向量管线执行。

scalarization 的核心机制：编译器通过静态分析识别出 wavefront 内所有 lane 计算结果相同的操作（如 uniform 地址偏移、循环计数、分支条件），将其从 VALU 指令提取为 SALU 指令。这样做的好处是双重的：一是节省 VGPR 空间（原本需要在 64 个 lane 的 VGPR 中各存一份的数据，现在只需在 SGPR 中存一份）；二是释放 VALU 执行资源，使向量管线可以专注于非 uniform 的数据并行计算。对于含有大量 uniform 计算的控制流密集型内核，scalarization 可将 VGPR 用量降低 30%–50%，直接转化为更高的 resident wavefront 数量和更好的 latency hiding 能力。

分支与 Execution Mask 的硬件行为

GCN 保留了 wavefront 级别的 Execution Mask（EXEC mask）机制处理控制流分歧。EXEC mask 是一个 64-bit 的位掩码，每个 bit 对应 wavefront 内一个 lane 的执行状态：bit 为 1 表示该 lane 激活执行，为 0 表示被屏蔽。

当 wavefront 遇到条件分支时，SALU 计算分支条件（通常是比较操作的结果），生成两个互补的 EXEC mask：一个对应 if 路径的 active lane 集合，另一个对应 else 路径。硬件首先用 if-mask 执行分支体，被屏蔽的 lane 在向量管线上不写入结果，但对应的发射周期仍消耗，因此有效 lane 利用率下降（被屏蔽 lane 仍占用 wavefront slot 和寄存器）；然后切换到 else-mask 执行另一分支体。两个路径串行执行，直到 reconvergence 点汇合后 EXEC mask 恢复为全 1。

与 TeraScale 的关键区别：GCN 的分支条件判断本身由 SALU 完成，不消耗 VALU 资源。在 TeraScale 中，分支条件需要在 VLIW ALU 中计算，既占用向量槽位又增加编译器调度难度。GCN 的 scalarization 让 Hardware Scheduler 可以在 VALU 处理分支体 A 的同时，用 SALU 为另一个 wavefront 计算分支条件 B，标量/向量管线并行利用。

EXEC mask 的分歧代价是可量化的：在最大分歧情况下（如 32 个 lane 走 if、32 个 lane 走 else），有效执行时间翻倍，向量管线利用率降至 50%。分歧越严重，被屏蔽的 cycle 比例越高。这与 NVIDIA Warp32 的分歧代价结构相同，但 Wave64 的绝对代价是 Wave32 的两倍：同一分支在 Wave64 上串行执行两个 64-lane 路径，而 Wave32 只需串行执行两个 32-lane 路径，绝对 cycle 数减半。

waitcnt 与 Dependency Tracking 机制

GCN ISA 显式暴露内存和指令依赖管理，这是 AMD 与 NVIDIA 在 compiler/ISA/hardware scheduler 复杂度分配上的关键差异点。NVIDIA 采用硬件 scoreboard 隐式追踪依赖，编译器无需关心；AMD 采用 waitcnt 指令，由编译器显式插入、硬件执行。

waitcnt 指令的语义：编译器在生成代码时，根据指令间的数据依赖关系，在需要等待的位置插入 waitcnt 指令，携带一个计数器阈值。硬件维护多组独立的 in-flight operation counter：

• vmcnt：追踪向量内存操作（VMEM，包括全局 Load/Store 和纹理采样）的完成状态。每次向量内存指令发射时 vmcnt 递增，对应操作完成时递减。waitcnt vmcnt(N) 表示"阻塞直到 in-flight VMEM 操作数量 ≤ N"。
• lgkmcnt：追踪 LDS（DS 指令）、标量内存（SMEM）和 GDS 操作的完成状态。这三类操作共享 lgkmcnt 计数器。
• expcnt：追踪 Export 操作（颜色/深度输出到 ROP）的完成状态。
• vscnt（GCN 5/Vega 新增）：追踪向量存储（Store）操作的完成状态，将 vmcnt 的 Load/Store 混合计数拆分为独立的 Store 追踪。

这一设计的因果链：编译器在编译期分析数据依赖图，确定每条消费指令需要等待哪些生产指令的 outstanding counter 归零，据此计算 waitcnt 的阈值参数并嵌入指令流。Hardware Scheduler 在运行时解码 waitcnt 指令，将 wavefront 标记为等待状态，持续比较硬件 counter 当前值与阈值，当条件满足时将 wavefront 移回就绪队列。waitcnt 等待的是 outstanding operation counter 的完成计数，而非编译器预测 L1/L2/HBM 的具体周期数：编译器只需识别依赖关系并插入 waitcnt，硬件 counter 在操作真正完成时自动递减。

waitcnt 模式的代价与收益：编译器要正确识别指令间的依赖关系并插入合适的 waitcnt 阈值，但不必精确预测每条指令的绝对延迟（缓存命中/未命中的不确定性由硬件 counter 隐藏）。waitcnt 阈值设置过松会导致数据冒险（读取未就绪数据），设置过紧会不必要地阻塞 wavefront 降低 occupancy。优点是硬件逻辑简单，不需要复杂的 scoreboard 和动态依赖分析电路；缺点是编译器需正确建模依赖图，且面对延迟不确定时难以选择最优阈值。这反映了 AMD 在 GCN 时代选择将复杂度推向编译器和 ISA 的设计哲学。

ISA 扩展

第二代 GCN（Sea Islands/Hawaii）在 ISA 层面扩展了原子操作和内存一致性指令，增强了 FP64 和整数位运算支持。部分 GCN 3 代特性（如 wave 级投票、ballot 操作）在这一时期开始奠基。Wave 级投票指令（如 vcc = vote(any/same)）允许 wavefront 内的 lane 之间进行轻量级通信，是后续 wave reduction 操作的基础。

与 Vol.1 的公约数模型和 Vol.2 NVIDIA 的承接关系

GCN ISA 的标量/向量分离与 Vol.1 讨论的 SIMT 执行模型存在直接对应：SALU 处理 uniform 控制流（对应 SIMT 中的 scalar 路径），VALU 处理数据并行计算（对应 SIMT 中的 vector 路径），EXEC mask 对应 SIMT 的分支分歧掩码机制。与 Vol.2 NVIDIA Kepler 的对比：NVIDIA 采用统一的 SIMT 模型（warp scheduler 驱动 CUDA core 执行标量指令，无显式的标量/向量 ISA 分离），依赖硬件 warp scheduler 和 scoreboard 隐式管理依赖；AMD GCN 通过 SALU/VALU ISA 显式分离和 waitcnt 显式依赖管理，将更多调度复杂度暴露在 ISA 层面。Wave64（AMD）vs Warp32（NVIDIA）的宽度差异直接影响分支分歧代价、寄存器分配粒度和 occupancy 计算方式。

2.1.2 Scheduling

GCN 的调度分两层：前端的宏观任务调度由 Command Processor (CP) 和 Asynchronous Compute Engine (ACE) 负责；CU 内部的 wavefront 调度由每个 CU 内的 Hardware Scheduler 负责。这两层的协同构成了 GCN 统一执行模型的核心骨架。

统一执行模型完整路径

GCN 的完整执行路径可以描述为：Command Processor / ACE（前端任务分发）→ Workgroup Dispatch（workgroup 分配到 CU）→ Wavefront Dispatch（Hardware Scheduler 将 workgroup 分解为 wavefront 并分配给 SIMD）→ Hardware Scheduler 轮询选择就绪 wavefront → 指令发射前检查 waitcnt/dependency 条件 → Scalar/Vector Operand Read（从 SGPR/VGPR/LDS/Cache 读取操作数）→ SALU/VALU/VMEM/SMEM/DS/TEX 执行 → Writeback（结果写回寄存器文件或内存）→ Dependency Counter Clear（waitcnt counter 递减）→ Wavefront 状态更新（就绪/等待/完成）。

关键问题的回答：

• 谁分发 work？ CP 负责图形命令流（Draw Call），ACE 负责计算 Dispatch Call。CP/ACE 将 workgroup 网格分发给各 Shader Engine 内的 CU。
• 谁选择 wavefront？ CU 内部的 Hardware Scheduler 从驻留的 wavefront 中选择处于就绪状态（操作数就绪、资源可用、waitcnt 条件满足）的 wavefront，每周期向其中一个 SIMD 发射指令，4 个 SIMD 轮转服务。
• 谁判断依赖？ 编译器在编译期通过 waitcnt 指令显式标记依赖点，Hardware Scheduler 在运行期通过硬件 dependency counter（vmcnt/lgkmcnt/expcnt）执行实际的等待/唤醒操作。
• SALU 和 VALU 如何分工？ SALU 处理 uniform 工作（地址计算、分支判断、循环控制），VALU 处理 per-lane 数据并行工作。两者在同一周期可分别服务不同 wavefront，构成 CU 内部的隐式 ILP。
• VGPR/SGPR 如何影响 occupancy？ 每个 SIMD 的 VGPR 文件约 64KB，10 个 wavefront 共享。一个直观的估算示例（仅考虑 VGPR）：驻留 10 个 wavefront 时每个 wavefront 约可用 25 个 VGPR（64KB ÷ 10 ÷ 64 lane ÷ 4 byte）；若 wavefront 需要 50 个 VGPR，则每个 SIMD 只能驻留 5 个 wavefront，CU 总 resident wavefront 从 40 降至 20。但这只是简化示例，实际 occupancy 还受 SGPR、LDS、workgroup 数量上限、barrier buffer 容量、scratch memory 需求以及硬件 wave slot 上限共同约束，取各维度限制的最小值。resident wavefront 数量 → eligible wavefront（处于就绪状态的子集）→ Hardware Scheduler 的选择空间 → latency hiding 能力 → 执行单元利用率。
• LDS 何时成为瓶颈？ 两个条件：一是容量限制，每个 CU 64KB LDS，一个 workgroup 内所有 wavefront 共享，LDS 分配超出容量时编译报错；二是 bank conflict，LDS 32-bank 结构，同一 cycle 多个 lane 访问同一 bank 的不同地址时产生冲突，访问串行化。LDS 容量约束直接限制 workgroup 规模，进而影响每个 CU 可分配的 workgroup 数量和 resident wavefront 数量。

前端调度：CP / ACE

CP 负责接收图形命令流（Draw Call），解析并分发给图形管线前端（Shader Engine）。ACE 是独立于 CP 的硬件计算任务队列处理器，负责将 Dispatch Call 分发给 CU。初代 GCN 支持最多 2 个 ACE，第二代 Hawaii 提升至 8 个。

ACE 独立于 CP 运行，允许 GPU 同时处理来自多个独立命令队列的任务流（Async Compute）。这是 GCN 相对 TeraScale 的重要前端升级：TeraScale 的 UTDP 主要做时间片分配，而 GCN 的 ACE 允许图形与计算任务在 CU 上交错执行。但"并发"不等于"无资源竞争"：图形和计算任务共享同一组 CU、L2 缓存、LDS、显存带宽和 ROP，当两者同时满载时，cache contention（L1/L2 争用）和 memory bandwidth contention 会导致双方的实际吞吐低于独立运行时的峰值。ACE 的价值在于消除任务提交层面的串行等待，使 CU 在图形管线停顿（如等待 ROP 完成帧缓冲操作、等待显存读取纹理数据）时可以立即切换到计算任务，减少执行单元的空闲 cycle。

task / workgroup / wavefront 的分解关系

一个 Dispatch Call 定义了三维的 workgroup 网格。CP/ACE 将 workgroup 分配给可用的 CU，每个 CU 接收一个或多个 workgroup。CU 内部的 Hardware Scheduler 将每个 workgroup 进一步分解为 wavefront（每个 wavefront 64 个 work-item），并将这些 wavefront 分配给 CU 内的 4 个 SIMD。每个 SIMD 最多同时追踪 10 个 wavefront，因此每个 CU 最多同时驻留 40 个 wavefront（2560 个 work-item）。

CU 内部调度：Hardware Scheduler

Hardware Scheduler 在 4 个 SIMD 之间轮转：每个周期选择某一 SIMD，检查其驻留的最多 10 个 wavefront，判断是否有 wavefront 的下一条指令就绪（操作数已准备好，所需执行资源可用，waitcnt 条件满足）。选定就绪 wavefront 后，将其指令发射给该 SIMD 执行。一个 wave64 向量指令在同一 SIMD 上需 4 个周期完成（16 lane/周期），因此每个 SIMD 约每 4 个周期接收一条新 wave 指令。

GCN CU 的 issue 模型是：CU 级稳态每周期可覆盖 64 lane 的 FP32 FMA 吞吐（4 SIMD × 16 lane），外加独立的标量 ALU 每周期可发射一条标量指令（来自另一个 wavefront）。Hardware Scheduler 每周期向某一 SIMD 发射向量指令，4 个 SIMD 轮转；标量 ALU 独立选择就绪 wavefront 发射。这不是"4 个 SIMD 各自每周期独立发射"的模型，而是轮转发射、每个 SIMD 约每 4 cycle 接收新指令。不同 SIMD 在同一时刻服务的指令来自不同 wavefront，这是 GCN 利用 TLP 的核心机制。

延迟隐藏

当一个 wavefront 因等待全局内存访问（数百个时钟周期）而阻塞时，Hardware Scheduler 立即从就绪队列中选择另一个 wavefront 发射，无需保存/恢复上下文（每个 wavefront 的寄存器状态始终驻留在寄存器文件中）。这种切换以 cycle 级速度完成，是 GCN 延迟隐藏的主要机制。

延迟隐藏的效果取决于 occupancy：occupancy 越高，Hardware Scheduler 在任意时刻找到就绪 wavefront 的概率越大，执行单元的利用率越接近峰值。occupancy 的具体约束链：per-wave VGPR count → VGPR allocation granularity（以 4 个寄存器为粒度）→ 每个 SIMD 可驻留的 wavefront 数量 → CU 总 resident wavefront → eligible wavefront（满足就绪条件的子集）→ Hardware Scheduler 的有效选择空间。当 eligible wavefront 数量不足时（如所有 wavefront 都在等待内存），SIMD 进入空闲状态，利用率下降。

wavefront buffers 与 barrier buffers

GCN 为每个 CU 维护 wavefront buffer（追踪驻留 wavefront 的 PC、状态、等待条件）和 barrier buffer（追踪 workgroup 内的 barrier 同步状态）。当一个 wavefront 执行 barrier 指令时，它进入等待状态，直到同一 workgroup 内所有 wavefront 都到达 barrier 点。barrier buffer 的容量限制了单个 CU 内可以同时处于 barrier 等待状态的 workgroup 数量，这是影响 occupancy 的另一个约束。

2.1.3 ExecutionUnit

GCN 的基本执行模块是 Compute Unit (CU)。每个 CU 包含 4 个并行的 16-wide SIMD 向量管线，以及 1 个独立的标量 ALU。

4×SIMD16 向量管线

每个 SIMD 宽度为 16，即一次可对 16 个 lane 执行同一条向量指令。一个完整的 64-lane wavefront 需要在同一 SIMD 上分 4 个周期执行完一条向量指令（16 lane/周期）。4 个 SIMD 并行，理论上每个 CU 每周期可完成 64 次 FP32 MAD 操作（4 SIMD × 16 lane × 1 MAD/周期）。

这一数字与 TeraScale VLIW5 的理论峰值相当，但实现方式根本不同：TeraScale 需要编译器在单个 wavefront 内找到 5 条独立指令同时打包，GCN 只需要硬件找到 4 个独立的就绪 wavefront 分别驱动 4 个 SIMD。后者对工作负载的要求是"足够多的并行 wavefront"，而不是"足够高的单线程 ILP"，这在实际工作负载中更容易满足，因为 kernel 的 wavefront 数量由 grid 尺寸决定，通常远大于 4，而单 wavefront 内的 ILP 则受限于数据依赖和控制流结构。

标量 ALU

每个 CU 有 1 个独立的标量 ALU，执行 SALU 指令（整数运算、分支判断、地址计算等）。标量 ALU 与向量 SIMD 并行运行，可以在同一周期内分别服务不同的 wavefront：一个 wavefront 的向量指令在某个 SIMD 上执行，另一个 wavefront 的标量指令在标量 ALU 上执行。这种并行是 GCN CU 内部的一种额外 ILP，不需要编译器显式安排，Hardware Scheduler 自动完成调度。

FP64 与特殊功能

初代 GCN（Tahiti）的 FP64 执行速率为 FP32 的 1/4，面向 HPC 需求。第二代 GCN（Hawaii）将 FP64 降至 FP32 的 1/8，更加平衡能效和面积成本。超越函数（sin、cos、exp、log 等）由专用特殊函数单元（SFU）处理，执行速率约为 FP32 的 1/4。

纹理单元

每个 CU 配备专用纹理单元组（TMU），与向量 SIMD 并行工作。TMU 拥有独立的纹理缓存路径（Texture Cache），不占用全局 VMEM Load/Store 路径的带宽。纹理采样请求从 TMU 发出，经纹理缓存命中时直接返回数据，未命中时访问 L2 缓存，最终可能到达显存。

2.1.4 RegisterFile

GCN 将寄存器文件按 CU 内的 SIMD 单元拆分，并引入独立的标量寄存器文件，以匹配标量/向量双轨 ISA 的需求。

向量寄存器文件（VGPR）

每个 SIMD 配备独立的向量寄存器文件（VGPR），容量约 64KB，以多 bank 结构实现并行读写端口。VGPR 按 lane 组织：每个 lane 有独立的寄存器槽位，一个 wavefront 的 64 个 lane 分别使用各自的 VGPR 存储线程私有数据。

每个 SIMD 最多同时驻留 10 个 wavefront，这 10 个 wavefront 共享该 SIMD 的 64KB VGPR。编程模型上限与物理可用上限不同：GCN ISA 允许每个 wavefront 最多使用 256 个 VGPR（这是编译器可见的地址空间），但物理可用的 VGPR 数量由驻留 wavefront 总数决定。以下是一个直观的简化示例（仅考虑 VGPR 约束）：当 10 个 wavefront 同时驻留时，每个 wavefront 约可用 25 个物理 VGPR（64KB ÷ 10 ÷ 64 lane ÷ 4 byte）。若编译器为一个 wavefront 分配了 128 个 VGPR，则该 SIMD 只能驻留 2 个 wavefront（64KB ÷ 128 VGPR ÷ 64 lane ÷ 4 byte ≈ 1.95），CU 总 resident wavefront 从 40 骤降至 8。阶梯边界大致为：每 wavefront 的 VGPR 用量不超过 24 个时可驻留 10 个（wave slot 硬限制生效），25–48 个时可驻留 5 个，49–64 个时可驻留 3 个。这就是 occupancy cliff：当 VGPR 用量超过阈值时，resident wavefront 数量呈阶梯式骤降，Hardware Scheduler 的选择空间急剧收缩，latency hiding 能力随之下降。完整 occupancy 计算还需纳入 SGPR、LDS、workgroup 数、barrier、scratch memory 等约束，开发者应通过 AMD 提供的 occupancy calculator 工具精确求解。

在 Tahiti（GCN 1.0）上，VGPR 分配粒度为每 4 个寄存器一组，进一步限制实际可用数量。

VGPR bank conflict：VGPR 的多 bank 结构在多数情况下可以并行服务多个操作数读取，但当同一指令的多个源操作数恰好映射到同一 bank 的不同地址时产生冲突，读取串行化，引入额外等待周期。bank conflict 会被硬件仲裁、重放或排队处理，具体额外周期取决于实现。编译器可以通过调整寄存器分配策略减少 bank conflict 概率。

标量寄存器文件（SGPR）

每个 CU 有 1 个独立的标量寄存器文件（SGPR），供标量 ALU 使用。SGPR 存储 wavefront 内所有 lane 共享的数据：常量地址基址、循环计数、分支条件、workgroup ID、dispatch ID 等。将这些数据放入 SGPR 而非 VGPR 节省 VGPR 空间（64 个 lane 各存一份变成只存一份），同时 SALU 读取 SGPR 的延迟低于 VALU 读取 VGPR。

每个 wavefront 可用的 SGPR 数量受物理容量和分配粒度双重约束。Tahiti 每个 wavefront 最多 102 个 SGPR（编程模型），但实际可用数量同样遵循共享原则。SGPR 容量不足时限制 resident wavefront 数量，构成与 VGPR 平行的 occupancy 约束维度。实际调优中，SGPR 很少成为瓶颈（大多数 kernel 的 SGPR 用量在 20–60 之间），但在控制流极其复杂的 kernel 中可能触发约束。

寄存器文件对 Occupancy 的定量影响

occupancy 的简化估算模型由 VGPR、SGPR、LDS、workgroup size 和 wavefront slot（每 SIMD 10 个）等多个维度共同约束，取各维度限制的 resident wavefront 最小值。以下约束链仅作示意：

• VGPR 约束（示例）：VGPR_per_wave × 64 lane × 4 byte × num_wave_per_SIMD ≤ 64KB → max_wave_per_SIMD = floor(64KB / (VGPR_per_wave × 256 byte))
• LDS 约束：LDS_per_workgroup × num_workgroup_per_CU ≤ 64KB → 结合 workgroup size 推算 wavefront 上限
• SGPR 约束：SGPR 容量与分配粒度同样限制 resident wavefront 数量
• Barrier 约束：barrier buffer 容量限制同时处于同步等待的 workgroup 数量
• Slot 约束：每 SIMD 最多 10 个 wavefront（硬限制）

VGPR 维度的阶梯计算（驻留 wavefront 数随 VGPR 用量阶梯式下降，即 occupancy cliff）推导同该节 VGPR 段落；它是 GCN 性能调优的核心关注对象，实际场景中 SGPR、LDS、barrier、scratch memory 和 workgroup 数量上限都可能成为比 VGPR 更紧的约束。

2.1.5 MemorySubsystem

GCN 建立了明确的分层缓存体系，将 GPU 从固定纹理缓存模型演进为通用处理器式的内存层级。GCN 的内存子系统包含多条独立的数据路径，每条路径服务不同类型的访问请求。

内存路径拆分

• VMEM（Vector Memory）路径：服务 VALU 发起的全局内存 Load/Store 指令，经过 CU 内的 16KB 向量 L1 数据缓存（4-way set associative，64-byte cache line，write-through）。VMEM 是通用计算内核访问全局内存的主要路径。L1 一致性边界在 CU 级别：同一 CU 内的 wavefront 可通过 L1 共享数据，不同 CU 之间的 L1 不保证一致性。需要跨 CU 一致性的访问必须通过 L2（使用 coherent load 指令或显式 cache flush）。
• SMEM（Scalar Memory）路径：服务 SALU 发起的标量内存加载指令，访问常量数据和 uniform 内存。SMEM 经过由相邻若干 CU 共享的标量缓存（Scalar Cache），命中延迟低于 VMEM 路径。凡是通过标量指令加载的数据走此路径，无需程序员显式标注内存区域。
• TEX（Texture）路径：服务纹理采样指令，经过独立的 Texture Unit（TMU）和 Texture Cache。TEX 路径与 VMEM 路径在 L1 层面分离，互不竞争，但两者共享 L2 缓存和显存带宽。TMU 处理过滤、坐标计算和格式转换，Texture Cache 缓存最近使用的纹理数据。
• DS（Data Share / LDS）路径：服务同一 workgroup 内 wavefront 之间的快速数据交换。LDS 是软件可编程的 scratchpad memory，不走缓存层次。64KB/CU，32-bank 结构，每 bank 每周期可读出 1 个 32-bit 数据，总带宽 128 byte/周期。LDS 原子操作（add/min/max/compare-and-swap）在同一 CU 内硬件保证。LDS bank conflict 时访问串行化，是 LDS 编程的核心优化点。
• RB（Render Backend / ROP）路径：服务像素输出阶段的颜色/深度写入。RB 通过独立的 ROP 单元执行混合、深度测试、颜色压缩，最终写入显存。不同世代的 RB-L2 关系存在差异：GCN 1.0/1.1（Tahiti 等）中 RB 主要经独立路径与显存控制器通信；GCN 1.2（Tonga）及之后 RB 逐步接入 L2 缓存路径；Vega 世代 RB 全面成为 L2 client。将这一演进倒推至所有 GCN 世代会造成代际混淆。

L1 数据缓存（向量 L1）

每个 CU 配备 16KB 向量 L1 数据缓存，4 路组相联，64-byte cache line，write-through 策略。L1 服务于 VMEM 路径的全局 Load/Store。相比 TeraScale 的 8KB 只读纹理缓存，GCN 的 L1 容量翻倍且支持写缓存，满足了通用计算工作负载对低延迟可写缓存的需求。

L1 的一致性边界在 CU 级别。跨 CU 一致性需要通过 L2 或显式 flush。

标量缓存（Scalar Cache）

GCN 为标量访问路径提供专用缓存，通常由相邻若干 CU 共享，用于存储 wavefront 统一访问的常量数据（通过 SMEM 指令访问）。标量缓存的命中延迟低于向量 L1，对着色器常量、物理仿真全局参数等 uniform 访问模式效果明确。

L2 缓存

片上全局 L2 缓存作为各 CU L1 之后的二级缓存，连接所有 CU 与后端显存控制器。L2 容量视 GPU 规格而定，Tahiti 为 768KB（6 个内存控制器，每个 128KB）。L2 是全 CU 共享的一致性域：不同 CU 的 L1 write-through 到达 L2 后，其他 CU 通过 L2 可以读到最新数据。ROP 的帧缓冲写入路径因代际而异：GCN 1.0/1.1 中 RB 主要经独立路径与显存通信，GCN 1.2 及之后逐步接入 L2，Vega 世代 RB 全面成为 L2 client。

DCC 与 HTILE 在 GCN 世代的状态

早期 GCN（GCN 1.0/1.1）已支持颜色/深度压缩用于节省显存带宽，但名为 Delta Color Compression（DCC）的现代机制通常从 Tonga（GCN 1.2）起进入公开开发者语境。不应将 GCN 1.0/1.1 的压缩能力等同于完整 DCC。DCC 压缩率取决于颜色数据的连续性，典型压缩比约 2:1 到 8:1。Hierarchical Z（HTILE）在 GCN 中作为 Hi-Z 机制的基础，存储每个 tile 的深度范围信息，用于早期深度剔除。两者在 GCN 世代的功能相对基础，为 RDNA 世代的增强（如 DCC 的端到端压缩数据流、HTILE 的更大 tile size 和更精细的层次结构）铺垫。

虚拟内存与 PRT

GCN 引入了完整的 GPU 内存管理单元（IOMMU v2），支持 GPU 线程使用虚拟地址访问系统内存。GCN 还支持 Partially Resident Textures (PRT，对应 DX11.2 Tiled Resources Tier2）：通过 64KB 页粒度的虚拟内存映射，GPU 只加载实际用到的纹理页。

显存接口

Tahiti 采用 384-bit GDDR5 接口，提供约 288 GB/s 峰值带宽；Hawaii 扩展至 512-bit，峰值带宽约 320 GB/s。ROP 单元通过片内高速总线与任意内存控制器相连。

GCN 在寻址模型上完成了一次完整的位移：SGPR 承载 wavefront 共享的地址基址，SALU 执行标量地址计算，SMEM 路径经共享标量缓存服务 s_load，IOMMU v2 将全部可访问内存纳入平坦的 64-bit 虚拟地址空间。资源访问在指令层退化为一次标量指针加载加上若干次向量 Load/Store。这个位移对上层图形 API 的含义超出了内存子系统本身。

Descriptor 在指令层的真实形态只是 SGPR 中的一组标量值。GCN 把 GPU 从固定纹理缓存模型推进到通用处理器式的内存层级，descriptor 的归宿也随之从绑定点表项变为普通内存中的字节。一个 buffer descriptor 的内容是基地址、尺寸与格式字段，经标量路径加载进 SGPR，再由向量指令的寻址模式消费；其加载完成状态与常量加载一样，由 lgkmcnt 计数器追踪。高层 API 里那个需要在 CPU 侧录制、切换并付出整套状态跟踪代价的巨型不透明 Descriptor 结构，在硬件上没有对应物。它是早期 GPU 缺乏通用逻辑寻址、资源只能走固定纹理寻址路径的时代留下的代偿：硬件只会按绑定点查表，API 便把查表动作封装成一等抽象。硬件转向平坦寻址之后，这个抽象没有随之退役，反而在 CPU 侧持续增重，每次绑定切换都要重新校验、重新生成 GPU 可见的 descriptor 内存。

Bindless 正确的部分在指令层：平坦寻址下，任何资源访问确实都可以退化为一次指针加载。但它的代价被系统性低估。索引规则时，descriptor 指针经 s_load 一次加载、全 wavefront 共享，这正是标量路径的设计场景；索引发散时，同一条加载退化为逐 lane 的独立访问，标量缓存的共享假设随之失效。当 working set 规模过大，或资源索引来自不规则的稀疏数据时，发散的资源索引（divergent resource indexing）会剧烈破坏 descriptor cache 的局部性：不同 lane 指向不同 descriptor，每个并发 wavefront 各自等待自己的 descriptor fetch。再往下是 TLB miss 与 page walk 的长尾延迟，一次未命中就是数百个周期的零利用率停顿；occupancy 越高，同时踩中长尾的 wavefront 越多，停顿越整齐。3.2.5 节的物证将进一步表明：Infinity Cache 解决不了 TLB miss，descriptor fetch 的延迟也独立于它的数据路径。

判断分两层。硬件层上，资源绑定已经退化：Descriptor Table 的表项只是待加载的标量字节，切换一组绑定等价于换一批 SGPR 初值，与 compute kernel 的传参没有本质区别。API 层上，资源模型不应以无节制的 indirection 为荣。从物理吞吐稳定性看，可控的 Descriptor Table 把索引集中度暴露在驱动与引擎面前，局部性可以被显式管理；从 RHI 调试确定性看，绑定点有限、可枚举、可校验，错误在提交时暴露，而不是在 page walk 长尾里随机出现。支持细粒度局部控制、拒绝无限 indirection 的 Descriptor Table 模型，才是高并发引擎设计中更有工程价值的路径。RDNA 4 的 SCOPE hint 把一致性操作粒度交给编译器标注，说明连缓存一致性域都在向软件显式管理迁移。内存模型退化到这一步之后，API 的资源绑定层还剩多少独立存在的理由，需要用物理证据回答。

2.1.6 FunctionFeature

GCN 1.x-2.x 的图形与计算功能建立在前述 CU 结构之上，该节聚焦 ISA/调度/执行单元章节未覆盖的管线级特性和平台级能力。

Graphics

GCN 延续统一着色器架构，所有图形管线阶段（顶点、Hull、Domain、几何、像素、计算着色器）均由同构的 CU 执行。Tahiti 配备 2 个图形前端（Shader Engine），Hawaii 扩展至 4 个，每时钟最多处理 4 个三角形。

Hawaii 引入 XDMA 通道用于多卡互联（无桥 CrossFire），直接利用 PCIe 总线在 GPU 间交换帧缓冲。

GCN 完整支持 DirectX 11.1/11.2 和 OpenGL 4.x 特性，包括 Tiled Resources（PRT）等。

Compute

GCN 的 ACE 机制是其计算侧最重要的前端升级：多个 ACE 允许图形与计算任务在 CU 层面交错执行，而不是时间片轮转。在支持 DirectX 12/Vulkan 的应用中，开发者可以将计算任务安排为异步计算队列，与主渲染管线同时提交。

ACE 提供的"并发"存在资源竞争边界，其边界与价值定位已在 2.1.2 节澄清。

GCN 的标量 ISA 配合 Hardware Scheduler，使控制流复杂的计算内核不再因 VLIW 槽位空置而损失性能。ISA 层面的 scalarization 和 waitcnt 机制使编译器可以精确控制依赖管理，Hardware Scheduler 通过跨 wavefront 调度维持执行单元利用率。实际利用率取决于 occupancy：当 resident wavefront 足够多（通常 ≥ 20 个 wavefront/CU）时，Hardware Scheduler 在任意 cycle 找到就绪 wavefront 的概率高，SIMD 利用率趋近峰值；当 occupancy 较低时（如 < 8 个 wavefront/CU），所有 wavefront 同时等待内存的概率上升，SIMD 空闲 cycle 增加。

HPC 可靠性方面，GCN 引入了 ECC 支持（寄存器文件和 L2 缓存），这是 AMD 将 GPU 定位为计算加速器的重要信号。ECC 对科学计算和数据中心应用是基本要求。图形渲染通常不需要 ECC，因为单个像素的错误影响有限，而 ECC 会带来约 10–15% 的显存带宽和容量损失（用于存储校验位）。GCN 将 ECC 设计为可选功能。

2.1.7 小结

GCN 1.x-2.x 的核心贡献是完成了 AMD GPU 从"编译器主导 ILP"到"硬件主导 TLP"的架构迁移。这一迁移使单 wavefront 的 ILP 利用率不再是性能来源，但换来对更广泛工作负载的稳态吞吐更加可预期，以及对通用计算的适应性显著提升。

GCN 的关键不是"更强的硬件调度"五个字，而是把性能来源从单线程 ILP 迁移到了多 wave TLP，同时配合更简单可预期的标量 ISA。编译器不再为填满 VLIW 槽位做复杂的静态调度，开发者只需关注如何保持足够高的 occupancy，让 Hardware Scheduler 有足够多的就绪 wavefront 可以选择。

GCN 1.x-2.x 确立的架构范式（标量 ISA、CU 模块化扩展、分层缓存、ACE 异步计算）在之后的 GCN 3/Vega 时代持续演进，直到 RDNA 架构才做出下一次根本性的结构调整。

架构背景与设计动机

GCN 的诞生既是 AMD 对 NVIDIA CUDA 生态的追赶，也是 GPU 计算范式演进的结果。TeraScale 时代，AMD 的 VLIW 架构在图形渲染领域尚能维持竞争力，但 OpenCL、DirectCompute 等通用计算 API 兴起后，VLIW 的结构性弱点开始暴露。编译器需要在静态调度时预知所有指令间的独立性，但通用计算内核充满了分支、依赖和不规则访存，TeraScale 的实际利用率因此远低于理论峰值。

AMD 在 TeraScale 末期（Cayman/VLIW4）已经意识到这个问题，VLIW4 相对 VLIW5 的改动是在减少每周期的"赌注"：从 5 个槽位降到 4 个，降低了编译器填满指令束的难度，但没有解决根本问题。GCN 的决策是彻底放弃 VLIW，转向标量 ISA，放弃了 VLIW 在理想情况下的峰值优势，换取对更广泛工作负载的稳定性能。

GCN 与 NVIDIA Kepler 的对比视角

GCN 推出时，NVIDIA 的 Kepler 架构（GK104/GK110）是主要竞争对手。两者在设计哲学上有明显差异：

Kepler 的 SMX 拥有 192 个 CUDA Core（FP32 ALU），每个 SMX 每周期可发射多条指令（通过 warp scheduler 的多发射机制）。GK110 的每个 SMX 有 4 个 warp scheduler，每个 scheduler 每周期可发射 2 条指令。这种设计使 Kepler 在单个 SM 的指令吞吐上更高，但也需要更复杂的 warp scheduler 逻辑。

GCN 的 CU 设计更为精简：4 个 SIMD16 + 1 个标量 ALU，Hardware Scheduler 在 4 个 SIMD 之间轮转发射，CU 级稳态每周期覆盖 64 lane 的 FP32 FMA 吞吐。GCN 通过更多的 CU 数量弥补单 CU 的吞吐差距：Tahiti 有 32 个 CU，而 GK104 只有 8 个 SMX。这种"小而多"的设计使 GCN 在扩展性上更好，但对工作负载的并行度要求更高。

在 FP64 性能上，两者的差距最为突出：GCN Tahiti 的 FP64 为 FP32 的 1/4，而 Kepler GK104（游戏卡）的 FP64 仅为 FP32 的 1/24。这一差距使 GCN 在 HPC 应用中具有优势。

Wave64（GCN）与 Warp32（NVIDIA）的执行宽度差异是架构对比的另一维度：两者的最大分歧代价结构相同、绝对 cycle 数差一倍（机制分析同 2.1.1 节），RDNA 引入 Wave32 的直接动因即源于此。

ACE 机制的实际意义与资源竞争边界

在 TeraScale 时代，GPU 的工作提交通过单一的 Command Processor 进行，图形和计算任务必须串行提交。GCN 的 ACE 引入了独立的计算任务队列，允许计算任务在图形任务执行期间并行提交和调度。当图形管线的某个阶段（如顶点着色）完成后，CU 可以开始执行来自 ACE 队列的计算任务，而不需要等待整个图形帧完成。

ACE 的实际收益受资源竞争条件限制，其边界与最大价值场景同 2.1.2 节的澄清。

初代 GCN 支持 2 个 ACE，第二代 Hawaii 提升至 8 个。更多的 ACE 意味着可以同时管理更多的独立计算任务流，在 DirectX 12 和 Vulkan 的多队列模型下，应用程序可以将不同类型的计算任务分别提交到不同的 ACE 队列。

GCN 的 Shader Engine 与图形前端架构

GCN 将图形前端组织为 Shader Engine（SE）。每个 SE 包含一组 CU、一个几何处理器（Geometry Processor）、一个光栅器（Rasterizer）和若干 ROP 单元。Tahiti 有 2 个 SE，每个 SE 包含 16 个 CU；Hawaii 扩展至 4 个 SE，每个 SE 包含 11 个 CU（总计 44 个 CU）。

SE 的设计使图形管线的前端（几何处理、光栅化）与后端（像素着色、ROP）可以独立扩展。增加 SE 数量可以同时提升几何处理吞吐和像素着色能力，而不需要同比增加显存带宽。

GCN 架构的局限性与 RDNA 的动机

尽管 GCN 在 2012 年是合理的架构选择，但其局限性逐渐显现：

Wave64 在分支密集的着色器中分歧代价尤为突出，是 Wave32 的两倍，机制与量化同 2.1.1 节。

GCN 的 Hardware Scheduler 在 CU 内部是相对固定的轮询调度，缺乏对优先级和延迟的精细控制。

GCN 的 L1 缓存（16KB/CU）在现代高分辨率渲染场景下命中率下降，导致更多的 L2 和显存访问。

VGPR 按 64 lane 全量分配，无法根据实际活跃 lane 数量动态调整，在稀疏计算场景下浪费寄存器资源。

这些局限性在 Vega 中有所缓解，但未彻底解决。RDNA 的推出是 AMD 在积累了 7 年 GCN 经验后，对游戏 GPU 架构的系统性重构。

2.2 GCN 5/Vega

GCN 5（Vega，2017 年）是 GCN 体系的最后一代重大演进。Vega 在继承 GCN 基础框架的同时，引入了几项关键改进：Draw Stream Binning Rasterizer (DSBR)、Rapid Packed Math（FP16 双倍吞吐）、HBM2 显存与 High-Bandwidth Cache Controller (HBCC)、Primitive Shader/NGG 前端，以及面向专业计算的 SR-IOV 虚拟化支持。

Vega 的底层执行结构（NCU，Next-Generation Compute Unit）保持 GCN 的基本范式：4 个 SIMD16 + 1 个标量 ALU，Wave64 执行模型，Hardware Scheduler 轮询调度。改进集中在频率容忍度、混合精度执行、内存子系统和图形前端，而非 CU 核心结构的重新设计。

2.2.1 ISA

Vega 延续 GCN 的标量+向量 ISA 框架，在以下方向扩展：

混合精度与 Rapid Packed Math

Vega ISA 层面最大的变化是对半精度浮点（FP16）和低精度整数的原生支持。Rapid Packed Math 的硬件机制是：当执行 FP16 运算时，每个 32-bit ALU 通路可以拆分为两个 16-bit 数据通路，同时处理两个 FP16 操作。这 NCU 的 FP16 峰值吞吐达到 FP32 的 2 倍（256 FP16 FLOP/周期 vs 128 FP32 FLOP/周期，即 128 FP16 FMA/周期 vs 64 FP32 FMA/周期）。INT8 运算可以进一步拆分为 4 个 8-bit 操作，峰值吞吐达到 FP32 的 4 倍（512 INT8 FLOP/周期，即 256 FMA/周期）。

Rapid Packed Math 的精度代价：FP16 的表示范围（约 5.96×10⁻⁸ 至 65504）和精度（约 3–4 位有效十进制数字）远低于 FP32（范围约 1.18×10⁻³⁸ 至 3.4×10³⁸，精度约 6–7 位有效十进制数字）。FP16 的舍入误差在数值不稳定的算法中可能累积，导致结果偏差。FP16 无法直接表示许多常用数值（如 100000），需要先 scale 到表示范围内再运算。因此 Rapid Packed Math 的适用域限于对精度不敏感的计算：图形中的法线、颜色值（尤其在 HDR 管线中需要注意 range 限制）、部分机器学习推理场景。关键路径（如物理模拟中的位置计算、大规模累加）仍需要 FP32 保证数值稳定性。

Rapid Packed Math 的激活条件是软件层面的：编译器需要生成 FP16 类型的 VALU 指令，着色器源码需要显式使用 half 精度类型。自动类型转换不会触发 Rapid Packed Math，这要求开发者对数据精度和数值范围有明确判断。

新增整数指令

Vega ISA 增加了一批整数操作指令，包括用于内存地址计算和哈希算法的专用指令（如位操作和整数乘法的优化形式）。这些指令的目标场景是加密运算、区块链挖矿等整数密集型计算。编译器可以利用这些指令减少临时寄存器占用，在特定场景下提高 resident wavefront 数量。

8 位 SAD 运算

Vega 扩展支持 8-bit 整数 SAD（Sum of Absolute Differences）指令，用于加速图像块比较运算。QSAD 指令每周期每个 NCU 可并行完成 16 个 4×4 像素块的 SAD 计算。这类指令在视频编码运动估计、计算机视觉立体匹配等场景中有明确用途。

图形 API 支持

Vega 支持 DirectX 12.1 和 Vulkan 1.0 Shader Model 6.x。固定功能管线和 API 层面提供了保守光栅化（Conservative Rasterization）和栅格顺序视图（Raster Ordered Views, ROV）的支持。ROV 要求像素着色器的内存写入按特定顺序提交，固定功能管线配合缓存一致性协议保证不同像素线程的写入顺序。

2.2.2 Scheduling

Vega 的调度架构在 GCN 基础上保持，Hardware Scheduler 继续管理最多 40 个 wavefront/CU（每 SIMD 10 个），采用相同的轮询调度策略。

Hardware Scheduler 与指令发射

每个 NCU 的 Hardware Scheduler 周期性检查驻留 wavefront，从就绪的 wavefront 中选择指令发射到 4 个向量 SIMD 单元和 1 个标量单元。由于每个 SIMD 执行 Wave64 指令需要 4 个时钟周期（16 lane × 4 拍完成 64 线程），Hardware Scheduler 在 4 个 SIMD 之间轮转发射，每个 SIMD 约每 4 个周期接收一条新 wave 指令。CU 级稳态每周期可覆盖 64 lane 的 FP32 FMA 吞吐。

Vega 保持了每个 SIMD 10 个 wavefront 的设计，使 Hardware Scheduler 在某些 wavefront 因内存延迟阻塞时，仍有其他就绪 wavefront 可切换执行。上下文切换零开销的前提是 wavefront 的寄存器状态始终驻留在 VGPR/SGPR 中，切换时只需改变 Hardware Scheduler 的指针，无需保存/恢复寄存器数据。

Occupancy Control 的定量分析

Hardware Scheduler 通过控制驻留 wavefront 数量来平衡资源利用率与延迟隐藏能力。occupancy 的具体约束与 GCN 1.x-2.x 相同：VGPR 用量、SGPR 用量、LDS 用量和 wavefront slot（每 SIMD 10 个）共同决定 resident wavefront 上限。

Vega 通过 ISA 层面的优化（如新的整数指令形式减少临时寄存器使用）和 Rapid Packed Math（机制见 2.2.1 节），在特定场景下可以降低单个 wavefront 的资源占用，从而提高 occupancy。Rapid Packed Math 的寄存器减半收益是有条件的：仅当编译器/ABI 真正使用 packed half 格式时才成立；若 half 被扩展为 32-bit 或单独占用完整 VGPR slot，则不成立。在满足 packed half 条件的前提下，如果 kernel 可以将 50% 的 VGPR 数据从 FP32 转为 FP16，则物理寄存器需求减半，resident wavefront 可能翻倍。

异构任务调度

Vega 的外部调度系统延续 GCN 的多级队列架构：Graphics Command Processor（GCP）负责图形任务，Asynchronous Compute Engine（ACE）负责计算任务。高端 Vega 10 配备多个 ACE 单元，可同时处理多个独立计算队列。

Vega 前端加入了改进的 Workgroup Distributor，在各 Shader Engine（SE）之间分配工作，减少 SE 间的负载不均衡。当同时存在图形和计算任务时，调度器按既定策略将 wavefront 混合派发到各 CU。硬件多队列支持减少了 CPU 干预需求。

硬件虚拟化与 SR-IOV

Vega 10 较早支持了 SR-IOV（Single Root I/O Virtualization）GPU 硬件虚拟化。官方资料提及的"最多 16 个会话"主要对应视频编码会话，不等同于所有 Vega 产品都支持 16 个虚拟功能（VF）；实际 VF 数量取决于产品定位和驱动实现。SR-IOV 需要硬件具备 VM 上下文快速切换、CU 时间片分配和内存地址空间隔离机制。MMU 支持多虚拟地址映射，硬件划分计算和内存资源给每个 VF。SR-IOV 的定位是专业虚拟化场景（如 VDI、云计算），对消费级游戏没有直接影响。

Wave64 的三个结构性瓶颈

Vega 保持 Wave64 执行模型，在游戏渲染的典型负载下带来三个结构性效率问题：

Wave64 的分歧代价是 Wave32 的两倍，机制与量化同 2.1.1 节。

Wave64 的每个 wavefront 占用 64 个 lane 的 VGPR，分配粒度较粗。当 VGPR 用量较高时（如 > 48 VGPR/wave），occupancy 骤降至每 SIMD 3–5 个 wavefront，Hardware Scheduler 的选择空间急剧收缩。

处理极小三角形或稀疏像素覆盖时，每个 wavefront 的有效活跃 lane 数量远小于 64，但仍占用完整 wavefront slot 和寄存器资源。例如一个 8×8 像素 tile 中仅 4 个像素被覆盖，Wave64 wavefront 仍有 60 个 lane 被屏蔽，资源利用率低下。

这三个问题共同作用，是 Vega 在游戏场景下 CU 利用率低于理论峰值的原因，也是 RDNA 转向 Wave32 默认执行的直接动因。

2.2.3 ExecutionUnit

Vega 引入 NCU（Next-Generation Compute Unit），核心结构保持 GCN 范式（4 个 SIMD16 + 1 个标量 ALU），改进集中在频率容忍度、混合精度执行和物理设计。

NCU 内部改进与高频设计

Vega 的设计目标之一是提升核心频率。工程手段包括：重新布局 CU 物理版图以缩短关键信号线长度，确保更高频率下信号在单周期内传输到位；对指令提取、解码单元进行电路级重设计以适应更紧的时序约束。ALU 管线深度维持在 4 级（与 GCN 相同），未以加深流水线为代价换取频率，保持了单周期执行密度。

混合精度执行单元

NCU 的 32-bit ALU 通路支持动态精度切换：FP32 模式下每周期执行 1 个 FMA 操作（2 FLOP）；FP16 模式下拆分为 2 个并行的 FP16 FMA 操作（4 FLOP）；INT8 模式下拆分为 4 个并行的 INT8 操作（8 FLOP）。NCU 的 IEEE 754 兼容 FMA 单元在 FP16 模式下保持结果正确性。

混合精度吞吐的倍数关系（FP16 = 2× FP32，INT8 = 4× FP32）仅在软件显式使用对应精度类型时实现（见 2.2.1 节 Rapid Packed Math）。NCU 的 FP16 峰值（256 FLOP/周期，即 128 FMA/周期）在同期消费级 GPU 中处于竞争位置，但实际利用率取决于算法对精度的容忍度和开发者的显式优化。

标量单元

NCU 的标量 ALU 继续执行 SALU 指令，受益于更高的时钟频率和改进的标量缓存（每 4 个 CU 共享 16KB L1 标量缓存）。标量路径的低延迟对控制流密集型 shader 有明确收益：分支条件计算更快，减少 wavefront 在 wait-branch 状态下的等待时间。

2.2.4 RegisterFile

Vega 延续 GCN 的寄存器文件组织（VGPR + SGPR + LDS），通过工艺改进优化电气特性。

向量寄存器文件

每个 NCU 的 VGPR 文件容量与 GCN 前代相近（每个 SIMD 约 64KB），编程模型上每个线程最多可用 256 个 32-bit VGPR，物理约束的阶梯计算同 2.1.4 节。

Vega 采用 AMD Zen CPU 团队开发的定制 SRAM 宏单元构建寄存器阵列，读延迟降低约 8%、面积缩小约 18%、功耗降低约 43%。这些改进为 NCU 冲击更高频率提供了电气层面的支撑，但不改变 VGPR 的编程模型和 occupancy 约束逻辑。

标量寄存器与常量缓存

每个 NCU 配备 8KB 标量寄存器文件（SGPR），用于存储标量 ALU 所需的标量值（loop 计数、分支标志、跨 lane 不变参数）。每 4 个 CU 共享 16KB L1 标量数据缓存，加速常量内存访问。标量缓存和寄存器的组合降低 uniform 数据的访问延迟，减少对向量 L1 的争用。

寄存器分配与占用优化

Vega ISA 新增的某些指令（如整数 ADD/SUB 的复合形式）旨在减少临时寄存器使用。例如，原本需要两条指令和一个临时寄存器的运算，现在通过单条指令完成，避免额外寄存器读写。寄存器占用的降低直接影响 resident wavefront 数量。

FP16 Rapid Packed Math 对寄存器占用的影响（见 2.2.1 节）：两个 FP16 值打包在一个 32-bit VGPR 中，满足条件时大量使用 FP16 的 wavefront 其物理 VGPR 需求可能减半。在 VGPR 为 occupancy 瓶颈的场景下，这可以将 resident wavefront 翻倍。

LDS

每个 NCU 集成 64KB LDS，32-bank 结构，总带宽 128 byte/周期。LDS 容量与 GCN 前代相同，银行冲突约束也保持一致。LDS 是片上 scratchpad，不会自动溢出到全局内存；超出容量时编译报错，开发者必须显式管理 LDS 使用量。

2.2.5 MemorySubsystem

Vega 的内存子系统经历了 GCN 世代最大幅度的演进，包括 HBM2 显存、HBCC、L2 扩容和 RB 成为 L2 client。

HBM2 显存

Vega 10 配备 2 堆 HBM2（每堆 1024-bit 总线），总位宽 2048-bit，典型带宽约 483 GB/s。Vega 20 扩展至 4096-bit，带宽约 1 TB/s。HBM2 的带宽优势伴随容量限制：Vega 10 典型配置仅 8GB HBM2，对 4K 游戏和专业工作负载（如大型数据集计算）构成容量约束。

High-Bandwidth Cache Controller (HBCC)

HBCC 支持 49-bit 虚拟地址空间，允许 GPU 将系统内存和非易失性存储映射为统一地址空间。其工作机制是：当 GPU 访问超出显存容量的数据时，HBCC 以 page 粒度（通常为 64KB）将所需数据从系统内存调页到 HBM2 显存，同时将近期不用的数据页驱逐回系统内存。

HBCC 主要面向专业图形和计算应用（如大规模数据集可视化、科学计算），这些场景的 working set 超出显存容量但访问模式具有局部性。在游戏场景中，HBCC 的收益有限：游戏引擎通常通过显式资源流送（texture streaming）管理超出显存的数据，且 PCIe 带宽（约 16 GB/s）远低于 HBM2 带宽（483 GB/s），page fault 导致的系统内存访问会引入数量级延迟增长。HBCC 的"接近本地显存性能"仅在 page hit rate 极高时成立，而游戏工作负载的随机访问模式难以保证这一点。

Render Backend 成为 L2 Client

Vega 将 Render Backend (RB) 纳入 L2 缓存的客户端范围，使渲染输出单元与着色器单元共享同一 L2 一致性域。着色器写入的颜色数据可在 L2 中被后续着色器直接读取，无需先写回显存再读回。这对延迟着色（Deferred Shading）等需要跨管线阶段共享数据的渲染技术有直接收益。

Vega 10 的 L2 总容量达到 4MB（分散在 4 个 Shader Engine），相比 Polaris（2MB）翻倍。L2 扩容配合 RB 成为 L2 client，构成了 Vega 内存子系统的一致性升级。

片上互连

Vega 采用 Infinity Fabric 作为片内互连，连接内存控制器、L2 缓存分片、计算集群等。Infinity Fabric 提供了模块间标准化通信接口，但 GPU 自身与 CPU 的缓存一致性并未完全打通（APU 除外）。

2.2.6 FunctionFeature

Draw Stream Binning Rasterizer (DSBR)

DSBR 是 Vega 图形前端的重要改进。DSBR 不是 tile-based deferred rendering（TBDR），而是叠加在即时模式渲染（Immediate Mode Rendering, IMR）之上的 binning 优化。

TBDR（如 PowerVR 系列）的核心特征是将整个渲染管线按 tile 拆分，每个 tile 完整执行几何处理、光栅化、像素着色和 ROP 操作，像素着色在 tile 内完成，颜色数据不写出到显存。DSBR 的工作方式不同：它仍然是 IMR 的变体，在光栅化阶段引入 binning：将屏幕划分为 tile，收集图元并确定每个图元覆盖哪些 tile，然后按 tile 顺序进行像素着色。关键区别是 DSBR 的几何处理（顶点着色、曲面细分、几何着色）仍然在全分辨率上完成，不局限于 tile；只有像素着色阶段按 tile 组织。这与 TBDR 的完整 tile-based 管线有本质差异。

DSBR 的收益场景：overdraw 较高的场景（如大量半透明粒子、复杂重叠几何），通过 tile-level early-Z 和片上 bin cache 减少重复像素着色。收益具有条件依赖性：当场景 overdraw 低时，DSBR 的 binning 开销可能超过收益。AMD 在典型游戏场景的测试数据约为帧率提升最高 10%、显存带宽占用减少约 1/3，但这两个数字受场景特征和驱动启发式策略影响较大，不应作为普遍预期。DSBR 是可选组件，驱动根据场景特征判断是否开启。

Primitive Shader / NGG Fast Path

Primitive Shader（也称 NGG Fast Path）是 Vega 引入的新型可编程着色阶段，目标是合并替代传统管线的顶点着色（VS）、外壳着色（HS）、域着色（DS）和几何着色（GS）的固定功能流程。

Primitive Shader 的硬件机制：开发者使用单一着色器程序处理从顶点输入到图元输出的完整流程，包括自定义的图元剔除（视锥体裁剪、背面剔除、LOD 筛选）直接在 shader 中实现，仅输出存活图元到光栅化。AMD 声称的理论峰值是每时钟 17+ 个三角形（相比 GCN 前代的每时钟 4 个）。

Primitive Shader 在 Vega 上的实际状态：引入但未成熟。原因包括：

1. Primitive Shader 的编译器支持、调试工具和性能优化在 Vega 发布时不够完善，开发者难以稳定使用。
2. DirectX 12 和 Vulkan 在 Vega 发布时未标准化 Primitive Shader 的编程接口，开发者需要依赖 AMD 专有扩展。
3. Primitive Shader 的收益取决于场景的图元密度和剔除率，在低几何复杂度场景下 overhead 可能超过收益。
4. Primitive Shader 与传统 VS/GS/DS 管线的切换逻辑复杂，驱动难以在所有场景下自动选择最优路径。

Primitive Shader 的概念在 RDNA 世代通过 NGG（Next-Generation Geometry）管线重新实现并成熟，是 Vega 作为技术验证平台的价值所在。

DirectX 12.1 支持

Vega 是 AMD 首款完整支持 DX12 Feature Level 12_1 的架构。硬件功能包括 Conservative Rasterization Tier 1（光栅器在亚像素级别标记三角形覆盖，用于碰撞检测和体素化）和 Raster Ordered Views（ROV，像素着色器的有序内存写入，用于 Order-Independent Transparency）。ROV 的实现需要缓存和内存子系统保证不同像素线程按序写入同一地址，避免数据竞争。

Rapid Packed Math 的适用域

Rapid Packed Math 的适用场景与精度代价已在 2.2.1 节详述。总结而言，其定位是混合精度加速，适用于法线计算、颜色混合、部分机器学习推理等对精度不敏感的计算；不适用于大规模数值累加、需要精确比较的算法、超出 FP16 表示范围的中间计算。

2.2.7 小结

Vega 是 GCN 体系的集大成者，在 CU 核心结构不变的前提下，通过以下改进扩展了架构能力：

• 执行单元：NCU 的频率提升和混合精度 ALU 使峰值算力增加，但 Wave64 的结构性瓶颈（分歧代价、寄存器粒度、小工作量效率）未解决。
• 内存子系统：HBM2 提供高带宽，HBCC 扩展虚拟地址空间，L2 扩容配合 RB 成为 L2 client 提升一致性。HBCC 主要面向专业应用，游戏收益有限。
• 图形前端：DSBR 作为 IMR 上的 binning 优化减少 overdraw 场景带宽消耗，Primitive Shader 引入可编程图元处理概念但驱动未成熟。
• ISA 扩展：Rapid Packed Math 提供 FP16/INT8 加速，精度代价限制了适用域。

Vega 暴露的核心问题是 GCN 架构的根本限制：Wave64 在游戏轻载场景下效率不足，CU 利用率难以达到理论峰值。功耗偏高（部分源于 HBM2 和 HBCC 的额外功耗、部分源于为维持利用率而需要的高 occupancy 策略）使 Vega 在游戏性能/瓦特比上未达预期。这直接促成了 RDNA 的架构重构：缩小 wavefront 宽度、重构 CU 组织、降低低占用率下的 forward-progress 延迟。

Vega 的技术验证价值在于：DSBR 的 binning 思路、HBCC 的大地址空间管理、混合精度 ALU 的设计方向在后续架构中被继承或改进；Primitive Shader 的概念在 RDNA 的 NGG 中成熟；HBM 显存的经验为后续产品提供了参考。Vega 是 GCN 路线的终点，也是 RDNA 路线的起点。

三、RDNA

CDNA 路线沿计算专业化方向纵深推进：Matrix Core 精度覆盖逐代扩张、HBM 带宽层层堆叠、Wave64 作为吞吐最大化的执行宽度被刻意保留。RDNA 走的是另一条线：缩小 wave 宽度至 Wave32 以降低分歧代价和寄存器 footprint，围绕图形管线效率做逐环节优化，在消费级功耗预算下追求频率提升而非峰值算力堆叠。本章覆盖 RDNA 1 至 RDNA 4 四代架构的代际演进，以及 PlayStation 5 / Xbox Series X 定制 GPU 的差异化设计。

3.1 RDNA 1

经历了 GCN 架构长达数代的沿用后，AMD 在 2019 年推出了全新的 RDNA 微架构。这一架构直接回应了 Vega（GCN 5）时代暴露的三个结构性瓶颈。

瓶颈一：Wave64 分歧代价。Vega 的 wavefront 固定为 64 lane，当分支条件导致 lane 分化时，两个分支路径串行执行，被屏蔽 lane 的执行周期直接浪费。在分支密集的游戏着色器中，这一问题尤为突出。

瓶颈二：VGPR 分配粒度。Wave64 模式下每个 wavefront 的 VGPR 条目宽度为 64×32-bit，物理寄存器占用量大。当着色器线程需要较多 VGPR 时，每 CU 可驻留的 wavefront 数量骤减，occupancy 下降直接削弱延迟隐藏能力。

瓶颈三：图形小工作量低效。处理极小三角形或稀疏像素覆盖场景时，一个 Wave64 中仅有少数 lane 承载有效工作，却仍占用完整的 wavefront slot 和寄存器资源，实际 ALU 利用率远低于理论值。

RDNA 1 的设计正是针对上述三个瓶颈：以 Wave32 缩小分歧粒度、减半单 wave 寄存器 footprint、降低点亮全部 ALU 所需的最小线程数。从执行模型角度，GCN 依赖"堆叠大量 wavefront 以 TLP 隐藏延迟"，RDNA 1 则通过降低单 wave 的 forward-progress latency、提升多管线并行度，低 occupancy 场景下硬件利用率不再急剧衰减。

3.1.1 ISA

RDNA 1 延续了 GCN 的标量+向量双指令集范式，指令类型仍涵盖 SALU、SMEM、VALU、VMEM、分支、Export、消息七大类，编码格式与 GCN 基本一致。ISA 层面的核心变化是引入 Wave32 执行粒度并保留 Wave64 兼容模式，以及面向 NGG 和 Rapid Packed Math 的少量扩展。

Wave32 与 Wave64 双模式

RDNA 1 的硬件原生支持 Wave32（32 lane wavefront）作为默认执行粒度。相较于 GCN 的 Wave64，Wave32 的改变可分解为以下几个维度：

• 执行粒度：单条向量指令在 SIMD32 上一个周期即可完成（GCN 的 SIMD16 需 4 拍完成一条 Wave64 指令），forward-progress latency 从 4 拍降至 1 拍。
• VGPR 占用：Wave32 模式下每个 VGPR 条目宽度为 32×32-bit，仅为 Wave64 的一半。在相同物理寄存器容量下，单 wave 的寄存器 footprint 减半，occupancy 上限提高。
• Divergence 粒度：分支分歧时，Wave32 最多浪费 32 个 lane 的执行周期，最坏情况下的分歧代价为 Wave64 的一半。
• Memory coalescing：这是 Wave32 的代价面。Global memory 的 coalescing 依赖同一 wavefront 内多个 lane 的地址连续性来合并为更少的 memory transaction。Wave32 仅有 32 个 lane 参与 coalescing，相比 Wave64 的 64 个 lane，在访问连续地址时可能生成更多的 memory transaction（在地址高度连续时差距不大，在部分连续/步进访问时差距明显）。

为了兼容既有代码，RDNA 1 保留 Wave64 模式。其硬件实现采用 sub-vector 执行：一条 Wave64 指令在 ISA 层面表现为对两个 32-lane sub-vector（低半波 lane 0-31、高半波 lane 32-63）的相继操作，默认在同一 SIMD32 上 back-to-back 发射，也存在跨 SIMD32 的 sub-vector mode。Wave64 counts double：从资源占用角度，Wave64 消耗两倍于 Wave32 的 VGPR 条目（高低半波各需独立的物理寄存器分配），其并发 wavefront 上限相应减半；具体的 sub-vector 执行模式（同一 SIMD32 内连续发射还是跨 SIMD32 推进）取决于编译器选择的 wave mode 与调度器状态。

编译器根据 workload 特征在 Wave32 和 Wave64 之间做 heuristics 选择：pixel shader 因 quad 对齐（2×2 pixel quad 构成 derivative 计算的最小单位）和屏幕空间像素分布的不规则性，Wave32 适应性更好；compute shader 在数据并行度高、分支少的场景可选 Wave64 以最大化单 wave 线程数。

从 quad 对齐的约束分析：GPU 的像素着色以 2×2 pixel quad 为最小执行单位（用于计算纹理 derivative，即 mip level 选择所需的偏导数）。一个 Wave32 包含 8 个 quad（32÷4=8），一个 Wave64 包含 16 个 quad。当三角形覆盖的像素数量不足 32 个（或 64 个）时，wavefront 中会有部分 quad 的所有 lane 被屏蔽，这些 quad 仍占用 wave slot 和寄存器资源但不产生有效计算。Wave32 因 quad 数量更少，在小三角形密集的场景（如植被、远景几何）中无效 quad 的比例更低。

Wave32 并非 universally better，它的收益集中在分歧多、寄存器压力大、线程并行度有限的场景；在规则数据并行 workload 中，Wave64 的 64 lane coalescing 能力反而构成优势。编译器通常采用混合策略：pixel shader 默认 Wave32，compute shader 根据 barrier 使用模式、寄存器压力和分支密度综合判断。

特殊指令扩展

RDNA 1 的 ISA 扩展围绕三个方向：NGG 图形管线（新增 s_sendmsg 几何输出消息指令和线程组通信原语）、Rapid Packed Math（FP16/INT16 双倍并行度执行，延续自 Vega）、以及低精度 AI 推理支持（DOT4 类指令，支持 INT8×INT8 打包累加）。这些扩展保持了与 GCN 的软件兼容，编译器可通过 heuristics 决定是否生成 Wave32 或 Wave64 代码路径。

与 NVIDIA Volta/Turing 的对比视角

AMD 的 Wave32 与 NVIDIA 的 Warp32（自 Volta 起固定为 32 lane）在执行宽度上趋于一致，但两者在调度机制上有根本差异：NVIDIA SM 采用 scoreboard-based 依赖跟踪，硬件自动管理指令间的数据依赖和延迟；AMD RDNA 1 延续 GCN 的显式 waitcnt 模型，编译器通过 s_waitcnt 指令显式指定对 VMEM/SMEM/DS 操作的等待计数，硬件按计数器归零条件推进 wavefront。前者对编译器要求较低但硬件调度逻辑更复杂，后者将延迟隐藏的部分责任交给编译器，但硬件调度器设计更精简。

3.1.2 Scheduling

RDNA 1 的调度系统分两层：前端 CP/ACE 负责任务级分发，CU/WGP 内部的 Hardware Scheduler 负责指令级发射。

前端调度：CP → ACE(4) → Graphics CP → Wave Dispatch

RDNA 1 的全局调度继承了 GCN 的多队列异步计算框架并做扩展。Navi 10 配置 4 个 ACE（Asynchronous Compute Engine），可同时处理 4 条独立计算队列加 1 条图形队列。ACE 与 Graphics CP（Command Processor）协同，在 CU/WGP 层面以硬件分时/抢占机制调度图形与计算任务，避免单一方过度占用资源。

统一执行模型（RDNA 1 完整数据路径）

RDNA 1 的 wave 生命周期完整路径：

Command Processor（Graphics CP + 4×ACE）→ Wave32/Wave64 Dispatch → WGP（Dual CU）→ 双 Hardware Scheduler → waitcnt（显式依赖计数）→ SGPR/VGPR/L0/L1/L2 → SALU×2/VALU×2（SIMD32×2）/VMEM/DS/TEX → Writeback → Dependency Clear

这一路径的关键特征是：(1) WGP 取代 CU 成为资源分配的基本边界；(2) 每个 CU 内部存在两条独立的调度通道，各自管理一个 wavefront pool；(3) 编译器通过 waitcnt 显式控制对内存操作的等待，硬件依赖计数器归零后才允许对应 wavefront 的下一条指令进入发射阶段。

CU 内部双调度器

RDNA 1 每个 CU 内部配置两个平行的 Hardware Scheduler，将 wavefront pool 均分为两份，各自由独立调度器管理。每个调度器连接到一个 SALU 和一个 SIMD32 向量单元。这种设计的直接结果是：一个 CU 可在同一周期并行发射两条标量指令（分别来自两个调度器管辖的 wavefront 组）和两条向量指令（分别在两个 SIMD32 上执行），实现了 SALU 和 VALU 的双发射并行。

GCN 时代每 CU 只有一个中央调度器，所有 wavefront 共享 1 个 SALU 和 4 个 SIMD16，标量指令成为瓶颈时向量管线被迫空等。RDNA 1 的分组设计将标量计算资源翻倍，每组 wavefront 拥有独立的 SALU，标量瓶颈的概率降低。

多管线并行发射

RDNA 1 的 Hardware Scheduler 支持 multi-pipeline concurrency：每个周期可从管理的 wavefront 集合中挑选多条无依赖的指令，并行发送到不同功能单元。具体而言，一个 WGP（Dual CU）内部存在以下可并行工作的管线：

• 4×SIMD32（向量 ALU，每 CU 2 个）
• 4×SALU（标量 ALU，每 CU 2 个）
• 2×Load/Store 单元（全局内存访问，每 CU 1 个）
• 2×DS 单元（LDS 访问，每 CU 1 个）
• 2×分支/导出单元（每 CU 1 个）

上述管线在 WGP 内并行工作，每周期可向各执行单元发射多条无依赖指令，具体发射数取决于调度器仲裁和各单元的就绪状态。这与 CPU 的乱序执行（OoO）有本质区别：RDNA 1 的每个 wavefront 内部仍严格 in-order，并行性来源于跨 wavefront 的多管线重叠，而非单线程内的指令重排。

Wave64 sub-vector 协调

当执行 Wave64 指令时，调度器依据编译器指定的 wave mode 将高低半波分派到 SIMD32 执行单元。默认路径下，同一 SIMD32 在相邻周期先后处理低半波与高半波；在 sub-vector mode 下，两个 SIMD32 可分别处理各半波。两个半波的结果在 writeback 阶段合并为完整的 Wave64 结果。高低半波的发射协调可能引入周期级调度间隙，是 Wave64 在 RDNA 1 上的固有代价。

Occupancy 与延迟隐藏

Wave32 模式对 occupancy 的优化体现在两个维度：单 wave VGPR footprint 减半使得相同物理寄存器容量下可驻留更多 wavefront；单周期执行完毕使得 wavefront 在 SIMD 上的占用时间缩短，调度器可更频繁地轮换。RDNA 1 每个 SIMD32 可驻留最多 20 个 Wave32，因此每 CU（2 个 SIMD32）最多支持 40 个 Wave32 并发，总线程数 1280（GCN 为 40 个 Wave64 = 2560 线程）。数字上的差异不直接意味着 RDNA 1 的延迟隐藏能力更弱，关键在于 RDNA 1 单 wave 的执行速度更快、wave 切换更频繁，可用"快切换"部分弥补"少线程"。

"WGP 只需 128 线程（4 个 Wave32）即可点亮所有 ALU"这一 AMD 披露数据，其背后的微架构原因是：每 CU 有 2 个 SIMD32，每周期每个 SIMD32 可发射 1 条向量指令，因此每 CU 每周期需要 2 个就绪 Wave32 即可驱动全部向量 ALU；加上双 SALU 和 Load/Store 单元，一个 WGP（2 个 CU）共 4 个 SIMD32，4 个 Wave32 恰好覆盖。但这仅指"ALU 不被饿死"的最低条件，要达到高 steady-state 利用率，仍需足够的并行度覆盖内存延迟；在典型的图形着色 workload 中，256 线程/每 WGP（8 个 Wave32）可达 90% 以上的 ALU 利用率。

这组数字出自 GPUOpen 公开的 RDNA Architecture 演示材料，原文的对照更完整：GCN 的 2 个 CU 需要 2×4×64 = 512 线程才能达到 100% ALU 利用率，RDNA 的 WGP 只需 4×32 = 128 线程；材料同时注明这一数字依赖高 ILP（图形负载通常自带三条独立流 RGB/XYZ），因此 256 线程/WGP 在实践中即可经常达到 90% 以上的利用率。同一材料还指出，GCN 与 RDNA 都需要额外线程隐藏内存延迟，但 RDNA 所需的线程总量下降，barrier 之后的利用率回升也更快。

3.1.3 ExecutionUnit

RDNA 1 的执行单元围绕 WGP = Dual CU 的组织形式重新构建。每个 CU 内部配置 2×SIMD32（取代 GCN 的 4×SIMD16）和 2×SALU，通过多管线并行发射维持低 occupancy 下的执行利用率。

WGP = Dual CU：资源池化边界重划

WGP（Work Group Processor）由两个 CU 组成，实质是资源池化边界的重新划定。在 GCN 中，一个 workgroup 必须局限在单个 CU 内执行，受限于该 CU 的 64KB LDS 和寄存器资源上限。在 RDNA 1 中，一个 workgroup 可跨 WGP 内的双 CU 执行，LDS 容量和调度/前端资源扩大一倍。但 VGPR 文件仍是 per-SIMD/per-CU 的物理资源，RDNA 1 并未实现跨 CU 的 VGPR 统一池化；WGP 的资源池化主要体现在 LDS、调度/前端与工作组分配边界上。

WGP 对外仍表现为 2 个逻辑 CU（软件兼容性），但硬件实现上两个 CU 共享 L0 scalar cache 并通过内部互连保证跨 CU 的 LDS 访问一致性。对 compute shader 大 workgroup 场景的收益是：过去需拆分为多个 workgroup、引入跨组 barrier 同步的任务，现在可在单个 WGP 内完成，减少了同步开销和调度复杂度。

SIMD32 × 2：forward-progress latency vs. steady-state throughput

RDNA 1 每个 CU 配置 2 个 SIMD32 向量单元，取代 GCN 每 CU 的 4 个 SIMD16。从微架构角度分析这一变化的影响：

• Forward-progress latency：GCN 的 SIMD16 执行一条 Wave64 指令需 4 拍（16 lane/拍 × 4 拍 = 64 lane），RDNA 1 的 SIMD32 执行一条 Wave32 指令仅需 1 拍。单 wave 完成时间从 4 拍缩短到 1 拍，这是低 occupancy 场景下效率提升的主要来源。
• Steady-state throughput：在理想调度、occupancy 充足的前提下，GCN 每 CU 每周期可完成 4×16 = 64 个 FP32 FMA（4 个 SIMD16 各处理 16 lane），RDNA 1 每 CU 每周期可完成 2×32 = 64 个 FP32 FMA（2 个 SIMD32 各处理 32 lane）。两者峰值向量吞吐相同。RDNA 1 实测的每 CU 性能提升主要来自频率提升（更短的 SIMD 数据路径允许更高时钟）和更高的实际利用率（更少的空转周期），而非 SIMD 宽度本身的增加。

因此，"2×SIMD32 取代 4×SIMD16"的正确理解是：峰值吞吐不变，但单 wave 延迟降低、调度选择空间增大、硬件在workload不足时利用率更高。

SALU × 2 与标量指令双发射

RDNA 1 每个 CU 的 SALU 从 GCN 的 1 个增加到 2 个，每个 SALU 绑定到一个 Hardware Scheduler。两个 SALU 可独立工作，每个周期并行执行两条来自不同 wavefront 组的标量指令。对地址计算、循环计数、分支条件判断等标量操作密集的 workload，标量吞吐翻倍。GCN 中 1 个 SALU 服务 40 个 wavefront 时标量指令可能排队积压，RDNA 1 中每 20 个 wavefront 独享 1 个 SALU，标量瓶颈概率降低。

Compiler-Assisted Scheduling

RDNA 1 采用编译器辅助的调度策略：编译器在生成 ISA 时通过指令排序将独立指令尽可能相邻放置，Hardware Scheduler 据此识别可并行发射的指令对。编译器同时通过 s_waitcnt 指令显式标记对 VMEM（全局内存）、SMEM（标量内存）、DS（LDS）操作的等待计数，Hardware Scheduler 在这些计数器归零前不发射依赖后续结果的指令。这种软件-硬件协同调度模型的代价是编译器需要精确知晓各操作的延迟特征（缓存命中 vs. miss、LDS 访问周期等），优化不足会导致 waitcnt 等待过长（ALU 空转）或过短（数据冒险）；收益是 Hardware Scheduler 的逻辑可因此简化，功耗和面积低于同等规模的硬件 scoreboard 方案。

多管线并行发射能力

RDNA 1 每个 CU 理论上可同时执行：2 条向量指令（2×SIMD32）+ 2 条标量指令（2×SALU）+ 1-2 条内存访存指令（Load/Store 单元）+ LDS 访问指令（DS 单元）。这些指令可来自同一 wavefront 的不同独立指令，也可来自不同 wavefront。ILP 的挖掘对象是"跨 wavefront 的指令级并行"而非"单 wavefront 内的乱序"：每个 wavefront 内部仍严格 in-order，但硬件可在同一周期将多个 wavefront 的不相关指令分发到不同管线上并行推进。

多管线发射的约束条件：并非所有指令组合都能在每个周期并行发射。当两个 wavefront 同时请求同一资源（如两个 wavefront 都需要访问 LDS 且 bank 冲突，或两个 wavefront 同时发出 VMEM 请求且 Load/Store 单元已满），调度器需推迟其中一条指令到下一周期。Resource allocation 的仲裁逻辑在每个周期评估所有就绪指令的资源需求，选择无冲突的指令子集发射。

特殊功能单元

RDNA 1 的 SFU（Special Function Unit）支持超越函数（sin、cos、log、exp、rcp 等）与常规 VALU 指令的并行执行，SFU 拥有独立的执行管线，不阻塞 SIMD32 上的普通 FMA/ADD 运算。每个 WGP 的 TMU（Texture Mapping Unit）与 ALU 协同工作，RDNA 1 将纹理采样吞吐和缓存带宽相对 GCN 提升约一倍，以匹配 ALU 侧更高的产出速率。

与 NVIDIA SM 的对比视角

RDNA 1 的 WGP（2×CU，共 4×SIMD32）与 NVIDIA Turing 的 SM（4×processing block，共 32×FP32 CUDA Core + 2×Tensor Core + RT Core）在设计哲学上存在根本差异。WGP 的核心目标是"用更少的 wavefront 维持利用率"，通过降低单 wave 延迟、提升多管线并发，在低 occupancy 下维持高利用率。SM 则延续"堆叠更多 warp 隐藏延迟"的路线，通过更大的寄存器文件和更多的 warp slot（Turing SM 支持 32 个 warp）维持高并发。两者在图形 workload 上的效率差距在 RDNA 1 时代明显缩小，但在 compute workload 上，NVIDIA SM 更大的寄存器容量和更成熟的 scoreboard 调度仍有优势。

3.1.4 RegisterFile

RDNA 1 的寄存器文件沿袭 GCN 的 VGPR/SGPR 双轨划分，Wave32 模式的引入改变了物理寄存器分配粒度。

VGPR 占用量化分析

GCN 中每个 Wave64 的 VGPR 条目物理宽度为 64×32-bit = 256 byte。RDNA 1 的 Wave32 模式下，单个 VGPR 条目宽度为 32×32-bit = 128 byte，物理占用减半。驱动文档显示 RDNA 1 每个 wavefront 的 VGPR 上限仍为 256 个（与 GCN 一致），则：

• Wave32：单 wave VGPR 总占用 = 256 × 128 byte = 32 KB
• Wave64：单 wave VGPR 总占用 = 256 × 256 byte = 64 KB

在相同物理 VGPR 容量下，Wave32 可驻留的 wavefront 数量上限为 Wave64 的两倍。这一差异直接影响 occupancy：一个需要 128 VGPR 的着色器，在 GCN（Wave64）上每 wave 占用 32 KB，若 CU 的 VGPR 总容量为 256 KB，则最多驻留 8 个 wavefront；在 RDNA 1（Wave32）上每 wave 占用 16 KB，同一容量可驻留 16 个 wavefront，并发度翻倍。

Wave64 在 RDNA 1 上的 VGPR 占用等效于两个 Wave32（sub-vector 机制导致高/低半波各占用一份物理寄存器），因此选择 Wave64 模式时并发数上限相应减半。软件可在编译时通过 heuristics 权衡：高寄存器压力 workload 优选 Wave32，规则数据并行 workload 可选 Wave64。

每 CU wavefront 并发能力

RDNA 1 每 CU 配置 2 个 SIMD32，每个 SIMD32 可驻留最多 20 个 Wave32，因此每 CU 最大并发 wavefront 数为 40（Wave32），总线程数 1280。GCN 每 CU 为 40 个 Wave64，总线程数 2560。数字差异的物理含义是：RDNA 1 用"更少的总线程数"换取"单线程更快的执行速度"，两者的延迟隐藏能力取决于 workload 的内存延迟和计算密度比例，不能简单判定优劣。

LDS 池化：WGP 模式下的共享存储

RDNA 1 每 CU 配置 64KB LDS（与 Vega 相同），WGP 内双 CU 的 LDS 在硬件上可合并为一个 128KB 的池化资源。当驱动将 workgroup 调度到 WGP 上执行时，该 workgroup 可用的 LDS 上限从 64KB 提升到 128KB。对大量共享数据的 compute shader（如 Tiled 光照计算、大矩阵分块乘法），过去因 LDS 不足而拆分为多个 workgroup、引入跨组 barrier 和全局内存通信的算法，现在可在一个 WGP 内完成，减少了跨 workgroup 同步开销和全局内存流量。

LDS 池化的代价是跨 CU LDS 访问的延迟略低于同 CU 访问。WGP 内两个 CU 通过专用互连共享 LDS，同一 WGP 内跨 CU LDS 访问仍维持在较低延迟（具体延迟差值 AMD 未公开），但与同 CU LDS 访问相比存在微小差距。编译器和驱动在分配 workgroup 到 WGP 时需考虑这一因素，尽量将 LDS 密集型的线程组集中在单个 CU 内。

线程切换与 occupancy 优化

Wave32 模式对延迟隐藏的贡献不仅来自更多的并发 wavefront，还来自更快的 wave 切换：单周期执行完毕意味着 wavefront 在 SIMD 上的驻留时间缩短，调度器每周期都可选择新的就绪 wavefront 发射。当某 wavefront 因等待 VMEM 操作（数百周期延迟）而阻塞时，调度器有更多机会从其他就绪 wavefront 中挑选指令填充流水线缝隙。在 occupancy 受限的场景（如高 VGPR 用量导致只能驻留少量 wavefront），更快的单 wave 执行可部分弥补并发数不足的问题。

3.1.5 MemorySubsystem

RDNA 1 重塑了片上缓存层次，将 GCN 的 CU-L1-L2-DRAM 四级结构改为 CU-L0-L1(RO)-L2-DRAM 五级结构，并引入更细粒度的数据压缩和预取机制。

L0：每 CU 私有 16KB × 2（per WGP），load bandwidth 翻倍

GCN 架构中每个 CU 配备 16KB 向量数据缓存（常被直接称为 L1，但实际上与 CPU 的 L1 概念不同，更接近 today 的 L0 定位）。RDNA 1 将这一层级正式重新定位为 L0 缓存，仍由每个 CU 私有，容量维持 16KB，但 load bandwidth 相对 GCN L1 翻倍（每 CU 带宽从 64 byte/cycle 提升至 128 byte/cycle [AMD 公开数据]）。每个 WGP（双 CU）合计拥有 2×16KB = 32KB L0。

L0 服务全局 Load/Store（VMEM 路径），命中时提供远低于 L1/L2 的低延迟访问。L0 采用 write-through 策略，写操作同时更新 L0 和下一级缓存，简化了一致性管理但增加了写流量。L0 与 L1 之间的一致性边界在 WGP 级别：同一 WGP 内双 CU 的 L0 通过内部互连保持一致，不同 WGP 的 L0 不保证一致性，跨 WGP 的数据共享需通过 L2 完成。

从 GCN L1 到 RDNA L0 的演进在命名之外反映了功能边界的重新划定：GCN 的 CU L1 同时承担数据缓存和纹理数据缓冲的混合角色，RDNA 1 将纹理路径与数据缓存路径分离得更彻底。L0 专注于 VMEM 全局内存访问，纹理采样请求走独立的 texture cache hierarchy（texture L1 → texture L2），两条路径在 L2 层面才汇聚。这种分离减少了纹理访问和数据访问在同一缓存中的竞争，提高了两者的有效带宽。

L1：per-Shader Array 128KB，Read-Only

RDNA 1 在 GCN 中不存在的层级插入了一层 128KB L1 缓存，位于每个 Shader Array（一组 CU/WGP 的集合）内。这一 L1 的关键约束是 read-only：着色器写操作（UAV 写入、render target 写入）不经过 L1，直接写入 L2 或显存。L1 缓存只读的语义意味着它不参与写一致性协议，硬件实现可简化（无需 dirty bit 管理、无需写回逻辑），容量和速度可因此优化。

L1 的功能定位是"只读数据的二级汇聚点"：当多个 CU 访问相邻或相同的只读数据（常量缓冲、纹理、 uniform 数据）时，L0 miss 的请求先在 L1 中查找，命中即可避免上升至 L2，从而减轻 L2 带宽压力。对以读取为主的图形 workload（典型的顶点/像素着色器以读纹理和常量为主），L1 可有效截留大量读取流量。

L2：全局缓存与 RB 成为 L2 Client

RDNA 1 的 L2 作为全芯片共享的最后一级缓存，Navi 10 配置 4MB（与 Vega 10 相同量级）。L2 承担全局内存一致性职责：不同 CU 的 L0 写操作通过 L2 同步，确保后续读取可见最新数据。

RDNA 1 延续了 Vega 已引入的趋势，进一步将 RB（Render Backend）作为 L2 的 client 并扩展了 L2 client 的单元范围。在 Polaris 架构中，RB 的像素输出通常直接写入显存（或绕过 L2 的 write-through 路径）；Vega 中 CP/RB 已成为 L2 client，RDNA 1 在此基础上将 Copy Engine 等更多单元纳入 L2 client 范围。像素着色器写入的 render target 数据先进入 L2，后续阶段（如 post-processing shader）若读取同一数据，可直接在 L2 中命中，无需访问显存。对延迟着色（Deferred Shading）等多阶段读取同一帧缓冲的渲染技术，这一变化减少了帧缓冲数据在显存和片上来回搬运的带宽消耗。量化收益取决于 workload：在 G-Buffer 写入后紧跟着 lighting pass 读取的场景中，RB→L2→lighting shader 的数据流避免了 G-Buffer 的显存往返，节省的带宽与 G-Buffer 的分量数量和分辨率成正比（4K 分辨率下 G-Buffer 可能达到数十 MB/帧）。

DCC 增强：端到端压缩数据流

RDNA 1 改进了 DCC（Delta Color Compression）算法，覆盖更多颜色格式和渲染场景。核心变化是 RB、TMU、缓存与显示通路可在内部以压缩格式搬运颜色数据，shader 看到的是经硬件隐式解压后的语义值，显示引擎也可直接消费压缩帧缓冲而无需 CPU 侧解压。

GCN 的 DCC 局限在 RB 写出时压缩，后续着色器读取时需由硬件隐式解压。RDNA 1 扩展了压缩数据在片上管线中的流通范围：若一个压缩的 render target 被后续 shader 采样，TMU/cache 路径可在压缩状态下搬运，仅在送入 ALU 前由硬件解压。端到端压缩数据流减少了两个方向的带宽：压缩数据体积更小（DCC 压缩率通常在 2:1 到 8:1 之间，取决于画面内容），且省去了中间格式转换的功耗和延迟。

HBCC 移除的原因与代价

RDNA 1 移除了 Vega 引入的 HBCC（High Bandwidth Cache Controller）。HBCC 支持 49-bit 虚拟地址空间（512TB 虚拟地址范围），允许 GPU 以 page 粒度将系统内存甚至 SSD 存储页入/页出到 HBM 显存，使显存容量在逻辑上扩展至系统内存规模。

移除 HBCC 的权衡：HBCC 的 page fault 处理、地址翻译、页迁移逻辑消耗了不少芯片面积和功耗，而游戏 workload 的典型工作集远小于显存容量（即使 RDNA 1 的 8GB GDDR6 也足以容纳绝大多数游戏场景），HBCC 的能力处于闲置状态。RDNA 1 将 HBCC 节省的面积和功耗预算重新投入到 L0/L1 缓存、更多 SALU、以及 GDDR6 内存控制器上，这些资源在游戏 workload 中的利用率远高于 HBCC。

代价是：RDNA 1 无法像 Vega 那样处理超出物理显存容量的超大数据集（如专业可视化中的超大纹理场景）。对于需要显存虚拟化的专业 workload，这一能力缺失构成了功能边界。AMD 的解决方案是将大显存需求导向 CDNA/MI 系列加速卡，RDNA 系列专注游戏场景。

预取机制

RDNA 1 的 Prefetch 单元检测 VMEM 访问的 stride pattern（如连续地址或固定步长），提前将后续 cache line 加载到 L0/L1。Wave32 模式下单个 wavefront 的工作集更小（32 线程的地址范围通常比 64 线程更集中），预取器在较小工作集上的预测准确率相对提高，部分内存延迟由预取命中覆盖，降低了对高 occupancy 的依赖。

3.1.6 FunctionFeature

RDNA 1 的功能特性围绕 NGG 几何管线重构和纹理/渲染输出增强展开，同时明确了 RDNA 系列与 CDNA 的计算分工边界。

NGG（Next-Generation Geometry）：传统几何管线的瓶颈与解决方案

RDNA 1 的 NGG 并非"更现代的几何管线"这一空洞描述可概括。要理解 NGG 的价值，需先分析传统 GCN 几何 front-end 的结构性瓶颈：

传统管线的前端包含多个固定功能和可编程阶段的串联：IA（Input Assembly，固定功能）→ VS（Vertex Shader，可编程）→ HS/TS/DS（Tessellation 阶段）→ GS（Geometry Shader，可编程）→ 固定功能 Primitive Assembly → 固定功能 Viewport Clip → 固定功能 Rasterizer。这一长链路的每个阶段都有独立的吞吐限制和缓冲需求，且阶段间的数据格式转换和缓冲拷贝消耗带宽和延迟。而剔除操作（背面剔除、视锥剔除）发生在管线较后端的固定功能阶段，大量无效图元在此前已历经完整的顶点着色和细分计算，这些计算被浪费。

Vega 世代 AMD 曾尝试通过 Primitive Shader 绕过部分固定功能阶段，但因驱动成熟度、API 支持不足和硬件限制未能实用化。RDNA 1 的 NGG 是对这一思路的重新实现，但启用范围仍受驱动和游戏适配条件约束，完整成熟要到后续 RDNA 版本。

Primitive Shader 的工作分布改变

NGG 将传统管线中 VS/GS/ES 等可编程阶段合并为 Primitive Shader，由通用 CU/WGP 执行（而非固定功能硬件）。输入顶点和图元以 workgroup 形式批量提交给 Primitive Shader，shader 代码可访问每个 primitive 的拓扑信息并决定是否丢弃或生成新 primitive。Primitive Shader 的输出直接进入光栅化阶段，绕过了传统管线的多个固定功能缓冲和格式转换步骤。

这一机制改变了几何 workload 的分布：传统管线中几何阶段的吞吐受限于固定功能硬件的峰值（Vega 每时钟最多处理 4 个三角形，受限于 Shader Engine 数量），NGG 模式下 Primitive Shader 运行在通用 CU 上，几何吞吐理论上可扩展到 CU 数量的上限（Navi 10 有 20 个 WGP = 40 个 CU），峰值几何吞吐不再受固定功能前端瓶颈约束。

Shader Culling：光栅化前剔除的收益与条件

NGG 模式支持在 Primitive Shader 中插入 Shader Culling 逻辑：利用顶点变换后的屏幕空间坐标，在图元进入光栅化之前判断其可见性（背面、视锥外、过小等），直接丢弃不可见图元。剔除发生在光栅化前，被剔除的图元不会进入后续像素管线，也不产生对应的顶点属性写入和纹理采样请求。

收益量化取决于场景的 overdraw 程度：在几何复杂度高、大量图元被遮挡的场景（如密集植被、复杂建筑），Shader Culling 可剔除 30%-70% 的输入图元 [AMD 公开数据，具体比例 workload 依赖]，节省的带宽包括被剔除图元的顶点属性写入（参数缓存带宽）和对应的纹理采样请求。在 overdraw 低的场景（如开阔地形、简单几何），收益有限。

Shader Culling 的条件约束：剔除逻辑本身消耗 CU 执行周期（Primitive Shader 中执行额外计算），若剔除率不够高，剔除计算的代价可能超过收益。驱动通常根据场景特征 heuristics 决定是否启用 NGG 和 Shader Culling。

RDNA 1 NGG 的范围限制

RDNA 1 的 NGG 实现存在以下限制：(1) 不支持所有拓扑类型和 rendering path，某些 legacy 模式（如特定 GS 输出拓扑、多流输出）需 fallback 到传统固定功能管线；(2) per-primitive 输出属性支持不完整，限制了部分 GS 功能（如逐 primitive 的多个输出属性）向 Primitive Shader 的直接映射；(3) 驱动层面的启用条件较保守，实际游戏中 NGG 的激活率受 AMD 驱动版本和游戏 profile 双重影响。这些限制的根因是 NGG 硬件在 RDNA 1 中尚属首次规模部署，AMD 采取了保守策略以确保兼容性，完整功能在 RDNA 2（NGG "完全体"，支持 Mesh Shader）中逐步解除。

Primitive Shader 的执行路径

Primitive Shader 的执行遵循以下数据路径：顶点数据从内存加载 → CU 执行顶点 fetch 和初步处理 → Primitive Shader kernel 以 workgroup 形式在 WGP 上执行（访问 LDS 共享顶点属性、执行 culling 逻辑）→ 存活图元输出到参数缓存 → 光栅器读取参数缓存进行光栅化。与传统管线相比，Primitive Shader 将顶点处理和图元处理合并为单一可编程阶段，消除了中间多个固定功能缓冲和格式转换步骤。这一合并减少了顶点属性数据在片上的多次搬运，但将更多的计算职责转移到通用 CU 上，CU 的 ALU 需承担原本由固定功能硬件完成的图元装配和剔除工作。

纹理单元增强

RDNA 1 的 TMU 在带宽和格式支持上做了针对性增强：L0 缓存带宽翻倍减少了 texture miss 后从上层取回的等待时间；64-bit/双组件纹理格式（如 FP16 纹理、RG 法线贴图）的过滤吞吐相对 GCN 提高一倍。HDR 贴图、体积纹理、高精度法线贴图等过去容易成为瓶颈的资源，在 RDNA 1 上的采样代价降低。

渲染输出与像素处理

RDNA 1 的 RB（Render Backend）通过 L2 路径写入颜色数据（见 MemorySubsystem 章节），配合 DCC 端到端压缩，减轻了高分辨率、高 overdraw 场景下的显存写压力。光栅化侧继承了 tile-based binning 光栅化思路（AMD 此前在 Vega 等架构中部署过类似机制），在 overdraw 高的场景通过片上 tile buffer 减少重复像素着色。其具体实现细节（如是否完整沿袭 DSBR）缺乏公开资料确认。Tile binning 的收益取决于场景特征：overdraw 高时减少无效像素计算，overdraw 低时引入 tile sorting 的额外开销。

图形 API 支持边界

RDNA 1 发布于 2019 年，硬件层面不支持光线追踪加速单元和 Mesh Shader。NGG 的 Primitive Shader 在概念上与 Mesh Shader 有相似性（可编程几何生成），但 RDNA 1 未通过标准 API 开放通用 Mesh Shader 接口。光线追踪需完全依赖软件模拟（通过 compute shader 遍历 BVH），效率远低于 RDNA 2 的硬件光追单元。这一取舍将晶体管预算集中于传统光栅性能优化，使 RDNA 1 在其目标市场（2019 年主流游戏）中获得了竞争力。

计算功能

Wave32 和多管线并行发射对 compute workload 同样有益：分支密集 kernel 的分歧损失降低，不规则数据并行任务中 Wave32 的调度自由度优于 Wave64。然而，RDNA 1 在纯计算场景中的效率提升不如图形场景明显：规则数据并行的 compute kernel（如矩阵乘法）中 Wave64 的更大 coalescing 宽度和更多单 wave 线程数仍有优势，且 RDNA 1 的 occupancy 上限（每 CU 1280 线程，Wave32 计）低于 GCN（每 CU 2560 线程，Wave64 计），在高延迟隐藏需求的 compute workload 中可能成为短板。

Rapid Packed Math（FP16/INT16 双倍吞吐）和 DOT4（INT8 打包累加）延续自 Vega，为低精度推理和图像处理提供基础支持。RDNA 1 的 FP16 峰值算力为 FP32 的两倍（每个 FP32 FMA 单元内部数据路径复用，可并行执行两个 FP16 FMA），DOT4 指令支持 INT8×INT8 累加，为简易神经网络推理提供比纯 FP32 高 4 倍的整数吞吐。但 RDNA 1 没有专用矩阵乘法单元（如 NVIDIA Tensor Core），矩阵运算需通过通用 VALU 逐元素实现，大规模矩阵乘法的效率受限。

FP64 速率仍为 FP32 的 1/16，面向消费级定位。AMD 将 FP64 高性能留给 MI 系列加速卡（后来发展为独立的 CDNA 架构），RDNA 系列专注游戏图形和轻量计算的性价比。这一架构分叉决策（RDNA for 图形，CDNA for 计算）使 RDNA 1 可将晶体管预算集中于游戏相关优化（Wave32、NGG、多级缓存），而非为 HPC 功能（HBCC、高 FP64 吞吐）付出面积和功耗代价。分叉的代价是 RDNA 1 失去了 GCN 时代的"通用计算平台"定位，在 AI 训练、科学模拟等专业市场中的竞争力下降；但 AMD 的判断是游戏 GPU 市场规模远大于专业计算市场，专注游戏效率的投资回报率更高。

3.1.7 小结

RDNA 1 是 AMD GPU 架构的一次结构性调整，其设计动机来自 Vega（GCN 5）时代三个可量化的效率瓶颈：Wave64 分支分歧代价过高、VGPR 粗粒度分配限制 occupancy、图形小工作量场景下 ALU 利用率不足。RDNA 1 的回应是系统性的：Wave32 降低分歧粒度和寄存器 footprint、2×SIMD32 取代 4×SIMD16 以降低单 wave 延迟、双 SALU + 双调度器提升多管线并发、WGP 资源池化扩展 workgroup 边界、L0/L1/L2 三级缓存重塑数据访问路径、NGG 将几何处理从固定功能前移至可编程 CU。

性能提升的构成与条件

AMD 披露 RDNA 1 在"同等工艺和频率"下每 CU 性能较 GCN 提升约 25%。这一数字的构成需拆解理解：其中约 12-15% 来自频率提升（更短的 SIMD32 数据路径允许更高时钟），约 10-12% 来自实际利用率改善（更少的 ALU 空转周期），SIMD 宽度变化本身对 steady-state 峰值吞吐贡献有限。"每 CU 性能提高可达 50%"的数字则包含了频率提升（RDNA 1 的 7nm 工艺优势）和架构效率的综合效果，不能简单归因于微架构革新。

这些提升具有明显的 workload 依赖性：在分支密集、寄存器压力大、 occupancy 低的游戏着色 workload 中，RDNA 1 的效率优势最大；在规则数据并行、高 occupancy 的 HPC workload 中，GCN 的 Wave64 和更大的单 wave 线程数反而可能更匹配。RDNA 1 的设计优化目标是游戏图形，非通用计算。

与 NVIDIA 架构的对比总结

RDNA 1 与 Turing 在执行宽度（Wave32/Warp32）上趋同，但在调度哲学上保持差异：AMD 延续编译器显式控制（waitcnt）+ 硬件精简调度的路线，NVIDIA 坚持硬件完整管理（scoreboard + OoO within warp）。两种路线各有代价：AMD 路线对编译器优化要求高但硬件功耗较低，NVIDIA 路线硬件复杂度更高但编程模型更友好。

RDNA 1 的代价与边界

Wave32 模式下每个 wavefront 的线程数减半，对天然适合大 wavefront 的 HPC workload（如规则矩阵运算），RDNA 1 的优势不如游戏场景明显。NGG 和 Primitive Shader 的完整收益受驱动成熟度约束，在 RDNA 1 世代未能完全兑现。HBCC 的移除使 RDNA 1 无法处理超显存容量数据集，功能边界明确限定在游戏和消费级图形。FP64 性能仅为 FP32 的 1/16，专业计算需转向 CDNA 系列。

RDNA 1 的历史定位是 AMD GPU 架构从"通用计算优先"（GCN）回归"游戏效率优先"的转折点。它确立了后续 RDNA 2（光线追踪 + Infinity Cache）、RDNA 3（Chiplet + 双发射）的微架构框架：WGP 组织形式、Wave32/Wave64 双模式、NGG 管线框架在后续代际中被延续和完善。

3.2 RDNA 2

RDNA 2 架构于 2020 年发布，工艺节点维持 7nm 不变，核心设计目标是在 RDNA 1 基础上进一步提升时钟频率与指令级并行效率，补齐两项 RDNA 1 缺失的关键能力：片上高带宽数据供给与硬件光线追踪加速。RDNA 1 通过 Wave32 执行模型和 WGP 组织方式解决了 GCN 在游戏图形负载中延迟敏感、效率偏低的问题，但其 256-bit GDDR6 接口（峰值带宽约 448-512 GB/s）在高分辨率场景下成为瓶颈；RDNA 2 通过引入 128MB Infinity Cache 缓解了这一外部显存带宽约束。RDNA 2 在每个 CU 中集成了 Ray Accelerator（RA）固定功能单元，以交点测试加速的方式实现了对 DirectX Raytracing（DXR）和 Vulkan RT 的硬件支持。RDNA 2 还完善了 NGG 几何管线以完整支持 Mesh Shader 执行模型，将光栅器像素产出率从 16 pixel/clk 提升至 32 pixel/clk，ROP 数量翻倍。这些改动使RDNA 2成为PlayStation 5和Xbox Series X/S的图形核心基础。

AMD官方数据显示，在选定workload和相同工艺条件下RDNA 2性能每瓦最高提升约54%（AMD 官方白皮书数据）。该数据的成立高度依赖Infinity Cache对显存流量的削减效果；在working set size超过128MB或缓存命中率较低的streaming workload中，这一比例会下降。RX 6000系列（Navi 21）在部分游戏场景中达到了与竞品Ampere架构相当的光栅化性能，但二者在不同workload下的表现存在明显差异，取决于显存访问模式、几何处理压力和光线追踪负载比例。

3.2.1 ISA

RDNA 2保持了RDNA 1的SIMT指令集框架（标量+矢量双指令流），完全兼容RDNA 1指令集，并针对新硬件功能扩展了三类关键指令：光线追踪交点测试指令、V_DOT低精度点积指令、以及支持DX12 Ultimate新特性的管线控制指令。

Wave32与Wave64双模式

RDNA 2继续以Wave32作为图形着色的默认执行宽度。每个CU内含两个SIMD32矢量单元，Wave64指令被拆分为两个Wave32 half顺序执行完成，无需保留专门的SIMD64硬件。两个half共用同一SIMD32物理单元分时调度，保留了与RDNA 1兼容的执行模型，同时简化了wave scheduling和寄存器分配逻辑。Wave64模式继续受支持，用于兼容GCN遗留代码和在特定计算着色器中利用更大的跨lane数据共享粒度。

硬件光线追踪指令：ISA接口与软件遍历的边界

RDNA 2新增了两条核心光追指令：IMAGE_BVH_INTERSECT_RAY（32位地址模式）和IMAGE_BVH64_INTERSECT_RAY（64位地址模式）。从ISA语义看，这两条指令属于纹理指令扩展族，因为 Ray Accelerator 物理集成在 Texture Memory Unit（TMU）内部，指令通过 TMU 的地址路径和端口发起请求。每条指令可在硬件中完成以下操作之一：

• 4个ray-box intersection test（针对BVH内部节点）
• 1个ray-triangle intersection test（针对BVH叶节点）

指令返回命中状态、命中距离、三角形索引等信息至VGPR，由着色器代码读取并决定后续操作。

ISA层面的能力边界：这些指令仅加速intersection test，不执行BVH traversal。完整的traversal逻辑（包括选择下一级子节点、处理miss回退、管理ray栈、调用不同hit/miss shader）仍由compute/vertex shader代码在VALU上执行。这种"固定功能intersection + 可编程traversal"的分工模式与NVIDIA Turing/Ampere RT Core存在本质差异：NVIDIA在RT Core内部实现了硬件traversal pipeline（包括BVH节点取指、栈管理、递归展开），而AMD将traversal保留在shader域，仅在TMU中添加了intersection test的固定功能加速。

这一设计选择的微架构后果是：

1. 每个RA的面积开销相对Tensor Core等独立光追单元更为轻量 （第三方估算），使AMD能在相同die size下部署更多CU。
2. traversal逻辑占用VALU、VGPR和LDS资源，执行光追workload时有效wave occupancy低于传统光栅化workload。BVH遍历中的divergent path（不同ray命中不同深度或不同材质的节点）导致warp内active lane减少，VALU利用率下降。
3. 每次intersection test请求需要通过TMU端口，结果返回受TMU响应延迟和VGPR writeback端口约束。与NVIDIA RT Core内部完成整个traversal、仅最终hit/miss返回shader的模式相比，AMD方案在每次intersection后都需要一次shader-roundtrip，增加了端到端traversal延迟。
4. 开发者使用标准DXR HLSL接口编写光追着色器，编译器和驱动在需要的位置插入IMAGE_BVH_INTERSECT_RAY指令。traversal策略（如自定义BVH布局、early exit、multi-level BVH）可在shader层实现，不受硬件traversal pipeline的固定语义限制。

Packed Dot指令（V_****DOT）：低精度运算的ISA扩展

RDNA 2新增了一组dot product指令，属于V_DOT类别，用于在常规SIMD32 VALU上执行 packed low-precision multiply-accumulate 操作。主要指令包括：

这些指令的功能定位是利用现有VALU数据通路执行低精度向量运算，减少实现等效计算所需的指令数量。与NVIDIA从Volta/Turing引入的DP4a（DP4A指令，4组INT8点积）在功能上对等。RDNA 2没有引入专用的矩阵乘法加速单元（Tensor Core或Matrix Core）；V_DOT指令依赖常规SIMD32流水线的ALU阵列执行，每个周期每个SIMD32可发出的dot指令数量受限于VALU端口数和指令发射带宽。

这种设计的路径分析如下：dot指令的operand从VGPR file读出 → 送入VALU multiplier array → 在ALU内部完成multiplication和accumulation → 结果写回VGPR。整个data path与常规FP32/INT32 VALU操作共享物理资源，不经过独立的矩阵运算阵列。直接后果：

• 每SIMD32每周期最多发射1条dot指令（受单条VALU issue与SIMD32 pipe限制），远低于专用Tensor Core的每周期4×4×4或更大矩阵处理能力。以V_DOT4_I32_I8为例，单指令完成4个INT8 MAC，一个K=256的GEMM inner loop需64条指令；Tensor Core可在单周期完成4×8×8或更大矩阵片段运算，同等K值下仅需8条matrix-multiply-accumulate指令。
• dot指令需同时读取多个packed operand（如V_DOT4_I32_I8需两个32-bit源寄存器，各含4个INT8元素），短期内增加VGPR read port竞争。K维度较大的GEMM中，running sum accumulator额外占用VGPR，减少了data loading和address calculation可用的register budget。
• V_DOT指令的accumulation目标为32-bit（FP32或INT32），不存在中间值宽度扩展问题；但缺少专用的multi-level accumulator register file（如Tensor Core的独立accumulator tile），所有partial sum必须占用通用VGPR。
• 对于小batch、低并行度的推理workload（如CNN point-wise卷积层或全连接层），V_DOT指令可有效提升throughput；对于大矩阵乘法（GEMM），缺少专用矩阵单元和register-level accumulator tile，需依赖wave-level或workgroup-level loop tiling累加partial sum，效率受限。

指令集演进总结

RDNA 2的ISA扩展沿两条轴线展开：图形方面，通过纹理指令扩展接入Ray Accelerator的intersection test能力，同时保持traversal逻辑的可编程性；计算方面，通过V_DOT packed dot指令在低精度向量运算上获得数倍于逐元素MAC的指令效率，但受限于VALU的物理吞吐，不具备专用矩阵运算单元的peak throughput。这两条扩展路径共同反映了RDNA 2的设计取舍：以最小的ISA和硬件改动获取功能性覆盖，将更激进的专用化推迟到后续架构。

3.2.2 Scheduling

RDNA 2的调度机制延续了RDNA 1的硬件wavefront调度框架，核心调整是降低了每个SIMD单元的并发wavefront上限，以换取更高的时钟频率和单wave资源分配效率。

Wavefront上限从20降至16的取舍

RDNA 2将每个SIMD32可同时追踪的wavefront数量从RDNA 1的20个减少到16个，对应每CU最大并发wavefront从40个降至32个，每WGP从80个降至64个。微架构动机体现为业界基于公开规格和微基准测试的推测分析 （第三方推测），非AMD官方披露：

1. 硬件scheduler每周期需要检查所有驻留wavefront的就绪状态（检查dependency、waitcnt、执行单元可用性）。将检查条目从20减至16，调度决策逻辑的gate count和critical path长度相应降低，允许scheduler在更高频率（>2.5 GHz）下稳定完成单周期决策。
2. 每个SIMD32配备128 KB VGPR file，在16 wave条件下每条wave平均可分配8192 byte（约64个256-vector寄存器），相比20 wave条件下的平均5120 byte（约40个寄存器）增加了约60%。更多VGPR减少了register spilling到LDS或显存的频率，降低了spill-induced memory traffic。
3. 更少的并发wave意味着更少的simultaneous memory request generator，LDS bank conflict概率和L1/L2 request port争用相应下降。

代价是：在memory-bound workload中（如大量随机显存访问、texture fetch密集场景），较少的并发wave可能降低latency hiding能力。RDNA 2通过三方面缓解这一问题：更高的时钟频率缩短了单指令执行时间；更大的Infinity Cache削减了显存访问频率；更深的ALU pipeline允许更大的instruction-level interleaving空间。实际测试表明，在典型游戏workload中，64 wave/WGP的并发度足以覆盖L2/Infinity Cache miss带来的延迟 （Chips and Cheese 微基准测试）。

Chips and Cheese 的 RDNA 2 架构分析给出了这组取舍的实测侧写：每个 SIMD 可追踪的 wavefront 上限确为 16 个（RDNA 1 为 20 个），一个 WGP 可在飞行中保持 64 个 wavefront，多于 Ampere SM 的 48 个 warp；其单 WGP 带宽测试同时显示，RDNA 2 在低并发下即可从各级缓存获得高带宽，Infinity Cache 在低 occupancy 时提供的带宽甚至超过 Ampere 的 L2。这一观察与"降并发换频率"的推测方向一致。

超标量Instruction Dispatch

RDNA 2的每个CU内，两个SIMD32各配备独立的wave scheduler，每周期可从驻留wavefront中并行发射多条指令到不同执行单元：

• 1条标量指令至SALU（地址计算、控制流、常量访问）
• 1条矢量指令至两个SIMD32单元之一（FP32/INT32/低精度dot运算）
• 1条内存指令至Load/Store单元（VMEM/SMEM/DS/LDS访问）

scheduler进行dispatch决策时检查以下约束：instruction的register dependency是否满足（包括VGPR/SGPR read-after-write hazard）、目标执行单元是否空闲、register file端口是否存在冲突、以及特殊指令（如光追指令）所需的TMU/RA单元是否可用。当标量指令与矢量指令来自不同wavefront且不存在资源冲突时，它们可在同一周期双发射。

调度与Execution Unit的衔接

scheduler通过wave state table维护每条wavefront的PC、execution mask、VGPR/SGPR分配区间、以及outstanding memory request计数（waitcnt）。当一条指令的operand全部就绪且目标执行单元可用时，wave state table将该指令标记为可调度；scheduler按round-robin或优先级策略从可调度集合中选择指令发射。RDNA 2的wave state table条目减少（每SIMD从20减至16）直接降低了table scan的硬件开销，这是支持更高频率的关键路径优化之一。

3.2.3 ExecutionUnit

RDNA 2的执行单元微架构延续了RDNA 1的"每CU双SIMD32 + 双SALU"配置，但通过pipeline深化、频率提升和新增固定功能单元实现了更高的单位面积性能。

双SIMD32架构与高频优化

每个CU配置2个独立的SIMD32矢量流水线，每周期最多完成64个FP32运算（32×2）。为实现>2.2 GHz的典型运行频率（较RDNA 1的~1.8 GHz提升约22-39%），RDNA 2对ALU pipeline进行了stage细分：通过增加pipeline depth缩短每级组合逻辑的propagation delay，使更高频率下的timing closure可行。更深的pipeline意味着单条指令的execution latency可能增加1-2个cycle（例如FP32 MUL/MAD从N cycle变为N+1 cycle），但在GPU这种throughput-oriented架构中，更高的时钟频率直接转化为更高的peak throughput，单指令latency的增加被frequency gain覆盖。

每SIMD wavefront上限从20降至16也简化了执行单元侧的状态管理：更少的in-flight wave意味着更少的active execution mask和更少的register file bank conflict，有利于高频下的operand fetch和writeback。

标量单元与L0 Scalar Cache

RDNA 2保留每CU 2个SALU的设计，每周期最多并行发射2条标量指令。SALU配有16 KB L0 Scalar Cache，用于存储常量数据、descriptor pointer和立即数，命中时可提供单周期访问延迟。标量路径的独立性（独立cache + 独立ALU）使地址计算、循环控制和分支决策不占用矢量unit的slot，这是AMD架构相较于NVIDIA SM（标量操作通常嵌入在warp scheduler中）的一个结构性差异。

Ray Accelerator：固定功能Intersection Test单元

RDNA 2在每个CU内新增了一个Ray Accelerator（RA），物理集成在TMU内部，共享TMU的地址计算逻辑和部分cache hierarchy。RA的硬件能力边界已在上文ISA部分讨论，此处从执行单元角度补充其data path和集成细节。

RA的物理执行流程如下：

1. 指令发射：shader通过IMAGE_BVH_INTERSECT_RAY指令发起请求，operand（ray origin/direction、BVH node address）从VGPR经TMU operand path传入RA。
2. Address generation：RA复用TMU的address generation unit计算BVH节点在显存中的物理地址。若节点数据命中L0/L1/L2/Infinity Cache，直接从cache读取；否则发起显存读取请求。
3. Intersection computation：RA内部的固定功能逻辑执行4-wide box test或1-wide triangle test。box test采用slab method同时测试ray与AABB的6个面；triangle test采用类ray-triangle intersection fixed-function datapath，内部算法未公开。
4. Result return：intersection结果（hit/miss、t distance、barycentric coordinates、primitive ID）写回VGPR，由后续shader指令读取处理。

RA集成在TMU中的工程权衡：

• RA可共享TMU现有的address generation、TLB lookup和cache access path，避免了为光追功能重复建设完整的memory interface。每个RA面积开销相对独立RT Core较轻重量的业界估算 （第三方估算），在Navi 21（80CU）中光追相关单元的总面积占比较小，占整个GPU die area的约2-3%。
• RA请求与常规texture sample请求共享TMU的dispatch端口和L0 texture cache bandwidth。在高光追负载下（如大量ray同时发起intersection请求），TMU端口可能成为瓶颈，常规texture sampling throughput会受挤占。
• BVH traversal产生大量随机、非合并的显存访问（读取BVH节点、顶点数据），与texture sampling的2D spatial locality访问模式不同。RA的访问模式更接近于random memory read，对cache的line fill效率和bank distribution提出不同要求。

与NVIDIA RT Core的关键差异对比：

这一差异决定了RDNA 2在光追workload中的性能特征：对于BVH深度较浅、ray coherence较高的场景（如primary ray shadow、简单反射），软件traversal的overhead较小，RA的intersection acceleration可有效提升性能；对于BVH深度大、ray divergence严重的场景（如recursive glossy reflection、全局光照的大量secondary ray），频繁的shader-roundtrip和low occupancy会限制整体throughput。

INT/FP混合运算能力

RDNA 2的每个SIMD32矢量流水线支持FP32和INT32的全速执行，每周期可在FP32或INT32中选择一种类型执行（非并行混合）。这与NVIDIA Turing/Ampere架构中部分单元支持并发FP32+INT32 execution的设计不同。RDNA 2通过编译器调度实现FP/INT操作的pipeline interleaving，依赖高occupancy隐藏类型切换的bubble。V_DOT dot指令的引入增强了低精度整数运算的并行度，但执行单元本身未增加独立的INT datapath。

3.2.4 RegisterFile

RDNA 2的寄存器文件组织延续了RDNA 1的大容量VGPR设计，并根据wavefront数量上限的调整重新平衡了资源分配。

VGPR

每个SIMD32单元配备128 KB VGPR file，按256-entry × 32-lane × 32-bit组织。在16 wave上限下，每条wavefront可分配的VGPR数量上限为64个256-bit vector register（256-entry / 16-wave）。相较RDNA 1的20 wave上限（每wave约40个VGPR的理论分配），RDNA 2为每条wave提供了约60%更多的VGPR空间。这对编译器的影响是：更复杂的shader（大量临时变量、长live range）可在不spill到LDS/显存的情况下获得足够的register allocation，减少了spill-induced memory traffic和wave launch latency。

一个RDNA 2 WGP包含4个SIMD32，总计512 KB VGPR capacity，可同时驻留64条wavefront。对比NVIDIA Ampere SM（约256 KB register file，48 warp容量），RDNA 2 WGP的register file总容量约为2倍，per-wave平均VGPR分配更为宽裕 （Chips and Cheese 架构分析）。

SGPR

每个CU为两套SALU各配备独立的SGPR file。RDNA 2未公布具体物理entry数量，但沿用GCN/RDNA传统，每wavefront在Wave32模式下至少可访问102个逻辑SGPR（部分为保留寄存器，用户可用约96个）。Wave32模式下每条wave占用的SGPR物理资源为Wave64的一半，在相同SGPR capacity下可支持更多wavefront并发。由于总并发wavefront数从40/CU降至32/CU，SGPR竞争压力相应降低。

Wavefront数量调整的资源分配含义

每CU wave上限从40降至32，是用并发度换单wave资源深度。在GPU资源分配中，编译器面临VGPR usage与occupancy的trade-off：更多VGPR意味着更高的单wave IPC（更少的spill、更多的instruction-level parallelism可被exploit），但会occupancy降低导致latency hiding能力减弱。RDNA 2通过硬件上限的调整，在registers和wave count之间取了不同的平衡点。这一策略的有效性依赖于Infinity Cache和更高频率对latency hiding的部分补偿：当cache miss latency从数百cycle（显存访问）降至约90-100 ns（Infinity Cache命中）时，维持相同latency hiding能力所需的并发wave数量相应减少。

CP / ACE / QoS顶层调度

RDNA 2保留了GCN以来的分层调度体系。Graphics Command Processor（GCP）解析图形命令缓冲区并驱动状态机切换；多个Asynchronous Compute Engine（ACE）实例支持图形与计算任务的并发执行，而非时间片轮转。QoS层面，RDNA 2引入了更细粒度的队列优先级控制，允许驱动为不同任务分配不同优先级，确保帧渲染等关键路径不被低优先级计算任务阻塞。

3.2.5 MemorySubsystem

RDNA 2内存子系统的核心变动是引入了128MB Infinity Cache，作为位于L2与显存控制器之间的额外缓存层级。这一设计的直接动机是弥补RDNA 1的256-bit GDDR6接口带宽不足的问题：Navi 10（RX 5700 XT）在4K分辨率下显存带宽（约448 GB/s）成为性能瓶颈，而RDNA 2通过Infinity Cache在片上提供高带宽数据供给，减少对外部GDDR6的依赖，从而在维持256-bit显存位宽的同时提升了effective memory bandwidth。

Infinity Cache的设计语义与在Memory Hierarchy中的位置

Infinity Cache在RDNA 2 memory hierarchy中的物理位置是memory-side last-level cache（AMD内部代号MALL），所有经过L2的内存请求在到达显存控制器前都必须查询Infinity Cache。其组织方式为多个slice分布在芯片边缘，通过on-die interconnect（Infinity Fabric衍生的环形总线）与L2 cache和显存控制器相连。128MB容量按16个slice × 8MB或类似组织方式分布，每个slice配有独立的tag array和hit/miss逻辑，多slice并行提供aggregate bandwidth。请求经L2输出后，通过crossbar或ring bus路由至对应Infinity Cache slice，slice index由内存地址的固定bit field决定。

从设计语义看，Infinity Cache是read-only cache for most workloads （AMD RDNA 2 白皮书）。它主要截流从显存读取的texture data、buffer data和BVH node data，write traffic（如framebuffer write、UAV write）在多数场景下绕过Infinity Cache直接写回显存。这一语义选择的原因在于：GPU write traffic通常具有较高的streaming特性（顺序写入、低temporal reuse），不适合大容量缓存介入；而read traffic（尤其是texture sampling和repeated buffer access）通常具有较强的temporal和spatial locality，是Infinity Cache的主要收益来源。

收益依赖的约束条件

Infinity Cache的收益并非uniform，高度依赖workload的以下特征：

1. Working set size ≤ 128MB：当活跃数据集可完全驻留在Infinity Cache中时，read bandwidth接近on-die SRAM水平（第三方测试测得约1.5-1.8 TB/s aggregate bandwidth （Chips and Cheese）），远超256-bit GDDR6的~512 GB/s物理峰值。当working set超过128MB时，发生capacity miss，请求fall through到GDDR6显存，effective bandwidth断崖式下降至物理显存带宽水平。
2. Spatial locality：Infinity Cache以cache line（通常为64B或128B）为单位传输数据。访问模式具有良好的spatial locality（如顺序texture read、结构化buffer access）时，line fill的data utilization率高；random access模式（如BVH traversal中跳转到不相关的节点）会导致cache line中大量byte未被使用，浪费internal bandwidth。
3. Temporal reuse：Infinity Cache的收益与同一数据区域被多次访问的概率成正比。传统游戏渲染中，frame buffer tile data、shadow map、环境贴图等通常被多个draw call或shader pass重复读取，temporal reuse率高；streaming workload（如视频decode、大数据集GPGPU计算）中数据通常只被访问一次，temporal reuse接近零，Infinity Cache不产生有效带宽增益。

收益下降的workload类型

以下场景中Infinity Cache的效益明显降低：

• Ray tracing BVH traversal：secondary ray的访问模式高度随机，不同ray指向BVH中不相关的节点，导致poor spatial locality和cache thrashing。
• Large dataset GPGPU compute：当working set远超128MB时，cache capacity miss rate趋近于100%，Infinity Cache退化为pass-through buffer。
• Texture streaming / virtual texture：数据持续从磁盘/主存流入GPU显存，GPU端working set动态变化，cache warm-up阶段长且命中率不稳定。
• UAV read-after-write密集型计算：write traffic是否缓存取决于具体memory type、cache policy和render target/UAV path。部分write traffic（如framebuffer write配合特定cache policy）仍可能经过Infinity Cache，但多数UAV store/buffer store在默认配置下绕过Infinity Cache直接写回显存。因此read-after-write的coherency路径因配置而异，不能假定Infinity Cache统一保护或不保护。

Infinity Cache不能解决的问题

Infinity Cache并非万能带宽解决方案，以下问题不在其解决范围内：

• TLB miss latency：地址转换仍依赖TLB hierarchy。Infinity Cache位于物理地址域，VA-to-PA translation的TLB lookup在进入Infinity Cache之前完成。大页（huge page）支持不足或稀疏地址访问模式下的TLB miss penalty不受Infinity Cache影响。
• Descriptor fetch latency：texture/resource descriptor的读取路径独立于Infinity Cache的数据路径，descriptor cache miss的延迟由descriptor cache层次决定。
• Memory coalescing：Infinity Cache不改善wavefront内部各thread的地址分散度。如果32个lane的read请求分散到不相关的cache line，仍会产生32个独立的cache access，coalescing效率取决于地址模式而非cache容量。
• Compression metadata overhead：Infinity Cache存储的是decompressed或uncompressed数据。若显存中的texture/framebuffer采用delta color compression（DCC），从显存读取时的decompression开销在Infinity Cache miss path上依然存在。

延迟数据与独立时钟域

第三方微基准测试（Chips and Cheese）测得RDNA 2 Infinity Cache的访问延迟约90-100 ns（取决于working set size和测试方法） （Chips and Cheese 微基准）。作为对比，同期NVIDIA Ampere架构（RTX 3090）的6MB L2 cache访问延迟约140 ns （Chips and Cheese 同一测试源）。RDNA 2在cache hit latency上的优势部分来源于更大的cache容量（更多数据可命中而不fall through到显存），部分来源于cache hierarchy的组织方式（L2 → Infinity Cache → VRAM路径 vs NVIDIA的L1 → L2 → VRAM路径）。

Infinity Cache可能采用独立时钟/电源域设计以优化能效 （第三方推测）：若其 SRAM array 和 tag logic 运行在与核心 CU/L2 不同的时钟频率下（通常低于 core clock），设计动机在于 Infinity Cache 的访问频率低于 L0/L1/L2（大部分前端访问在更靠近执行的缓存层级命中），允许以较低的 clock rate 运行而不明显影响 aggregate throughput；较低的频率直接转化为 dynamic power savings，这可能是 RDNA 2 在相同工艺下控制功耗的手段之一。AMD 未公开确认 Infinity Cache 的时钟域划分，以下分析基于架构推测。第三方实测为这一推测提供了间接支撑：Chips and Cheese 随核心频率扫描的延迟测试显示，RDNA 2 核心降频时 WGP 从 Infinity Cache 取数所需的周期数反而减少，行为与以更低频率运行的独立时钟域一致；该媒体在分析中将 Infinity Cache 采用独立时钟域作为既定结论陈述，理由正是 L2 已截流大部分访问、Infinity Cache 性能不再是关键路径，降频运行可直接节省动态功耗。

L0/L1/L2缓存的协同优化

RDNA 2的前级缓存也做了相应调整以配合Infinity Cache：

• L0 Data Cache：每CU 16 KB，服务于两个SIMD32的load/store单元。RDNA 2通过提升CU频率间接提高了L0 effective bandwidth（bandwidth = frequency × width）。
• L1 Cache：每Shader Array 128 KB，RDNA 2优化了TLB design以减少translation latency，并改善了cache associativity以降低conflict miss rate。
• L2 Cache：Navi 21配备4MB统一L2。RDNA 2的一个关键优化是允许部分memory traffic绕过L2：page table属性标记为non-cacheable或跨CPU/GPU coherency同步时，访问可直接skip L2，由Infinity Cache捕获。RDNA 2的L2 bandwidth scaling特性也有所改善：测试显示RDNA 2的L2 bandwidth在单CU到满配WGP的范围内扩展更线性，而RDNA 1在half-WGP（单CU）运行时L2 bandwidth出现明显下降，暗示RDNA 2可能将部分L2 queue/bank资源从per-CU exclusive改为WGP-shared （微基准测试观察）。

带宽效率的实测表现

在typical游戏workload中（working set < 128MB，temporal reuse明显），RDNA 2的effective read bandwidth可达1.5 TB/s量级（Infinity Cache hit path），是物理GDDR6带宽的约3倍。当working set超出128MB时，effective bandwidth下降至GDDR6的~512 GB/s水平，此时与NVIDIA RTX 3090的384-bit GDDR6X（936 GB/s peak）相比处于劣势。Chips and Cheese的测试进一步指出：RDNA 2的cache hierarchy在低并发度（单WGP）下即可提供高bandwidth，而Ampere架构需要更多SM并发运行才能"撑满"L2 bandwidth，这反映了二者在cache port和queue design上的组织差异 （Chips and Cheese 微基准）。

对于计算workload，Infinity Cache的效益取决于dataset size和access pattern：小dataset（<128MB）的高带宽计算（如图像滤波、小规模矩阵运算）可几乎完全命中Infinity Cache；大dataset的streaming compute则受限于物理显存带宽。

3.2.6 Functional Features

图形管线特性

NGG完全体与Mesh Shader执行模型

RDNA 1首次引入了NGG（Next-Gen Geometry）硬件，将传统顶点处理流水线的多个阶段（vertex shader、optional geometry shader、hull/domain shader for tessellation）融合为单一的Primitive Shader阶段。但RDNA 1的NGG存在一个关键限制：不支持per-primitive attribute output，即shader无法为每个生成的primitive（三角形）输出独立的属性数据。这一限制导致Mesh Shader的完整功能无法在RDNA 1上实现，因为Mesh Shader要求每个meshlet中的primitive可携带独立的primitive-level attribute。

RDNA 2解除了这一限制，NGG shader现在支持per-primitive output attribute。从硬件执行模型看，Mesh Shader在RDNA 2上的执行路径如下：

1. Amplification Shader（任务着色器）阶段（可选）：GPU以task/meshlet粒度dispatch workgroup，每个thread评估是否需要生成对应meshlet。这一阶段用于 LOD culling、frustum culling 等粗粒度剔除，避免将不可见meshlet送入后续管线。
2. Mesh Shader阶段：通过amplification shader激活的meshlet被dispatch为workgroup（通常一个meshlet对应一个workgroup）。workgroup内的thread通过LDS协作，计算顶点位置和属性。Mesh Shader的核心操作是：thread通过vertex index写入vertex data（position + attribute），通过primitive index写入primitive connectivity（vertex index triple）和per-primitive attribute。
3. LDS payload管理：由于NGG硬件仍限制每个thread最多输出1 vertex + 1 primitive，驱动需在LDS中建立vertex/primitive的staging buffer。thread先在LDS中累积vertex和primitive数据，完成后由hardware NGG unit统一导出至rasterizer。LDS容量（每CU 64 KB，WGP mode下合并为128 KB）直接约束了单个meshlet可承载的vertex/primitive数量。
4. Primitive export至光栅器：NGG hardware将导出的vertex和primitive组织为rasterizer可消费的格式，进入光栅化阶段。

与传统vertex/tessellation/geometry pipeline的关键差异：meshlet-based vertex reuse由软件显式管理，不依赖自动的post-transform cache兜底。在传统管线中，vertex shader的输出自动进入post-transform cache（通常为FIFO组织，容量约16-32 entry），具有相同vertex index的后续图元可复用cached结果，hit时节省完整的vertex shading计算；在Mesh Shader模型中，同一meshlet内的vertex sharing由developer在meshlet generation阶段决定（通过optimal mesh decomposition算法最大化intra-meshlet vertex sharing），但不同meshlet间不存在硬件vertex reuse：同一vertex若被多个meshlet引用，会在每个meshlet的Mesh Shader invocation中被重复计算。这要求meshlet generation在vertex sharing和meshlet parallelism之间取平衡：过小的meshlet（如<32 primitive）降低parallelism和wave utilization，过大的meshlet（接近LDS capacity上限）限制同时驻留的meshlet数量。RDNA 2的128 KB LDS（WGP mode）理论上可支持约85 vertex + 124 primitive的meshlet（按D3D12 Mesh Shader spec推荐的max payload估算），实际游戏中常用64-128 primitive的meshlet size以在vertex reuse和occupancy之间取得平衡。

RDNA 2 NGG完全体的另一收益是更激进的triangle culling：由于所有几何处理统一在Primitive Shader中完成，驱动可在export前执行小三角形剔除、back-face culling和degenerate primitive culling，减少进入rasterizer的无效图元数量。这对geometry-dense场景（高tessellation级别、复杂角色模型）有直接的pixel shader调用 reduction 效果。

NGG 完全体的意义不限于剔除收益。放回 Vega 到 RDNA 2 的几何前端演进中看，还有一层语义变化：硬件管什么，软件管什么，边界正在移动。

Draw 语义与 PSO 模型的物理瓦解从这里开始。

传统 DrawIndexed 管线的顶点重用依赖两段固定功能逻辑：按 index 的隐式硬件去重（index deduplication），以及 FIFO 组织、容量约 16 到 32 个 entry 的 post-transform cache 滑窗。命中时省下一次完整的 vertex shading，重用由硬件自动完成，开发者甚至感知不到它的存在。这套机制在三角形尺寸均匀、index 局部性良好的年代是合格的。物理约束却是硬的：滑窗容量不可扩展，复用间隔一旦超出窗口，命中率不是线性下滑而是断崖式坍塌。Nanite 级别的超高精度集群几何把三角形压到像素尺寸，同一顶点的复用间隔被打散，隐式重用恰好在最需要它的场景中失效。固定前端的峰值吞吐也有明确上限：从 Tahiti 的 2 个 Shader Engine 到 Hawaii 的 4 个，扩展方式只是堆数量，每时钟 4 个三角形的上限沿用了多代。两者合在一起，是固定功能前端几何调度能力物理见顶的直接证据。

AMD 的回答分两步：Vega 的 Primitive Shader 是未遂的尝试，RDNA 的 NGG 把它变成正式路径。在 Mesh Shader 路径上，硬件不再提供跨 meshlet 的隐式 vertex 去重。上文的对照已经写明，meshlet 内的 vertex sharing 由开发者在离线切分阶段决定，跨 meshlet 的重复计算被接受为常态。作为交换，LDS 被提升为核心资源：顶点与图元的 staging buffer 直接暴露给线程组，去重、排序、剔除全部成为显式代码。LDS 容量（每 CU 32 KB，WGP 模式合并 64 KB）[待作者定夺：此处数据与上文每 CU 64 KB / WGP 128 KB 矛盾] 直接约束单个 meshlet 可承载的 vertex 与 primitive 数量，理论上限约 85 vertex 加 124 primitive，实际常用 64 到 128 个 primitive 以在 vertex reuse 与 occupancy 之间取平衡。Shader Culling 同理，剔除决策从光栅化前的固定功能阶段移入 shader 内部，剔除率的收益与剔除计算的 ALU 代价由开发者自行权衡。隐式机制被移除，控制权与责任一起移交软件。RDNA 1 的 NGG 仍受拓扑类型与 per-primitive 属性输出限制，部分 legacy 路径需回退固定功能管线；RDNA 2 解除属性输出限制后，这条路径才具备承载完整 Mesh Shader 的能力。

被瓦解的不只是几何前端的组织方式，还有 Retained-mode PSO（Pipeline State Object）与 Draw 语义的物理基础。Draw 调用隐含一个承诺：硬件会处理重用与剔除。PSO 隐含一个假设：管线阶段划分与硬件阶段一一对应。当几何调度被证明可以由通用 CU、LDS 与显式代码完成，且吞吐上限随 CU 数量扩展而不再由固定前端锁死，这两个承诺就失去了硬件依据。驱动用 heuristics 决定 NGG 启用与否，这个灰色地带本身是过渡期证据：硬件能力已经就位，API 语义还没跟上。Vega 到 RDNA 2 的演进说明，厂商在硅片预算上的取舍已经给出答案。Draw 是否还能作图形 API 的基本原语，需要与内存模型、同步语义两条线放在一起回答。

光栅器性能提升

RDNA 2的光栅器（Rasterizer）像素产出率从RDNA 1的16 pixel/clk提升至32 pixel/clk，推测通过增加scan conversion pipeline中的parallel packer单元实现。以Navi 21（16个RB分区）为例，peak pixel throughput为32 × clock frequency，在2.5 GHz下约80 Gpixels/s。这一提升的主要动机是：RDNA 2的CU频率和ALU吞吐增加后，后端着色器（pixel shader、ROP）的consumption rate提高，需要更高的光栅器产出 rate 来匹配后端消费速率。大三角形覆盖率高（fill-rate-bound）的场景中，光栅器升级可提升整体pixel throughput接近2倍；极小三角形（只覆盖少数像素）的场景中，32 pixel/clk的capacity可能无法充分利用，但这是geometry-bound而非rasterizer-bound场景，光栅器升级不构成浪费。

Render Backend+（RB+）

RDNA 2将每个RB分区的ROP（Raster Operation Processor）数量从4个翻倍至8个。Navi 21（16 RB分区）共配备128个ROP，较Navi 10的64个ROP翻倍。ROP翻倍与光栅器upgrade相匹配：更多的pixel fragment需要对应的color blend和framebuffer write能力。在高分辨率（4K）和HDR（每通道16-bit floating point）渲染中，color write bandwidth和ROP throughput是常见瓶颈，RB+的增加直接提高了framebuffer write rate。RDNA 2保持了每个RB 16 pixel/clk的Z/Stencil test能力，总计256个Z/Stencil单元，与RDNA 1高端型号持平；深度测试能力在RDNA 1时代已较为充裕，非RDNA 2的主要扩展方向。

VRS Tier 2

RDNA 2支持DirectX 12 Ultimate Variable Rate Shading Tier 2，允许以2×2、1×2、2×1、或1×1 pixel granularity指定不同screen区域的shading rate。硬件光栅器根据shading rate mask在光栅化阶段合并相邻pixel为单一shading quad，减少pixel shader invocation数量。RDNA 2的VRS实现对per-triangle shading rate（通过SV_ShadingRate系统值）和per-screen-tile shading rate（通过shading rate image）均提供硬件支持。

Sampler Feedback

RDNA 2支持DX12 Ultimate Sampler Feedback，允许texture unit在sample操作后记录访问的mip level和tile坐标至feedback map。应用可依据feedback map进行texture streaming决策，仅加载实际被sampled的texture region，减少显存占用和IO带宽。该功能由TMU硬件自动完成，无需ALU介入。

计算特性

低精度AI推理支持

RDNA 2通过V_DOT dot指令（见3.2.1节ISA部分）为低精度AI推理提供了ISA层面的支持。实测中FP16/INT8 inference throughput较RDNA 1提升数倍 （第三方推理 benchmark），但peak throughput仍明显低于配备Tensor Core的NVIDIA Ampere架构。V_DOT对大GEMM的吞吐受限分析见 3.2.1 节。

Infinity Cache对计算的适用性

Infinity Cache对计算workload的收益遵循 3.2.5 节分析的三项约束（working set size、spatial locality、temporal reuse）。简言之：dataset < 128MB且高复用的计算可获接近片上SRAM带宽，大dataset streaming则受限于GDDR6物理带宽；write traffic在多数默认配置下绕过Infinity Cache。

3.2.7 小结

RDNA 2在维持7nm工艺节点不变的前提下，通过架构层面的多项改进实现了性能提升。核心改动可分为三类：

频率与效率优化：通过加深ALU pipeline、精简wavefront调度条目（20→16 per SIMD）、优化缓存queue design，RDNA 2将典型运行频率从RDNA 1的~1.8 GHz提升至2.2-2.5 GHz，并在保持IPC的同时降低了per-cycle调度开销。这些微架构打磨是RDNA 2 per-CU性能提升的基础。

带宽结构创新：128MB Infinity Cache作为memory-side last-level cache，通过片上SRAM截流显存read traffic，在working set < 128MB且temporal reuse较高的workload中将effective read bandwidth提升至1.5 TB/s量级。该设计有效弥补了256-bit GDDR6（~512 GB/s peak）的物理带宽不足，使RDNA 2在4K游戏场景中避免了显存带宽瓶颈。Infinity Cache的收益受working set size、spatial locality和temporal reuse约束，在streaming或random access workload中效益下降。独立时钟域设计使其可在低于core frequency下运行，控制dynamic power。

功能扩展：Ray Accelerator以相对Tensor Core更轻量的面积开销提供了4 box/1 triangle per cycle的固定功能intersection test能力 （第三方面积估算，非 AMD 官方数据），通过DXR/Vulkan RT API暴露给开发者。与NVIDIA RT Core的关键差异在于RDNA 2保留BVH traversal在shader域执行，仅offload intersection test至固定功能单元，这一选择在area efficiency和traversal flexibility之间取了不同的平衡点，代价是high-divergence ray workload中的shader occupancy压力和shader-roundtrip latency。NGG完全体解除了per-primitive output限制，使RDNA 2完整支持Mesh Shader执行模型，其性能依赖meshlet layout、LDS组织和wave occupancy的协同优化。V_DOT packed dot指令在常规VALU上提供了低精度运算加速，但吞吐受限于VALU物理width，不具备专用矩阵运算单元的peak throughput。

RDNA 2与RDNA 1的关系是渐进演进：RDNA 1确立了Wave32/WGP的游戏效率基础，RDNA 2在此之上提升了频率、补齐了带宽结构和功能特性。RX 6000系列在部分游戏中达到了与竞品Ampere架构相当的光栅化性能，但二者在不同workload类型（cache-friendly vs bandwidth-bound、ray tracing light vs heavy）下各有优势区间。RDNA 2的设计取舍反映了AMD在有限die area和power budget下的资源分配策略：优先提升传统光栅化效率（高频+大cache），将光追和AI加速以最小增量成本纳入（RA集成在TMU内、V_DOT复用VALU），而非像NVIDIA那样为RT和Tensor分别建设独立的大面积专用单元。这一策略使RDNA 2在die size和cost efficiency上具有一定优势，但在纯光追和矩阵计算peak throughput上存在gap。后续RDNA 3通过引入Matrix Core和改进光追单元，部分弥补了这些gap。

3.3 RDNA 3

RDNA 3（gfx1100系列）是AMD面向Radeon RX 7000系列（Navi 3x GPU）的图形微架构。它在RDNA 2的7nm单片设计基础上，沿三个主线演进：CU内部执行带宽增加（Dual-Issue SIMD）、AI矩阵运算硬件化（WMMA指令族）、以及物理实现层面的Chiplet封装（5nm GCD + 6nm MCD）。三条主线分别对应指令吞吐能力、专用计算能力、芯片制造约束三个不同维度，彼此间存在耦合关系，也各自引入了新的工程取舍。

Chiplet设计在RDNA 3中的层次定位值得先厘清。Chiplet解决的是单片大芯片（monolithic die）的面积和良率问题，但它不改变GPU Core内部的微架构组织。GCD（Graphics Compute Die，5nm工艺）包含完整的CU/WGP阵列、L0/L1/L2缓存层级、Command Processor、Shader Engine、Geometry Engine、Rasterizer、RB（Render Backend）等所有图形和计算微架构组件。MCD（Memory Cache Die，6nm工艺，每片37.5mm²）则集成16MB Infinity Cache SRAM和一个64-bit GDDR6显存控制器。Navi 31包含1个GCD和6个MCD，通过Infinity Fabric die-to-die互连封装在同一基板上。在后续分析中，CU/WGP/Cache/Front-End/RB等微架构主线与Chiplet封装主线将分别展开，避免让封装叙事压过微架构主线。

RDNA 3的CU保持WGP=2CU的组织方式（Navi 31最多48WGP=96CU），但每个CU的理论向量执行峰值从128 FP32 FLOP/cycle（64 FP32 FMA/cycle）提升至256 FP32 FLOP/cycle（128 FP32 FMA/cycle），这一翻倍依赖VOPD Dual-Issue机制和Wave64交替发射实现，而非简单增加SIMD数量。每个CU新增2个WMMA矩阵运算单元，支持Wave级协作的16×16矩阵乘加，为消费级Radeon首次提供了AI推理硬件加速。缓存层级各级扩展：L0向量缓存从16KB增至32KB/CU，L1从128KB翻倍至256KB/Shader Array，L2从4MB增至6MB。Infinity Cache容量从128MB减至96MB（分布在6个MCD上，每片16MB），但通过并行访问实现了更高的理论带宽。

RDNA 3.5（gfx1150/gfx1151）是RDNA 3面向移动APU的变体，核心微架构未变，但在ISA层面引入标量FPU和VGPR单次使用提示等编译器协同机制，针对不同SKU调整了寄存器文件规模（gfx1150为128KB VGPR/SIMD，gfx1151为192KB VGPR/SIMD），并在功耗管理方面做了面向移动场景的优化。

3.3.1 ISA

RDNA 3在保持与RDNA 2基本兼容的指令集框架之上，针对双发射执行、矩阵运算、光追和调度优化新增了以下ISA扩展：VOPD双指令打包格式、WMMA矩阵指令族、S_DELAY_ALU调度提示指令、以及DLC缓存控制hint。RDNA 3.5进一步增加了标量浮点指令和S_SINGLEUSE_VDST寄存器提示。这些扩展的目标是让编译器能更精确地控制新硬件单元的行为，缓解因硬件复杂性增加而带来的调度不确定性。

VOPD Dual-Issue指令格式

VOPD（Vector OP Dual）是RDNA 3为配合双SIMD执行单元而引入的指令格式。它将两条独立的标量同类向量指令（homogeneous vector instructions）打包为一条64-bit指令，由编译器在ISA层面完成配对，硬件以dual-issue方式发射执行。每个VOPD指令包含两个操作槽位，各有独立的源操作数和目的寄存器编码域。例如，编译器可将两条无关联的FP32加法指令打包为v_dual_add_f32，在一个时钟周期内由CU的两个SIMD分别执行。

VOPD并非VLIW的回归，其打包约束远严于传统VLIW：

• 指令类别限制：仅特定类别的ALU指令支持打包，主要是简单的算术（V_ADD_F32、V_MUL_F32、V_FMA_F32）和逻辑（V_AND_B32、V_OR_B32、V_XOR_B32）操作。transcendental指令（如V_LOG_F32、V_SIN_F32）、访存指令（V_BUFFER_LOAD）、复杂ALU指令不在VOPD支持范围内。
• 寄存器配对约束：VOPD两条指令的合法性由具体ISA编码和寄存器分配约束共同决定，不可简单归纳为"所有操作数映射到不同Bank"。LLVM AMDGPU后端中存在exact pairing rule：部分操作数组合因ISA编码位宽或寄存器端口限制无法共存于同一VOPD指令，即便物理上分配到不同Bank。Bank冲突是必要条件之一但非充分条件，编译器需同时满足指令类别配对表、寄存器编号约束和数据独立性才能生成合法VOPD。
• 数据依赖限制：打包的两条指令之间不能存在读后写（RAW）、写后读（WAR）或写后写（WAW）依赖。若指令A的目的寄存器是指令B的源寄存器，则二者不能构成VOPD。
• 执行模型约束：VOPD打包在编译期完成，硬件按打包结果发射执行。VOPD的具体发射行为（如槽位失败时的处理策略）取决于微架构实现细节，公开资料未披露内部回退机制 [待确认]。

这些限制决定了VOPD的打包效率高度依赖编译器的静态分析能力。在LLVM AMDGPU后端中，VOPD的发掘发生在指令选择后的调度阶段：编译器首先识别出独立的同类型VALU指令对，然后检查其寄存器分配是否满足Bank不冲突条件，最后生成VOPD编码。即使启用最高级别的优化（-O3、target-specific scheduling），真实着色器的VOPD利用率通常在10%-30%区间，距离理论50%的打包率上限有较大差距。图形负载中常见的texture sample → ALU → branch模式天然限制了ILP的暴露，使得可用于打包的独立指令对数量有限。

对于Wave64模式，硬件采用交替发射（interleaved dispatch）机制：一个Wave64波前被逻辑拆分为两个Wave32 half-waves，硬件在连续两个时钟周期内交替将同一条指令的两个half分别发送到SIMD0和SIMD1。这种机制对编译器完全透明，不依赖VOPD打包，几乎不受指令类别和Bank冲突的限制（两个half-wave操作的是同一组寄存器，天然满足Bank一致性）。Direct3D Shader Model 6.x在RDNA 3上的实际wave size由shader stage、编译器heuristic、驱动策略和shader profile共同决定，不同workload可能选用Wave32或Wave64。Wave64模式以更低的编译器复杂度实现较高的双SIMD利用率，因此图形pipeline中常见Wave64被用于pixel shader等stage，但不宜概括为全局默认值。

VOPD对峰值吞吐的贡献需要放在实际约束中理解：理论峰值256 FP32 FLOP/CU/cycle（128 FMA/cycle）需要VOPD或Wave64交替发射同时达到满效率。在VOPD利用率偏低的Wave32着色器中，实际吞吐更接近64-80 FP32/CU/cycle。RDNA 2的峰值是64 FP32/CU/cycle，因此RDNA 3相比RDNA 2的改进幅度在0%（Wave32且无可打包指令对时）到100%（Wave64交替发射满效率时）之间波动，典型图形负载的改进中位数约20%-40%，高度取决于编译器质量和代码的ILP特征。VOPD是RDNA 2 Dual-Issue理念的硬件化实现：RDNA 2的两个SIMD已经能分别执行来自不同wavefront的指令，RDNA 3增加了同一wavefront驱动两个SIMD的能力，但保留了RDNA 2的基本调度框架。

Wave MMA矩阵指令

WMMA（Wave Matrix Multiply-Accumulate）是RDNA 3首次在消费级Radeon中引入的矩阵运算指令族，定位与CDNA架构上的大规模MFMA（Matrix-Fused Multiply-Add）单元不同：CDNA面向HPC/AI训练场景，每CU配备4个MFMA单元，峰值吞吐超过1024 FLOPs/CU/cycle；RDNA 3面向游戏+轻量AI推理，每CU仅2个矩阵单元，在芯片面积和功耗受限的条件下提供"足够好"的AI算力（官方定位接近NVIDIA Turing Tensor Core水平）。

执行模型：WMMA以整个Wavefront（Wave32或Wave64）为协作单位完成16×16×16 GEMM操作。数据路径如下：

1. 操作数准备：源矩阵A（16×16）和B（16×16）的元素分布在wavefront的所有lane的VGPR中，或通过LDS/cache加载。编译器需要确保各lane持有的元素位置符合WMMA指令的layout约定（标准row-major或column-major tile分布）。
2. 指令发射：Wave Scheduler识别WMMA指令 → 检查2个matrix unit的可用性（WMMA执行期间matrix unit锁定，其他wavefront的WMMA指令需排队等待）→ 发射至空闲unit。
3. 矩阵乘加执行：Matrix unit内部执行多周期MAC阵列运算。输入的A、B tile在unit内部保持驻留并复用，部分乘积通过forwarding network直接累加至accumulator，无需每步写回VGPR。这一数据驻留和结果转发机制是WMMA效率的核心，避免了通用ALU方案中逐元素计算导致的频繁VGPR读写。
4. 结果回写：完成的16×16结果矩阵C以fragment形式写回各lane的VGPR，每个lane保存结果矩阵的一个子集（fragment）。Fragment压缩存储模型减少了VGPR占用，但意味着后续vector指令如需访问完整的C矩阵元素，可能需要额外的shuffle操作。

精度支持：WMMA支持FP16和BF16输入累加至FP32，以及INT8/INT4输入累加至INT32。每CU每cycle的理论峰值：FP16/BF16为512 FLOPs（2 units × 256 ops/unit/cycle），INT8为1024 ops，INT4为2048 ops。一次完整的v_wmma_f32_16x16x16_f16指令需要约32 cycle在matrix unit内部完成。

对VGPR和调度的压力：WMMA指令的latency（约32 cycle）远高于普通VALU指令（通常2-4 cycle），编译器需要通过S_DELAY_ALU hint或显式的S_WAITCNT指令来管理后续依赖指令的发射时机。同时，WMMA执行期间matrix unit被锁定，其他wavefront即使就绪也无法使用matrix unit，这要求Scheduler在调度WMMA密集型workload时做好指令交错（interleave WMMA指令与其他不依赖matrix unit的指令）。

WMMA与CDNA MFMA的关系：WMMA借鉴了CDNA的矩阵核心设计思想（wave级协作、MAC阵列、数据复用），但在规模和集成方式上有明显差异。CDNA的MFMA单元是CU内独立的专用管线，与VALU/SIMD分离；RDNA 3的WMMA单元同样独立但与VALU共享operand fetch和register file通路，对VGPR bandwidth的竞争更直接。CDNA每CU 4个MFMA单元的配置使其在AI training workload中有数量级优势，而RDNA 3的2单元配置更适合inference场景中的矩阵加速需求。

光追与内存控制指令扩展

第二代Ray Accelerator的ISA支持新增了Ray Flags硬件过滤指令格式。在DXR 1.1中引入的Ray Flags（如RAY_FLAG_CULL_BACK_FACING_TRIANGLES、RAY_FLAG_ACCEPT_FIRST_HIT_AND_END_SEARCH、RAY_FLAG_SKIP_PROCEDURAL_PRIMITIVES等）可在intersection test阶段由硬件加速处理，但RDNA 3的整体BVH遍历仍由Shader驱动（shader-based traversal），Ray Accelerator作为intersection accelerator辅助，而非NVIDIA式的完整硬件traversal pipeline。数据路径：光线遍历指令由Shader发出并携带Ray Flags operand → Ray Accelerator读取Flags → 硬件根据Flags值加速intersection test和early termination判断（例如设置ACCEPT_FIRST_HIT_AND_END_SEARCH时，命中第一个triangle后Shader可据此提前终止该ray的遍历循环）→ traversal控制流仍由Shader管理，hit结果（t、primitive ID、barycentric coordinates）写回VGPR供后续Shader指令使用。

这一机制减少了光追遍历中的iteration次数和branch divergence。在RDNA 2中，intersection结果回传后完全由Shader执行branch判断；RDNA 3将Flags相关的intersection filtering下沉至硬件accelerator后，Shader端仍参与遍历控制但可在更少instruction下完成相同逻辑，VGPR压力和调度开销均降低。

内存控制方面，RDNA 3引入了DLC（Device-Level Cache）hint位，允许驱动或编译器标记特定内存访问为"绕过Infinity Cache"。适用场景是一次性大数据流（streaming data），如视频解码帧输出、大型纹理流（texture streaming）、compute shader的中间结果写入。这些数据特征是高带宽需求、无temporal locality（不会被再次访问），若放入Infinity Cache会占据有限的96MB空间并增加一跳跃迁延迟。数据路径：VMEM/SMEM请求标记DLC bit → memory controller识别后直接从L2 ↔ GDDR6通路传输 → 跳过Infinity Cache的tag lookup、line allocation和replacement逻辑。DLC hint在Linux驱动中通过AMDGPU_GEM_CREATE_DISCARDABLE内存标志间接暴露，但AMD未在官方文档中公开其完整语义和使用约束 [推测]。

S_DELAY_ALU 调度提示指令

S_DELAY_ALU是一条编译器插入的hint指令（非硬性延迟命令，不会阻塞pipeline），格式为S_DELAY_ALU imm，其中imm字段指定延迟cycle数（通常为1-15 cycle）。语义：告知Wave Scheduler紧随其后的VALU指令的结果需要imm个cycle后才能就绪，Scheduler应在等待期间优先调度其他wavefront的指令。

工作机制：编译器在指令调度阶段分析每条指令的latency（通过内置的latency table，VALU通常2-4 cycle、VMEM通常100-500 cycle、 transcendental通常10-20 cycle、WMMA约32 cycle）和依赖链长度，在producer指令和consumer指令之间插入S_DELAY_ALU。Wave Scheduler解码到S_DELAY_ALU时设置内部计数器，计数器非零期间降低当前wavefront的调度优先级，计数器归零后恢复正常评估。

这一设计反映了RDNA 3调度策略的变化：发射端可能采用比前代更激进的假设（指令可以独立发射），在后段通过bypass network或stall处理依赖。S_DELAY_ALU作为compiler-assisted scheduling机制，弥补了纯硬件调度在超长延迟指令上的信息不足。与CDNA架构的scoreboard机制不同，S_DELAY_ALU不强制阻塞，仅调整优先级，不会引入硬件stall cycle。它不增加功耗开销，因为hint解析由Scheduler在常规调度循环中完成，无需额外硬件状态机。

RDNA 3.5的ISA新增特性

标量FPU支持：自GCN以来AMD GPU的Scalar Unit仅包含整数ALU（SALU），用于地址计算、分支判断、循环计数等标量整型操作。RDNA 3.5首次在标量路径引入浮点运算能力，ISA层面新增了S_ADD_F32、S_MUL_F32、S_FMA_F32以及对应的FP16半精度指令。复杂特殊函数（如V_RCP_F32、V_RSQ_F32、V_SIN_F32、V_COS_F32）未在标量单元实现，仍依赖VALU计算后通过V_READFIRSTLANE_B32或类似机制写回SGPR。

执行路径变化：编译器识别着色器中不随lane变化的浮点计算（如uniform参数的中间计算、常量表达式求值）→ 转换为标量浮点指令 → Scalar FPU执行 → 结果写入SGPR → 后续vector指令通过scalar source operand机制（如V_ADD_F32 v0, s0, v1，其中s0为SGPR）直接读取SGPR值。这避免了将标量值broadcast到所有lane的VGPR后再执行vector操作的模式，节省了VGPR allocation slot和VALU cycle。

标量FPU的引入在APU场景尤为重要：APU的CU数量通常较少（8-16 CU），每CU的wave occupancy直接决定了能否有效隐藏memory latency。任何能减少VGPR占用、释放VALU资源的机制都能线性转化为更高的有效throughput。标量FPU在RDNA 3.5中首发，后续RDNA 4延续此设计。

S_SINGLEUSE_VDST：RDNA 3.5新增的寄存器单次使用hint指令，格式为S_SINGLEUSE_VDST。语义：紧随该指令后的vector指令，其所有源操作数在使用后不再被复用，硬件无需将这些操作数缓存在operand reuse cache中。

数据路径影响：RDNA 3及之前的operand reuse cache由硬件启发式自动管理：近期使用的操作数被缓存在cache中，后续指令若复用同一操作数可直接从cache读取而无需访问VGPR Bank。S_SINGLEUSE_VDST允许编译器显式声明"一次性"操作数，硬件据此跳过对应操作数的cache分配，将cache slot留给更有复用价值的操作数。收益场景：在VOPD dual-issue或WMMA指令附近，编译器已知某些操作数（如常数加载结果、临时计算值）为一次性，通过此hint降低Bank冲突概率，提升有效发射率。

与NVIDIA方案的对比：Turing以来的NVIDIA GPU采用逐操作数标记reuse标志的精细方案（REUSE bit在指令编码中显式标记哪些操作数需要缓存），默认不缓存。AMD的S_SINGLEUSE_VDST是粗粒度方案（一刀切作用于下一条指令的全部源操作数），优势是不增加vector指令的编码位宽，代价是控制精度较低。实际效果取决于编译器的分析质量：过度使用S_SINGLEUSE_VDST可能导致本可复用的操作数被驱逐，反而增加VGPR Bank访问。

双标量源操作数支持：RDNA 3.5放宽了DPP（Data-Parallel Primitives）指令的操作数约束，允许src0和src1同时为标量寄存器（SGPR）。此前RDNA架构中DPP指令的src1必须为vector寄存器（VGPR），这一限制导致编译器在需要两个标量输入的shuffle操作中必须额外插入V_MOV_B32搬运指令。RDNA 3.5的改动减少了这类不必要的指令，提高了代码密度和执行效率。

3.3.2 Scheduling

RDNA 3的调度体系延续了GCN/RDNA系列基于Hardware Scheduler的SIMT执行模型，但针对双发射和更高时钟频率进行了多处调整。调度决策发生在两个层次：CU内部的Wave Scheduler负责cycle-by-cycle的指令选择和发射；MES（Micro Engine Scheduler）负责跨队列的优先级划分和CU资源分配。两者结合形成了RDNA 3从宏观队列管理到微观指令发射的完整调度链路。

Hardware Scheduler与Wavefront管理

RDNA 3的Hardware Scheduler在每个CU内维护驻留wavefront的就绪队列（wavefront的下一条指令满足所有依赖且operand就绪）和等待队列（wavefront因memory access、texture sample、barrier或显式wait而阻塞）。Scheduler每个cycle从就绪队列中选取一至多个wavefront的指令进行发射。

Occupancy Control策略：为降低双发射下的调度复杂度，RDNA 3采取了相对保守的occupancy上限，每个SIMD的驻留wavefront数量从前代的最多20个降至约16个（具体数值因SKU和驱动版本而异，可通过COMPUTE_PGM_RSRC1寄存器中的VGPRS和SGPRS字段推算实际上限）。取舍逻辑：双发射下Scheduler每cycle需要评估的发射组合数随驻留wavefront数量超线性增长。假设N个驻留wavefront，单发射时Scheduler每cycle只需判断"哪个wavefront的下一条指令可以发射"；双发射时则需要判断"哪两个wavefront的哪两条指令可以配对发射"（或同一wavefront的两条指令是否满足VOPD条件），搜索空间约为O(N²)。限制N=16而非20，将每cycle的评估组合数从约400降至约256，简化了调度逻辑的关键路径，有利于提升时钟频率。

代价是memory-bound workload中较少的驻留wavefront可能降低latency hiding能力。RDNA 3通过以下机制补偿：(1) 增大VGPR容量至192KB/SIMD，允许单个wavefront保留更多live variable而不spill；(2) Infinity Cache 2.0的带宽提升降低了average memory access time；(3) 更大的L0/L1/L2缓存减少了VMEM请求频率。三者共同降低了对极高occupancy的依赖，使occupancy=16的latency hiding能力接近RDNA 2的occupancy=20水平。

Scheduler的工作循环：每个cycle，Scheduler执行以下步骤：(1) 扫描就绪队列中所有wavefront的scoreboard（记录未解决的依赖和waitcnt状态）；(2) 对依赖已解除的wavefront，检查operand fetch条件（VGPR Bank可用性、reuse cache状态、L0 cache readiness）；(3) 若候选指令为VOPD，额外检查第二条指令的Bank冲突和跨槽依赖；(4) 选择最优的一个或两个指令发射至SIMD0/SIMD1；(5) 若发射的指令为长延迟操作（VMEM、SMEM、DS、TEX、WMMA），将对应wavefront移至等待队列并设置wake-up条件。

Instruction Dispatch与资源分配

RDNA 3的CU设置了双指令调度端口，支持以下发射模式的组合：

• 模式A（VOPD Dual-Issue）：同一wavefront的两条独立vector指令通过VOPD格式打包，同步发射至SIMD0和SIMD1。需满足VOPD的类别/Bank/依赖约束。
• 模式B（Wave64 Interleaved）：Wave64波前的两个half-wave在相邻cycle分别进入两个SIMD。对编译器透明，限制条件最少。
• 模式C（Cross-Wavefront）：两条来自不同wavefront的vector指令分别发射至两个SIMD。这是RDNA 2已有的能力，RDNA 3保留并优化。
• 回退模式（Single-Issue）：仅发射单条指令至一个SIMD，另一SIMD空闲。这是最常见的情况，尤其在memory-bound或branch-heavy代码中。

资源分配决策受限于：VGPR allocation per wavefront（决定最大并发数，如一个使用64 VGPR的wave在192KB配置中最多驻留约6个wavefront）、LDS allocation per workgroup（影响CU mode/WGP mode选择，如workgroup需48KB LDS则只能用CU mode）、WMMA matrix unit占用（WMMA执行期间unit锁定，其他wavefront的WMMA指令需等待解锁）、以及special register（如trap handler resource）的分配。

MES（Micro Engine Scheduler）

MES是RDNA 3引入的固件级调度引擎，替代了传统架构中由Command Processor直接管理队列的方式。MES运行在每个Shader Engine内部的专用微控制器上，通过firmware实现可配置的队列管理和资源分配策略。

核心机制：

• Pipe Priority：MES为不同管道（graphics pipe、compute pipe、DMA pipe、可能存在的AI inference pipe）分配优先级权重。高优先级管道的wavefront在CU的Hardware Scheduler就绪队列中获得更高的调度优先级。优先级设置由驱动通过CP_PIPE_PRIORITY寄存器配置，可在运行时每帧调整。
• CU Reservation：驱动可以为特定任务类型预留固定数量的CU。例如，在VR应用中可为time-warp任务预留4个CU，确保其不被主渲染任务的wavefront抢占；在异步计算场景中可为AI推理任务预留8个CU。预留的CU对其他管道不可见，只有指定管道的wavefront可以分配至这些CU。

MES的介入位置在Command Processor之后、Shader Engine之前：CP解析命令缓冲区（Command Buffer）→ 提取Draw Call和Dispatch Call → 提交至MES → MES根据当前优先级配置和CU reservation映射，将命令分配至各SE的Queue Manager → Queue Manager将wavefront分发给目标CU的Hardware Scheduler。

MES与Hardware Scheduler的分工：MES负责粗粒度的队列管理和资源划分（响应时间在ms-μs量级，处理Draw Call级别的调度决策），Hardware Scheduler负责细粒度的cycle-by-cycle指令发射。这种分层设计让队列策略可以通过firmware更新迭代，无需修改硬件调度逻辑。

S_DELAY_ALU 的作用机制

S_DELAY_ALU的插入策略由编译器在指令调度（instruction scheduling）pass中决定。编译器维护一个latency table，包含RDNA 3上各类指令的精确延迟：

编译器遍历依赖图（dependency graph），在producer-consumer路径长度超过consumer所在wavefront的调度slot时，在producer后插入S_DELAY_ALU。例如，若指令A（FP32 ADD，latency 4 cycle）的结果被指令B（FP32 MUL）使用，但编译器在当前调度位置将B安排在A发射后2 cycle，则需在A后插入S_DELAY_ALU 2以避免Scheduler过早发射B。

在Wave Scheduler中的实现：S_DELAY_ALU被解码时不产生实际的执行操作，仅在Scheduler的per-wavefront状态寄存器中设置一个延迟计数器。计数器非零期间，该wavefront的调度优先级被临时降低（移至就绪队列尾部），Scheduler转而评估其他wavefront。计数器归零后，wavefront恢复正常优先级。这一过程不引入pipeline bubble或stall，仅改变调度顺序。

前端/着色器核心频率解耦

RDNA 3引入了Front-End与Shader-Core的频率解耦设计。Front-End（Command Processor、图形调度器、Geometry Engine、TES/GS固定功能、MES）运行在较高频率（约2.5GHz），而Shader Core（CU阵列，包括VALU/SALU/SIMD/WMMA/RA）运行在略低频率（约2.3GHz）。设计动机源于两个子系统的不同特征：Front-End以控制逻辑为主（状态机、队列管理、命令解析），控制逻辑的功耗与频率近似线性关系，提频收益直接；Shader Core以算术运算为主，大量并行单元在略低频下仍能通过IPC提升（dual-issue）补偿频率差距，同时降低动态功耗（动态功耗与频率×电压²成正比，稍降频率可稍降电压，功耗下降更快）。

这一解耦对调度路径的影响：CP和MES在高频下能更快地解析和分发命令 → Queue Manager的填充速率提升 → CU的Hardware Scheduler更不容易出现任务饥饿（starvation） → 整体occupancy稳定性改善。尤其在Multi-Draw Indirect场景中，高频Front-End配合MDIA硬件能在GPU侧快速解析大量DrawIndirect参数，不需要CPU逐条提交。

功耗管理与SE独立控制

RDNA 3支持最多6个Shader Engine的独立时钟/电压控制（per-SE DVFS）。Scheduler通过load detection算法持续监测各SE的利用率（活跃CU数、发射率、memory stall率），在partial load场景下动态调整：若某SE的利用率低于阈值，Scheduler可将其clock frequency降低或完全gated（关闭时钟），仅保留必要的state保持电路。当新的workload到达时，SE在微秒级内恢复至全速。

这一机制对MES的CU reservation策略有直接影响：MES在分配wavefront时会查询各SE的power state，优先将workload分配给处于active state的SE，避免唤醒处于低功耗状态的SE（除非所有active SE都已满载）。调度路径中的延迟因此增加了一个维度：不仅考虑CU资源和优先级，还需考虑SE的功耗状态转换时间。

3.3.3 Execution Unit

RDNA 3的CU执行单元配置在RDNA 2基础上沿三个方向扩展：向量ALU双发射（Dual-Issue SIMD）、矩阵运算单元集成（WMMA Accelerator）、以及光线追踪加速器升级（Ray Accelerator 2）。以下逐一分析其微架构机制、数据路径、约束条件和实际利用率边界。

双发射SIMD架构

RDNA 2的每个CU包含两个SIMD32单元，但每个cycle只能为单个wavefront发射一条vector指令（另一SIMD可执行来自不同wavefront的指令）。RDNA 3保留了两个SIMD32的物理结构，通过增强的Instruction Dispatch逻辑和operand delivery network，使单个wavefront能同时利用两个SIMD。

Wave32模式下的VOPD执行流程：编译器将两条独立的vector指令打包为VOPD → Fetch单元读取64-bit VOPD指令 → Decode后分发至CU的两个SIMD执行 → Operand Fetch阶段从VGPR Bank读取两对源操作数（需满足寄存器约束，详见下方Bank限制说明）→ 两条指令在两个SIMD中并行执行 → 结果分别写回各自的VGPR目的地址。约束不满足时回退为单发射模式。

具体的uop到SIMD的物理映射、operand collector的路由策略和半槽失败行为属于AMD未公开的微架构实现细节，不应从ISA约束外推到pipeline级 [待确认]。

Wave64模式下的数据路径：Wave64波前在硬件层面被拆分为Wave32-A（lane 0-31）和Wave32-B（lane 32-63）。Cycle N：Wave32-A的指令进入SIMD0的operand fetch → cycle N+1：Wave32-B的同一指令进入SIMD1的operand fetch，同时Wave32-A的下一条指令（若就绪）进入SIMD0。这种流水线式的交替调度使得两个SIMD在steady state下均保持忙碌，理论throughput等同于两个独立Wave32波前分别使用两个SIMD。Wave64模式的优势在于不需要编译器进行VOPD打包，Bank冲突的概率也因两个half-wave操作相同寄存器而降低。

实际利用率约束：双发射的理论峰值（256 FP32 FLOP/CU/cycle，即128 FMA/cycle）需同时满足以下条件：(1) 编译器能发掘足够的ILP（VOPD打包率≥50%或workload使用Wave64）；(2) VGPR Bank分配无冲突（4个Bank的read/write port不竞争）；(3) 无跨指令RAW依赖（dependency chain length≤1）；(4) Operand delivery bandwidth充足（每cycle从VGPR file读取4个source operands + 写入2个destination operands）；(5) L0 cache hit rate足够高（VMEM stall会导致SIMD空闲）。在真实游戏负载中，这些条件同时满足的比例有限。以典型的pixel shader为例：texture sample指令（长延迟）后通常跟随若干ALU指令处理采样结果，texture sample本身不能双发射，且后续的ALU指令因依赖sample结果而需等待，导致大量cycle中只有单个SIMD有就绪指令。实测中RDNA 3的典型FP32 utilization率为峰值的40%-70%，与RDNA 2的30%-50%相比有所改善，但距离理论峰值仍有明显差距。

WMMA Accelerator的微架构实现

RDNA 3每个CU集成2个矩阵运算单元（Matrix Unit，MU），每个MU可视为一个专用的64-wide MAC阵列，专门处理WMMA类指令。微架构数据路径：

1. 指令发射与仲裁：Wave Scheduler维护一个MU状态表（2个entry，记录每个MU的busy/idle状态和当前执行的WMMA指令类型）。当遇到WMMA指令时，Scheduler查询状态表 → 若有空闲MU，发射指令并标记MU为busy → 若无空闲MU，指令stall直至MU解锁。注意：不同wavefront的WMMA指令可以time-share MU，但同一时刻一个MU只能执行一条WMMA。
2. 操作数加载：MU从VGPR file或LDS读取源矩阵A和B的tile数据（16×16=256元素，在Wave32模式下每个lane提供8个元素）。操作数加载通过CU内部的crossbar network完成，可能与其他vector指令的operand fetch竞争bandwidth。若源数据在LDS中，通过LDS read port（每cycle 64B bandwidth）分多cycle加载；若在VGPR中，直接从register file的4个Bank并行读取。
3. 矩阵乘加执行：MU内部的64-wide MAC阵列在32 cycle内完成16×16×16 GEMM。微架构上，这可以看作一个8×8的systolic array或broadcast-based MAC grid：A tile的行被broadcast至各row，B tile的列被broadcast至各column，每个MAC单元计算一个outer product并累加。Partial sum通过forwarding network在MAC单元间传递，不需要写回VGPR。
4. Accumulator与结果回写：16×16结果矩阵C以fragment形式分布在Wave32的32个lane中，每个lane保存16个C元素（16×16/32=8，实际fragment size取决于WMMA指令的sub-type）。Accumulator数据在WMMA执行期间保存在MU内部的register file中（不占用VGPR），执行完成后通过writeback bus写回VGPR。

对VGPR pressure的影响：WMMA指令的输出fragment写回VGPR后，后续指令如需访问非本lane保存的C元素，需要通过V_PERM_B32或LDS交换进行shuffle。这增加了VGPR traffic和额外的ALU cycle。编译器在register allocation阶段需要考虑WMMA的fragment layout，尽量减少cross-lane访问。

每CU仅2个MU的规格决定了WMMA throughput的上限：一次WMMA指令（v_wmma_f32_16x16x16_f16）占用一个MU约32 cycle，因此2个MU的peak throughput为每32 cycle完成2条WMMA = 每cycle 1/16条WMMA。每条WMMA处理16×16×16=4096个MAC操作，因此每CU每cycle的peak为4096/16=256 MAC ops/MU，两MU合计512 MAC ops/cycle（FP16）。换算为FLOPs：512 MAC ops × 2（MAC = multiply + add）= 1024 FLOPs/cycle。此前表述的512 FLOPs/CU/cycle（FP16）基于 conservative counting（仅计multiply），实际峰值取决于FLOP的定义方式。

第二代光线追踪加速器（Ray Accelerator 2）

RDNA 3每个CU继续配备1个Ray Accelerator，为第二代设计。相比RDNA 2的RA，第二代的关键改进包括：

• 遍历流水线优化：RDNA 3维持BVH4的每cycle处理宽度（4个bounding box intersection tests），但通过改进的intersection pipeline和更深的ray queue提升了有效throughput。RA内部的box/triangle test管线在RDNA 2基础上做了微架构改良，降低了单个intersection的latency，允许更多ray在BVH中交错穿行。RDNA 4引入的BVH8（每cycle 8个box tests）和每cycle 2个triangle tests属于第三代RT Core特性，不在RDNA 3范围内。
• Ray Flags硬件过滤：DXR 1.1的Ray Flags（如cull back-facing triangles、accept first hit and end search、skip procedural primitives等）由RA硬件在intersection test阶段处理，辅助Shader-driven的遍历循环。数据路径：光线packet（包含origin、direction、tmax、Ray Flags）随Shader遍历指令进入RA → RA执行box/triangle intersection时依据Flags过滤结果（如CULL_BACK_FACING模式下back-facing hit被丢弃不写回VGPR）→ 遍历循环的控制流仍由Shader管理（如ACCEPT_FIRST_HIT触发后由Shader决定是否终止遍历），但硬件accelerator减少了返回Shader的intermediate hit数量和branch divergence。
• Inline Raytracing改进：RDNA 2已支持inline raytracing（在任意shader阶段通过TraceRayInline/rayquery直接发起光线遍历，不通过独立的ray tracing pipeline state object）。RDNA 3降低了inline ray query的launch latency（从发出query到RA开始遍历的cycle数减少），并增加了concurrent inline ray slots（同时处理的inline ray数量上限）。contact shadows、ambient occlusion、reflection等需要少量短光线的效果因此更适合在pixel shader中直接inline调用，避免了RT pipeline state的setup overhead。
• Ray Queue深度：硬件同时跟踪的in-flight ray数量从RDNA 2推测的约16条增至RDNA 3推测的约24条（增加50%）[具体数值未由AMD官方确认]，允许更多ray在BVH中并行穿行，提高了memory-level parallelism（多条ray交错访问BVH的不同节点，更好地利用cache bandwidth）。

数据路径（第二代RA）：Ray origin/direction（VGPR或inline ray descriptor）→ 可选的WMMA/ALU预处理（如ray transformation）→ RA接收ray packet并分配ray slot → 从L0/L1/L2/Infinity Cache层次读取BVH节点（box nodes和triangle nodes）→ RA硬件加速box intersection（AABB-ray test）和triangle intersection（Möller-Trumbore或类似算法）→ traversal stack管理（记录待访问的子节点地址，存储在RA内部的ray stack memory中）→ intersection结果（t、primitive ID、instance ID、barycentric coordinates、hit kind）写回VGPR → Shader根据结果控制是否继续遍历。注意：遍历控制流由Shader管理，RA不独立执行BVH traversal循环。

面积与定位：RDNA 3未增加每CU RA的数量（仍为1个/CU），Navi 31共96 CU因此共有96个RA。光追性能提升来源于单元内微架构改良（更深的queue、Flags过滤、更低的intersection latency）和CU总数增加（96 vs 80）。每RA的面积开销控制在较小范围内，AMD维持"以小面积换光追增益"的设计策略。NVIDIA RT Core采用更重度硬件化的traversal pipeline（独立调度、独立存储层次、专用 intersection unit），per-CU面积占比明显高于RDNA的RA；AMD则在CU内集成轻量级intersection accelerator，由Shader主导遍历控制流，以较低的面积代价提供适中的光追加速。两种策略在traversal模型上的差异（硬件traversal vs shader-based traversal）是理解其面积/性能trade-off的关键。

RDNA 3.5的执行单元微调

RDNA 3.5未改变CU的SIMD数量（2×SIMD32/CU）、WMMA unit数量（2 MU/CU）、或RA数量（1 RA/CU），但做了以下面向APU低功耗场景的微调：

• 纹理采样率优化：通过改进Tex Unit的filtering pipeline，使部分高频使用的双线性/trilinear过滤操作可以在每cycle处理两组像素采样（2 samples/cycle vs RDNA 3的1 sample/cycle for certain filter modes）。这提高了纹理管线的effective throughput，对 fill-rate-bound 的移动端游戏有直接收益。
• 标量FPU集成：如前所述，新增标量浮点ALU，直接降低了对VALU的依赖。在APU的有限CU数量下，这一改动释放的VALU cycle比例更为突出。
• 功耗门控：更激进的fine-grained clock gating，在texture unit、WMMA matrix unit、RA等模块空闲时快速关闭时钟（clock gated）， wakeup latency控制在数个cycle内。对于mobile workload中常见的bursty渲染模式（一帧内GPU活跃时间仅占30%-50%），精细门控能有效降低平均功耗。

3.3.4 Register File

RDNA 3的寄存器文件设计围绕一个核心矛盾：双发射SIMD在peak时需求同时读取4个vector source operands和写入2个vector destination operands（两个SIMD各需2 read + 1 write），但register file的大容量与高带宽在物理实现上存在张力：更多的port和更大的capacity意味着更复杂的routing、更高的动态功耗和更长的access latency。

VGPR容量与Bank架构

RDNA 3将每个SIMD32的VGPR文件容量从RDNA 2的128KB增至192KB。192KB按32-bit register计算约为49152个vector registers per SIMD。单个WGP（2 CU × 2 SIMD/CU = 4 SIMD）拥有768KB VGPR资源。

物理组织：192KB VGPR文件划分为4个单端口Bank，每Bank 48KB。每个Bank有一个read port和一个write port，每个cycle可服务一个read或一个write请求。4个Bank理论上可同时服务4个read请求（每Bank一个），可支撑VOPD dual-issue的operand fetch需求（2条指令 × 2 source operands = 4 reads）。但实际VOPD合法性还需满足更细粒度的寄存器配对约束（exact pairing rule），Bank冲突只是其中一层必要条件：即使操作数分布在不同Bank，ISA编码层面的寄存器编号约束仍可能阻止打包。

Operand reuse cache：每个SIMD配备一个small fully-associative cache（具体容量未公开，推测为16-32 entry），缓存近期使用的operand values。当instruction的source operand tag命中reuse cache时，直接从cache读取而不访问VGPR Bank，释放了Bank port给其他operand使用。Reuse cache的替换策略由硬件启发式决定（LRU或类似），RDNA 3.5通过S_SINGLEUSE_VDST允许编译器干预这一策略。

192KB容量的调度影响：一个使用48 VGPR的wavefront在128KB配置中每个SIMD最多驻留约8个wavefront（考虑allocation granularity和hardware reserved registers），在192KB配置中可驻留约12个，occupancy提升50%。更高的occupancy意味着更多的ready wavefront可供Scheduler在latency event时切换，提高了pipeline utilization。代价是更大的register file意味着更长的word line和bit line，增加了access latency和leakage power。RDNA 3通过维持较高的时钟频率（缩短cycle time）和优化的Bank segmentation来缓解latency问题。

SGPR、LDS与其他资源

RDNA 3保持独立的Scalar Register File（SGPR）设计，每CU的SGPR总量推测与RDNA 2相近或略有增加 [待确认具体数值]。标量路径在RDNA 3中为整数ALU（RDNA 3.5新增FP32 ALU），SGPR用于存储地址、常量、branch condition等标量数据。SGPR file的容量直接决定了每CU可同时驻留的wavefront数量（因为每个wavefront需要固定的SGPR allocation），也影响着复杂control flow（nested loops、multiple branches）的执行效率。

LDS（Local Data Share）：RDNA 3每CU提供64KB LDS（两个CU组成WGP时共128KB），组织为32 bank，每bank 2KB，每cycle可服务32B read或write。LDS的latency远低于global memory（约10-20 cycle vs 100-500 cycle），是wavefront间快速数据交换的主要媒介。RDNA 3新增了一条LDS优化指令（具体助记符未公开），用于加速特定遍历模式如linked list traversal，将原需多条指令（load next pointer → compare → branch → load data → repeat）的操作压缩为单条硬件指令， reportedly减少约50条动态指令开销并降低L0 bus traffic [推测]。

WGP mode与CU mode的LDS组织：WGP mode下两个CU的LDS物理合并为128KB统一池，bank数增至64，允许workgroup内的所有wavefront共享完整LDS空间，适合需要大量线程间共享数据的计算任务（如2D FFT tile处理、矩阵transpose的corner turning）。CU mode下每个CU独立使用64KB LDS，bank数为32，适合图形渲染中LDS需求较小（如32KB以下）但需要更多并发wavefront的场景。模式切换由驱动根据workgroup的LDS需求量和kernel特征自动完成。

RDNA 3.5的可变寄存器配置

LLVM patch和驱动代码显示RDNA 3.5存在两个主要变体：

• gfx1151（Strix Halo）：高端移动APU SKU，每SIMD 192KB VGPR，与Navi 31的高端RDNA 3配置一致。面向较高功耗预算（35-54W TDP）的笔记本/小型桌面，追求极致图形性能和并发能力。
• gfx1150（Strix Point）：标准移动APU SKU，每SIMD 128KB VGPR，与RDNA 2（Navi 21）同级。面向低功耗设备（15-28W TDP），如轻薄本、掌机、平板电脑，通过缩减register file深度节省芯片面积和静态功耗。

可变配置的执行模型影响：gfx1150在VGPR-heavy workload（如复杂光追shader、WMMA-intensive AI inference、大量使用register的compute kernel）中occupancy上限低于gfx1151。例如，一个使用64 VGPR的wavefront在gfx1151中每个SIMD可驻留约12个wavefront，在gfx1150中仅约8个，occupancy差距约33%。这直接影响latency hiding能力：在memory-bound场景中，gfx1150可能需要更积极的编译器优化（如register spilling to LDS、loop unrolling控制）来维持可接受的性能。

gfx1150的面积和功耗收益：128KB vs 192KB的register file面积缩减约30%（SRAM面积与容量近似线性），对应的bit line长度缩短降低了access energy per read/write。在长时间运行的移动设备中，SRAM的静态漏电（leakage current）占总功耗的可观比例，减小register file可直接降低idle power。这一取舍反映了AMD在移动APU上的设计哲学：峰值性能的妥协换取续航和散热可行性的提升。

3.3.5 Memory Subsystem

RDNA 3的内存子系统升级包含两个层面：片上缓存层级扩展（L0/L1/L2）和片外缓存/显存架构重构（Infinity Cache 2.0 + Chiplet MCD）。两者服务于同一个目标，即为双发射ALU和更多并发CU提供匹配的数据供给带宽，但各自的trade-off不同：片上缓存扩展主要解决bandwidth和latency问题，Chiplet重构主要解决面积和成本问题。

片上缓存层级扩展

L0向量缓存（Vector L0，每CU）：16KB → 32KB，32-way set associative，line size 64B。容量翻倍的动机：双发射SIMD每cycle可能产生2倍于RDNA 2的memory request rate（两个SIMD同时发出load/store），更大的L0能容纳更多active wavefront的工作集，降低L0 miss导致的VMEM latency暴露。Chips and Cheese的测试显示RDNA 3的标量缓存load-to-use latency约15.4ns（vs RDNA 2的17.4ns），延迟不增反降的部分原因是RDNA 3较高的时钟频率（2.5GHz+ vs 2.3GHz）缩短了绝对时间，另一部分原因可能是L0 controller的时序优化。这组 15.4 ns / 17.4 ns 出自标量缓存（16KB、4-way）的 load-to-use 测试，其文章同样将这一优势部分归因于 RDNA 3 更高的时钟；向量侧测试则显示 L0 向量缓存在容量翻倍至 32KB 的同时延迟同样低于 RDNA 2，两侧趋势一致。

L0扩容的副作用：32-way associative意味着每个set有32个cache line contender，tag compare逻辑需要并行比较32个tag，动态功耗和area相较于16-way或8-way设计有所增加。但对于hit latency敏感的L0（每cycle可能被访问2次，dual-issue下），set associative度的提高降低了conflict miss的概率，对effective bandwidth的正向贡献大于功耗代价。

L1缓存（每Shader Array）：128KB → 256KB，16-way associative。RDNA 3的CU数量上限从80增至96，且每CU的理论ALU throughput翻倍，意味着整个Shader Array的aggregate memory request rate可能达到RDNA 2的2-3倍。L1作为各CU共享的"第二道缓冲"，需要同步扩展容量和带宽以避免成为bottleneck。L1 read bandwidth从RDNA 2的约128B/cycle提升至约256B/cycle（推测值，基于容量翻倍和架构对称性），以匹配上行（L0→L1的aggregate traffic）和下行（L1→L2的请求带宽）。

L1的latency特征：Chips and Cheese测试显示RDNA 3的L1 hit latency在容量翻倍的情况下略有改善，表明AMD在L1的tag array、data array和arbiter设计上做了access path优化。更大的L1对texture sampling和buffer load密集型shader有直接收益：shader读取的纹理数据和uniform buffer有更高概率驻留在L1，减少了对L2和Infinity Cache的请求频率。

L2缓存（全GPU共享）：4MB → 6MB。L2位于GCD芯片上，是所有Shader Engine、Infinity Fabric接口（连接MCD）和可能存在的PCIe interface的共享枢纽。容量增加50%直接提高了L2 cache hit rate在4-6MB working set size区间的表现。在Chiplet架构中，L2还承担了额外的"traffic shaping"功能：更多的L2 hit意味着更少的跨die Infinity Fabric request，从而降低average memory latency和interconnect power。

L2的latency：尽管容量增加，RDNA 3的L2 hit latency较RDNA 2有所改善，推测得益于5nm工艺带来的更高时钟频率和优化后的L2 controller pipeline。6MB L2可以缓存大量shader constant、batch command data、以及中小型texture atlas，使这些频繁访问的数据不需要跨越Infinity Fabric到达MCD。

Infinity Cache 2.0与Chiplet内存架构

RDNA 3的Infinity Cache从RDNA 2单片128MB（Navi 21，7nm工艺）变为分布在6个MCD上的96MB（Navi 31，每MCD 16MB）。总显存位宽从256-bit增至384-bit（6 × 64-bit GDDR6控制器）。

容量从128MB减至96MB的动机：(1) 384-bit GDDR6在20Gbps速率下提供960GB/s的原始显存带宽（vs 256-bit的512GB/s），显存带宽的增加降低了对Infinity Cache容量的依赖，部分原先必须缓存的数据现在可以直接从显存获取而不明显影响性能。(2) Chiplet分割下每MCD 37.5mm²的die面积（6nm工艺）容纳16MB SRAM已是密度极限，若保持128MB需要8个MCD，增加封装复杂度、基板面积和成本。

带宽变化：GCD与6个MCD之间通过Infinity Fabric die-to-die interconnect连接，AMD宣称总互连带宽5.3TB/s（双向合计）。在纯读模式下，6个MCD可以并行响应请求，Infinity Cache的aggregate bandwidth较RDNA 2提升约1.8倍。带宽提升的幅度低于理论值（6 MCD vs 1 monolithic die的port数比例），可能受限于Infinity Fabric的仲裁开销和MCD内部的SRAM access parallelism。Chips and Cheese 的纯读带宽测试是这个 1.8 倍数字的出处：其测试未能达到理论上限（该媒体估算纯读模式理论可提升 2.7 倍），但确认 Infinity Cache 聚合带宽相对 RDNA 2 提升约 1.8 倍，并特别指出这一结果是在 Infinity Cache 物理上已移到独立 chiplet 的前提下取得的；同一组测试还记录了容量从 128MB 降至 96MB 且延迟上升的回退，其判断与系列一致，更大的片上 L2 会截流更多访问，实际触及 Infinity Cache 的频率随之下降。

延迟变化：单片128MB Infinity Cache在RDNA 2上的访问路径为CU → L2 → Infinity Cache（同一die内），延迟约80ns。RDNA 3的访问路径为CU → L2 → Infinity Fabric request → MCD receive → MCD SRAM access → Infinity Fabric response → L2 → data return，增加了die-to-die traversal的两跳延迟（request和response各一跳）。Chips and Cheese测得RDNA 3的Infinity Cache hit latency约100ns，较RDNA 2增加约25%。

Infinity Cache 2.0的trade-off在不同workload中表现不同：

• L2-friendly workload（working set < 6MB）：几乎不受Infinity Cache变化影响，数据在L2命中，不需要访问L3。这是最常见的游戏场景（shader constants、small textures、framebuffer tiles）。
• Medium working set（6MB - 96MB）：Infinity Cache 2.0的带宽优势显现，更高的aggregate bandwidth弥补了部分延迟增加。384-bit GDDR6作为后备带宽也比RDNA 2的256-bit更充裕。
• Large working set（> 96MB）：数据溢出到GDDR6显存，RDNA 3的显存带宽优势（960 vs 512 GB/s）使这一区间表现优于RDNA 2。
• Corner case（working set恰好80-96MB，频繁访问）：RDNA 2的128MB Infinity Cache可以完全容纳，RDNA 3的96MB则产生cache miss需访问GDDR6，这是RDNA 3可能弱于RDNA 2的少数场景。

DLC Hint与缓存控制

DLC（Device-Level Cache）hint允许软件标记特定内存访问绕过Infinity Cache。适用场景的识别标准：数据访问模式为streaming（sequential or strided access，无temporal locality），例如视频解码输出帧、texture streaming的mip level加载、compute shader的大规模中间结果写入。Streaming数据若放入Infinity Cache会占据line空间但不会被复用，同时增加了一跳跃迁延迟和cache replacement的management overhead。

数据路径：VMEM/SMEM请求在address packet中设置DLC bit → L2 controller识别DLC标记 → 对于read请求，直接从GDDR6读取数据而不在Infinity Cache中分配line；对于write请求，数据直接从L2 writeback至GDDR6，不经过Infinity Cache的write-allocate逻辑。这等价于GPU层面的non-cacheable access。

DLC hint对effective bandwidth的影响：在texture streaming场景中，大量一次性纹理数据若绕过Infinity Cache，释放了96MB缓存空间给更有复用价值的数据（如常驻texture atlas、shader constant buffer），提高了Infinity Cache的有效利用率。在video decode场景中，decoded frame直接写入GDDR6 frame buffer，不需要在cache中停留，减少了cache pollution。

DLC的局限：编译器或驱动需要准确识别streaming pattern才能有效使用DLC。错误地标记非streaming数据为DLC会导致不必要的GDDR6访问（绕过可能hit的Infinity Cache），反而降低性能。目前DLC hint的暴露方式有限（Linux驱动中的DISCARDABLE标志），尚未成为主流图形API的标准feature [推测]。

RDNA 3.5的内存优化策略

RDNA 3.5应用于APU，无Infinity Cache，末级缓存为2-3MB L2（因SKU而异）。内存接口为LPDDR5/5X（四通道128-bit，峰值带宽约100-150GB/s），远低于独立GPU的GDDR6带宽。RDNA 3.5的内存优化方向从"增加缓存容量"转向"提高带宽利用率"：

• 增强数据压缩：改进颜色缓冲（color buffer）、深度缓冲（depth buffer）、纹理数据的压缩算法，降低effective bandwidth需求。RDNA 3.5的lossless compression ratio推测较RDNA 3有小幅提升 [推测]。
• LPDDR访问模式优化：针对LPDDR5的burst transfer特性（BL=16，每burst传输256B），memory controller将小的scatter-gather请求合并为符合burst alignment的访问，提高row buffer hit rate和bus utilization。
• 批处理技术：Primitive Batch Processing将零碎的图元处理请求在GPU前端打包，减少CPU-GPU通信频次。配合MDIA硬件，大量小Draw Call的参数直接在GPU侧读取和处理，降低了per-draw的memory traffic。
• 缓存配置调整：RDNA 3.5每个Shader Array配备256KB L1（与RDNA 3一致），全GPU L2 2-3MB。在CU数量较少（8-16 CU）的APU中，这一缓存配置相对宽裕，但需要更充分的利用率来弥补无L3的劣势。

3.3.6 Function Feature

RDNA 3和RDNA 3.5的图形与计算功能特性建立在前述微架构改进之上。以下按功能域分析，每个功能点关联到底层硬件机制，避免脱离微架构的功能罗列。

第二代光线追踪

RDNA 3的第二代Ray Accelerator配合ISA层面的Ray Flags支持和遍历算法改进，实现了DXR 1.1的完整功能集。RDNA 3的RT模型为shader-based traversal with hardware intersection acceleration：Shader代码控制BVH遍历循环（如while-anyhit-continue），RA负责加速单个节点的box/triangle intersection test。

遍历throughput优化（vs RDNA 2的RA）：RDNA 3维持BVH4的硬件intersection宽度（每cycle 4个box tests），通过改进的内部pipeline效率、更深的ray queue（从约16条增至约24条并发ray）和Flags过滤来降低有效traversal time。BVH8（每cycle 8个box tests）和每cycle 2个triangle tests属于后续RDNA 4的第三代RT Core特性，不应归入RDNA 3指标。

Ray Flags硬件过滤的开发者视角：在DXR中设置RAY_FLAG_CULL_BACK_FACING_TRIANGLES后，RA硬件在triangle intersection阶段自动剔除背向三角形，将filtered结果返回Shader；Shader仍控制遍历循环，但可在更少instruction下完成相同culling逻辑。数据路径：ray packet携带Flags → RA在intersection test时依据Flags过滤hit → 过滤后的结果写回VGPR → Shader根据结果决定是否继续遍历。这减少了branch divergence和intermediate hit处理开销。

ACCEPT_FIRST_HIT_AND_END_SEARCH用于shadow ray和ambient occlusion ray：这些ray类型只需知道"是否被遮挡"而非"最近的hit point在哪里"，设置此Flag后RA在intersection阶段即返回first hit信息，Shader可据此终止遍历循环。在fully occluded场景中，这一优化可将traversal iteration减半。

Inline Raytracing的改进：RDNA 3降低了TraceRayInline/rayquery::Proceed的launch-to-first-intersection latency，使短光线效果（contact shadow距离<1 m、screen-space AO的secondary rays）更适合直接在pixel shader中inline调用。相比完整的RTPSO（Ray Tracing Pipeline State Object）dispatch，inline raytrace避免了pipeline state切换和shader table解析的overhead，但每个inline ray query占用VGPR资源（存储ray descriptor和intersection state），过量使用会降低occupancy。RDNA 3增加了concurrent inline ray slots（从约16增至约24）[具体数值未由AMD官方确认]，缓解了这一约束。

光追性能的绝对定位：Navi 31（96 CU × 1 RA/CU × 4 box tests/cycle × 2.3GHz）的peak box intersection rate约0.88 trillion tests/s [待确认]。NVIDIA RTX 4090（第三代RT Core，128 CU-equivalent × ~4× per-CU intersection throughput vs RDNA 3 × 2.5GHz）的peak约为RDNA 3的4-6×。RDNA 3的光追性能满足DXR在4K下的基本实时需求，但在最复杂场景（fully ray traced global illumination with multiple bounces）中仍需配合denoising和hybrid rendering技术。

硬件Primitive Culling

RDNA 2通过NGG（Next-Gen Geometry）阶段的Primitive Shader在CU上执行图元剔除：CU运行特殊的primitive shader kernel，判断每个三角形是否在视锥内、是否背面朝向、是否小于pixel size，决定是否丢弃。RDNA 3将剔除逻辑下沉至固定功能硬件电路。

数据路径变化：RDNA 2中，primitive数据（顶点位置、索引）从LDS/GMEM加载至VGPR → Primitive Shader在VALU上执行culling算法（视锥测试、背面测试、小三角形剔除）→ 结果写回 → surviving primitives继续下游管线。这一过程消耗VGPR allocation（culling shader需要数十个VGPR）、ALU cycle（每个primitive需要数十条指令）、以及对应的功耗。

RDNA 3中，Primitive Culling Unit（PCU）作为固定功能模块插入在NGG之后、rasterizer之前：primitive数据从NGG输出后直接进入PCU → PCU在专用硬件上并行执行视锥/背面/微小三角形测试（throughput较RDNA 2的软件方案明显提升）→ 结果直接控制primitive的pass/drop信号 → surviving primitives直接进入rasterizer。PCU不占用CU资源，不消耗VGPR，不发出ALU指令。

几何/NGG/剔除路径的代际优化：RDNA 3的硬件化culling相较RDNA 2的软件Primitive Shader方案在能效比上有明显改善，固定功能单元以远小于CU阵列的功耗完成相同剔除工作。这一功耗reduction使得在默认情况下全局启用细粒度culling成为可能，无需开发者手动权衡culling收益与功耗代价。具体的功耗数值取决于SKU和工作负载，公开资料中缺乏可比的精确测量。

Multi-Draw Indirect Accelerator（MDIA）

MDIA是RDNA 3在前端引入的硬件单元，用于在GPU侧直接解析Multi-Draw Indirect参数buffer。数据路径：CPU通过一次API调用提交包含N个draw参数的indirect buffer地址 → MDIA从GPU内存读取该buffer → 解析每个draw entry的vertexCount、instanceCount、firstVertex、firstInstance → 直接生成为内部的Draw Call命令 → 分发至Queue Manager → 进入常规CU调度流程。

MDIA消除了CPU端逐条处理DrawIndirect参数的overhead。在传统流程中，Multi-Draw Indirect虽然减少了API call数量，但驱动仍需在CPU端验证参数、计算GPU command packet、逐条写入GPU-visible command buffer。MDIA将这一系列操作完全硬件化，CPU只需提交一次buffer地址和count。AMD测试显示在大量小物体的Vulkan场景中，MDIA可降低CPU利用率超过50%，等效提升约10%-20%的帧率（当原场景CPU-bound时）。

MDIA对引擎开发者的影响：可以更大胆地使用GPU-driven rendering技术，将culling、LOD选择、draw参数生成全部在GPU compute shader中完成，结果写入indirect buffer，再由MDIA直接消费。这一模式（GPU culling + MDIA dispatch）已成为现代引擎的标准实践，RDNA 3的MDIA使其效率进一步提升。

栅格化与像素输出优化

RDNA 3的rasterizer每cycle三角形吞吐从4个增至6个（+50%），pixel fill rate（ROP output）提升至192 pixels/clock。这些改进与texture unit的throughput增强（RDNA 3.5进一步在部分filter mode下实现2 samples/cycle）配合，使像素管线各环节趋于均衡。

"Random Order Opaque Exports"：ROP在处理纯opaque pixel batch时，跳过reorder buffer的排序环节。传统ROP需要对可能混合透明和不透明pixel的batch维护排序状态以保证correct blending order；对于已知全opaque的batch（绝大多数游戏场景），排序是不必要的overhead。RDNA 3检测渲染目标的blend state：若blend disabled且所有写入pixel为opaque，ROP使用simplified output path直接写出，降低了延迟和buffer容量需求。

VRS（Variable Rate Shading）Tier 2：RDNA 3完整支持DX12 Ultimate的VRS Tier 2，允许对不同屏幕区域以不同shading rate着色（如1×1 for screen center，2×2 for periphery/motion blur regions）。VRS在RDNA 3上的overhead较低，得益于大容量Infinity Cache对shading rate texture的缓存和MDIA对VRS tile dispatch的快速处理。

通用计算与AI功能

传统着色与GPGPU计算：RDNA 3的FP32 peak为96 CU × 256 FP32 FLOP/CU/cycle × 2.5GHz ≈ 61.4 TFLOPS（RX 7900 XTX官方标称值，对应双发射满效率）。FP16/INT16继续以2×速率执行（每CU每cycle 128个FP16 FMA，整卡peak约122 TFLOPS）。FP64比率约为FP32的1/16（~3.8 TFLOPs），与RDNA 2一致，反映了游戏和常规计算对双精度需求有限的定位。

RDNA 3在GPGPU场景中的改进主要来自更大的VGPR和扩展的缓存层级：复杂compute kernel（如CFD simulation、particle system）可以使用更多寄存器而不spill到LDS/内存，减少了spill-related traffic；更大的L1/L2提高了memory-bound kernel的effective bandwidth。Chips and Cheese的micro-benchmark显示RDNA 3在并行访存场景的latency和bandwidth较RDNA 2有系统性改善。

AI推理：WMMA使RDNA 3具备了低精度矩阵运算的硬件加速。RX 7900 XTX的FP16矩阵peak约113 TFLOPs（96 CU × 512 FLOPs/CU/cycle × 2.3GHz），约为RDNA 2（依赖VALU逐元素模拟矩阵乘法）的4倍以上。在Stable Diffusion等生成式AI workload中，RDNA 3的推理速度远超RDNA 2（如RX 7900 XTX约26 images/min vs RX 6950 XT约6.6 images/min）。

RDNA 3的WMMA与NVIDIA Ada Tensor Core的规模差距：RTX 4090的Tensor Core peak（FP16 with sparsity）约为RDNA 3的5-8×，但这一差距在inference workload中并不完全转化为实际性能差距，因为许多inference模型受限于memory bandwidth而非compute peak，且RDNA 3的Infinity Cache 2.0和GDDR6带宽在memory-bound场景中表现良好。

XDNA 2 NPU（同SoC异构AI IP）：RDNA 3.5 APU所在的SoC中集成了独立的XDNA 2 AI加速器（来自Xilinx收购的NPU IP），它与RDNA 3.5 GPU是SoC层面的独立功能块，并非RDNA CU/WGP的一部分。XDNA 2提供独立于GPU的矩阵运算能力，定位与GPU WMMA互补：GPU WMMA处理高带宽的像素级操作（如convolution、pixel-wise network layer），NPU处理更高层次的推理任务（如object detection、scene understanding、super-resolution的global network）。两者协同使AI workload可以分层（GPU负责throughput-intensive pixel操作，NPU负责latency-sensitive decision操作），整体AI能效高于纯GPU方案。XDNA/XDNA2作为独立IP block，其架构描述应归入APU异构计算章节，不应与RDNA GPU微架构混淆。

RDNA 3.5的标量FPU对AI shader的间接增益：AI inference中的control flow（loop over network layers、conditional execution based on input size）和scalar computation（activation function的parameter lookup、batch normalization的mean/variance calculation）可由标量FPU处理，释放了VALU资源和VGPR allocation。在APU的有限CU数量下，这一资源释放的比例效应更为突出。

3.3.7 小结

RDNA 3的微架构演进可以沿三条主线归纳，每条主线包含具体的机制改进、约束条件和工程取舍。

执行单元与指令吞吐：通过Dual-Issue SIMD将每CU的理论vector throughput从128 FP32 FLOP/cycle提升至256 FP32 FLOP/cycle（即64 FP32 FMA/cycle提升至128 FP32 FMA/cycle）。VOPD指令格式在Wave32模式下提供了打包双发射的能力，但受限于指令类别（仅简单ALU）、寄存器Bank冲突（4 Bank约束）和数据依赖（无RAW/WAR/WAW），编译器实际发掘的VOPD比例通常低于30%。Wave64模式的交替发射机制限制更少（对编译器透明，几乎不受Bank冲突影响），成为API默认路径，其利用率高于VOPD模式。WMMA矩阵指令以每CU 2个matrix unit的规格为消费级GPU首次提供了硬件化AI加速，采用Wave级协作（整个wavefront完成16×16 GEMM）和fragment accumulator存储模型（结果压缩分布在各lane的VGPR中）。WMMA约32 cycle的latency和对matrix unit的锁定需求，对Scheduler的指令交错能力和VGPR分配提出了新的约束。每CU仅2个matrix unit的规格（vs CDNA的4个MFMA）反映了消费级GPU在面积预算下对游戏与AI的优先级权衡。

内存子系统与带宽：L0向量缓存从16KB增至32KB/CU，L1从128KB增至256KB/Shader Array，L2从4MB增至6MB，三级缓存的容量和带宽同步扩展以匹配ALU throughput的增加。Infinity Cache 2.0从RDNA 2单片128MB变为6×16MB的Chiplet分布式结构（每MCD一片），总容量减少25%但理论aggregate bandwidth提升约1.8倍，跨die访问延迟增加约20%（~80ns → ~100ns）。容量减少的动机包括384-bit GDDR6显存带宽增加降低了对Cache容量的依赖，以及Chiplet封装下每MCD的面积限制。DLC hint提供了软件控制的缓存绕过能力，适用于streaming data场景（video decode、texture streaming），防止一次性数据污染有限的96MB缓存空间。RDNA 3.5在无Infinity Cache的APU场景中，通过增强数据压缩、LPDDR访问模式优化和批处理技术来弥补带宽不足。

调度体系与功耗管理：MES引入固件级队列管理和CU reservation机制，使多任务（图形、计算、AI推理、VR time-warp）的调度从纯硬件策略转向firmware+ hardware协同。Pipe Priority允许不同管道按权重竞争CU资源，CU Reservation允许为关键任务预留固定数量的CU。S_DELAY_ALU作为compiler-assisted scheduling hint，帮助Wave Scheduler在高频运行下避免依赖导致的pipeline stall，其hint语义调整wavefront优先级而非强制阻塞，不引入额外功耗开销。前端/Shader-Core频率解耦（Front-End ~2.5GHz，Shader Core ~2.3GHz）使控制逻辑密集的front-end获得更高的Draw Call处理能力，同时让算术密集的shader core在略低频下通过并行度补偿。SE独立功耗控制（per-SE DVFS和clock gating）使partial load场景下的idle power显著降低。

RDNA 3.5的APU适配：在保持RDNA 3宏观架构的前提下，RDNA 3.5针对移动场景引入以下微调：标量FPU（释放VGPR压力，减少VALU依赖）、S_SINGLEUSE_VDST（降低operand reuse cache的Bank冲突概率）、可变的VGPR配置（gfx1150: 128KB/SIMD for 15-28W SKU；gfx1151: 192KB/SIMD for 35-54W SKU）、以及更激进的fine-grained clock gating。这些改动的目标不是在移动设备上复制桌面GPU的峰值性能，而是在有限的功耗包络（15W-54W）和内存带宽（LPDDR5/5X，100-150GB/s）内最大化effective performance per watt。

设计取舍与边界条件：RDNA 3没有在每个维度上都选择最大配置。VOPD的严格限制反映了ISA编码位宽和编译器复杂度之间的平衡，更宽松的打包条件需要更宽的指令格式或更复杂的硬件调度，二者都会增加面积和功耗。每CU仅2个matrix unit（vs CDNA的4个）反映了面积预算下游戏性能与AI加速的优先级排序，RDNA 3的首要定位仍是游戏GPU，AI加速是增量特性而非核心设计目标。Infinity Cache容量缩减（128→96MB）反映了大缓存与Chiplet封装成本的工程折中，在GDDR6带宽已明显增加的前提下，Cache容量的轻微让步换取了封装可行性和成本可控性。这些取舍使得RDNA 3在5nm GCD + 6nm MCD工艺下，以相对可控的芯片面积（Navi 31 GCD约300mm² + 6×MCD各37.5mm²）和功耗（TBP 355W for RX 7900 XTX），实现了相比RDNA 2 7nm单片设计（Navi 21约520mm²）约1.5-1.8倍的实际性能提升。RDNA 3 在设计层面反映的一个规律是：微架构改进的收益不仅来自单个机制的峰值提升，更来自多条数据通路（ALU、Cache、Schedule、Memory）的协同匹配，任何一端的过度超前若不能得到其他端的支持，只会转化为闲置的 peak capability 而非实际的 performance gain。

3.4 RDNA 4

AMD RDNA 4架构作为RDNA系列的第四代迭代，在微架构层面针对前代三个可量化的硬件瓶颈进行了定向修补：计算着色器中VGPR pressure导致的wave occupancy塌陷（尤以光线追踪等时变寄存器需求场景为典型）、跨wavefront内存伪依赖对并行度的限制、以及标量管线上冗余向量计算对SIMD发射槽的挤占。

在宏观设计层面，RDNA 3时代引入的Chiplet设计在RDNA 4上回调至monolithic方案。RDNA 3高端型号（RX 7900 XTX）采用1个GCD（Graphics Compute Die）与6个MCD（Memory Cache Die）通过Infinity Fabric互连，GCD到远端MCD的物理距离带来约50~80ns的额外访问延迟，且延迟随距离线性增加。RDNA 4（RX 9070系列）将图形计算和内存缓存重新整合至单硅片，消除了跨die链路的延迟不确定性，代价是单片面积约束下Infinity Cache容量从96MB缩减至64MB。这一取舍在光追等延迟敏感型负载下收益更为明显，因为BVH遍历的随机访问模式对延迟波动极度敏感，跨die延迟抖动直接转化为遍历步数的stall周期。

微架构层面的关键变更包括：动态VGPR分配机制允许wavefront在运行时弹性调整寄存器占用（公开ISA限定为wave32 compute shader，graphics shader与wave64不支持），使compute shader中"低VGPR阶段大量并行 / 高VGPR阶段精准扩容"的时变需求得以匹配；标量ALU扩展至浮点运算域（RDNA 3.5在APU上首次引入，RDNA 4带入独立GPU），将原本需在SIMD阵列上重复64 lane的公共浮点计算迁移至标量管线，标量FP32加/乘延迟4周期对比向量路径5周期；片上缓存层级移除L1 Data Cache（由read/coalescing buffer替代）并将L2容量在高端SKU上扩容至8MB，简化一致性协议的同时以更大L2吸收全部CU的并发访存压力；第三代RT Accelerator引入双Intersection Engine、BVH8支持和OBB（定向包围盒，硬件/驱动内部BVH优化）；第二代矩阵核心扩展至FP8/BF8并引入2:4结构化稀疏加速；Wait Counter拆分为S_WAIT_LOADCNT/S_WAIT_SAMPLECNT/S_WAIT_STORECNT/S_WAIT_DSCNT/S_WAIT_KMCNT/S_WAIT_EXPCNT/S_WAIT_BVHCNT独立追踪；新增SCOPE和Temporal Hint内存访问提示机制。这些变更均建立在前代已有的技术基座上：双发射SIMD（RDNA 3）、标量浮点初步试水（RDNA 3.5 APU）、ISA hint指令框架（RDNA 3）、分离屏障原语探索（RDNA 3.5），在RDNA 4中延续并深化。

3.4.1 ISA

RDNA 4在GFX11（RDNA 3）指令编码框架上保持向后兼容，针对新的硬件功能在三个维度扩展指令集：动态资源管理指令集、内存同步指令拆分、低精度矩阵运算数据类型。AMD延续了以独立hint指令替代指令内嵌控制位的策略，通过少量专用指令扩展实现类似NVIDIA大量内嵌标志位的效果，在功能扩展与代码密度之间维持平衡。

从执行模型视角，RDNA 4维持统一的数据通路：Command Processor解析命令缓冲并生成draw/dispatch packet → Wavefront Dispatch将work分解为wavefront并分配至CU/WGP → CU内Wave Scheduler管理驻留wavefront的就绪/等待状态 → Instruction Dispatch发射指令至Scalar/Vector Operand路径 → 操作数读取SGPR/VGPR/LDS/Cache → 执行单元（SALU/VALU/VMEM/SMEM/DS/RT Accelerator/Matrix Core） → Writeback写回结果 → Dependency Clear唤醒等待依赖的指令。RDNA 4的ISA扩展主要影响Wave Scheduler到Operand路径这一区段：动态VGPR改变了操作数可用的边界条件，S_BARRIER_SIGNAL/WAIT改变了同步依赖的解除时机，细粒度wait counter改变了memory dependency的追踪精度。

动态VGPR分配指令与寄存器提示

RDNA 4最核心的ISA扩展是动态VGPR（Vector General-Purpose Register）分配模式及相关指令。传统模式下，每个wavefront在着色器启动时即静态分配固定数量的VGPR，该数量由编译器根据着色器代码中最大live register需求推导，直接决定单个CU的wave occupancy上限。例如，一个需要128个VGPR的wave在192KB VGPR文件的SIMD上理论最多驻留约15个wave（192KB ÷ 128 VGPR × 64 byte/VGPR），若其实际执行过程中仅在密集计算阶段使用全部128个VGPR而在数据预取阶段仅需48个，则预取阶段大量寄存器空间被闲置，并发潜力浪费。

RDNA 4允许wave在运行过程中按需增减寄存器，实现运行时弹性调配，但公开ISA将其限定为wave32 compute shader，graphics shader与wave64不支持。驱动可将compute shader以动态VGPR模式启动，此时硬件通过chip-wide全局控制寄存器SQ_DYN_VGPR统一设定每个SIMD的occupancy target与VGPR block size（16或32 VGPR，chip-wide配置），不再由静态VGPR使用量推导。wave起初只占用一个最小寄存器块，后续当需要更多寄存器时，使用新引入的标量指令s_alloc_vgpr来申请扩容。该指令携带一个目标VGPR编号参数，以block粒度分配寄存器：wave最多可申请8个块（含初始占用的1块），从而最高支持每wave 256个VGPR（与RDNA 4 ISA的寻址上限一致）。s_alloc_vgpr的执行结果通过标量条件码SCC返回：成功分配则SCC置位，若因寄存器耗尽未能满足则SCC清零，着色器需检查SCC以决定是否重试或切换至低VGPR路径。

死锁避免机制是动态VGPR模式的关键支撑。如果多个wave同时申请额外VGPR且公共池资源不足，存在所有wave均因等待VGPR而停滞的循环等待风险。AMD在硬件中实现了预留策略：硬件保留足够VGPR让至少一个wave始终能达到最大allocation。在典型的max=8块、initial=1块配置下，即每SIMD预留7个VGPR块供动态分配，在竞争条件下保证至少有一个wavefront能够成功获取预留块并将其VGPR提升至上限运行，其余wavefront暂缓争夺。当该wavefront完成高寄存器占用段并释放资源后，预留块腾出，再允许下一个wave使用。这一机制确保系统"缓慢但不停滞"地推进，但无法避免多个wave同时需要最大allocation的极端死锁场景。应用层在高VGPR段引入跨wave的循环依赖时仍可能破坏死锁避免的假设，但在正常compute shader代码中此风险可控且极少出现。

这一机制使wave可在高需求代码段暂时获取更多寄存器，又在离开该段后释放，从而动态权衡寄存器利用率与并发数。动态VGPR模式从ISA角度改变了"高寄存器占用导致低并发"的固定约束。以compute shader中的光线追踪遍历（如通过GPUOpen RT库实现的compute-based traversal）为例：遍历阶段wave仅用极少VGPR即可大量并行，而在命中着色需要密集寄存器时再暂时提升VGPR配额，从硬件层面实现了弹性寄存器管理，使寄存器时变工作负载的CU occupancy接近各阶段的最优配置。

与NVIDIA Hopper架构的对比：NVIDIA在Hopper架构中引入了类似的动态寄存器指令（PTX中的setmaxnreg），但二者有本质区别。NVIDIA并无专门的动态模式，线程组仍以固定VGPR数启动，只是在运行中通过setmaxnreg要求整个Warp subgroup同步调整寄存器上限，相当于一种受控的寄存器窗口交换。这种机制需Warp内线程协同，自由度不及AMD方案，后者允许不同wave各自异步地申请寄存器、处在不同的寄存器使用阶段（类似于"错相"执行），而NVIDIA的方法更像在限定情形下交换寄存器窗口。由于NVIDIA硬件的DXR光追实现采用阶段间独立线程调度模型（各光追阶段作为独立kernel dispatch），不存在单个warp贯穿所有光追阶段的问题，因此NVIDIA架构对动态VGPR的需求紧迫性低于AMD。AMD的动态VGPR是针对其compute shader执行模型的定向设计，用于满足wave内寄存器需求的时变特性。

动态VGPR增加了调度复杂度，硬件调度器需实时追踪每个wavefront的VGPR占用边界，公共池的分配/回收需原子操作保证；s_alloc_vgpr指令本身占用标量ALU发射槽；申请失败时的retry循环消耗指令带宽。这些开销在VGPR需求时变的compute shader中可被occupancy提升的收益覆盖，但在VGPR需求稳定的工作负载中引入不必要的管理成本。

除了动态VGPR，RDNA 4还延续并扩展了RDNA 3.5中引入的一次性寄存器使用提示S_SINGLEUSE_VDST。编译器可在两条指令间插入该标量hint指令，告知硬件下一条向量指令的dest操作数属于"一次性使用"，即该值仅被后继一条指令消费，无需在寄存器操作数缓存（Operand Cache）中保留。

RDNA架构的VGPR文件被划分为多个物理bank（典型配置4个只读bank），硬件利用Operand Cache缓存近期使用的操作数以减少bank conflict对双指令发射的阻碍。但对那些仅被后继指令消耗一次的结果值，缓存反而徒劳占用带宽。S_SINGLEUSE_VDST提示使硬件跳过对这些值的缓存分配，减轻VGPR bank冲突对双指令发射的阻碍。

与NVIDIA每条指令自带操作数重用标志位的精细控制不同，AMD以独立hint指令形式批量标记全部dest操作数是否重用。策略的trade-off在于：NVIDIA的方式逐指令粒度更细但需为每条指令增加编码位宽（64-128位指令），AMD的方式仅在需要时插入额外32位指令，典型指令长度保持32或64位，等效仅在插入提示指令时增加到96-128位，并未整体拉大代码密度。这体现出AMD在ISA设计上平衡代码密度与提示自由度的思路：通过少量专用指令扩展，实现类似NVIDIA大量内嵌标志位的效果。

指令格式扩展与分离屏障

RDNA 4的指令格式总体沿袭GFX11框架：32位为基础指令长度，支持64位VOPD（双向量操作打包）及附加32位立即数。新增指令包括动态VGPR模式下的S_ALLOC_VGPR（标量形式）、分离屏障指令、BVH8栈操作原语DS_BVH_STACK_PUSH8_POP1_RTN_B32、DS_BVH_STACK_PUSH8_POP2_RTN_B64（及PUSH4_POP1变体）、矩阵转置加载GLOBAL_LOAD_TR_B128、以及WMMA FP8/BF8系列intrinsic。RDNA 4 ISA确认的BVH image指令族包括IMAGE_BVH_INTERSECT_RAY、IMAGE_BVH64_INTERSECT_RAY、IMAGE_BVH_DUAL_INTERSECT_RAY、IMAGE_BVH8_INTERSECT_RAY，分别对应BVH4/QBVH、dual QBVH与BVH8遍历模式。

传统GPU中的S_BARRIER实现workgroup内全wave同步：wave执行到屏障时等待所有同组wave抵达，期间先到达的wave空转。RDNA 4将屏障拆分成S_BARRIER_SIGNAL和S_BARRIER_WAIT两条指令。wave到达同步点时先发出_SIGNAL信号然后继续执行独立于同步数据生产的计算，直到确实需要消费来自伙伴wave的数据时再执行_WAIT等待。硬件为每个屏障分配独立ID，SIGNAL指令将ID写入硬件屏障寄存器并立即返回，对应的WAIT轮询该寄存器检测所有wave是否已发信号。

这样可在不破坏同步语义的前提下减少wave闲置等待，实现更加精细的内存同步控制。在不均衡workload下，快wave可利用_SIGNAL到_WAIT之间的间隙完成额外工作。这一特性对着色器的编程模型透明，由编译器/驱动在支持的着色器模型下自动以分离屏障替代传统屏障指令。

数据类型与矩阵运算指令扩展

面对AI工作负载的需求，RDNA 4在ISA层面增加了对更低精度数据类型的支持。RDNA 3的WMMA指令集支持FP16/BF16以及INT8/INT4矩阵运算。RDNA 4进一步扩充，新增对FP8（E4M3）和BF8（E5M2）两种8位浮点格式的支持，其矩阵运算指令与原有WMMA格式一脉相承，仅数据类型与计算规模不同。硬件矩阵单元针对低精度做了数据路径扩宽，FP8/BF8的dense吞吐可达到与INT8同等的每周期运算数；结合2:4结构化稀疏加速，等效吞吐可再提升一倍。

注：RDNA 4支持2:4结构化稀疏，在兼容稀疏模式的权重矩阵上，上述dense FMA吞吐可等效翻倍。FMA口径以单条乘累加指令计2次运算（mul+add）。

RDNA 4矩阵ISA还增加了转置载入指令GLOBAL_LOAD_TR_B128，允许在从内存加载矩阵块时自动完成行列转置，减少手动重排数据的代码量。WMMA计算要求特定存储格式（如A矩阵行主序、B矩阵列主序），转置加载消除了预处理矩阵布局的额外pass，硬件一次加载即完成格式对齐。

结构化稀疏加速方面，RDNA 4引入了2:4稀疏权重模式：权重矩阵每4个元素中固定2个为零，以2位掩码编码零值位置，矩阵单元在执行乘累加时跳过零值运算，等效将运算吞吐倍增。编译器可通过_gfx12后缀的WMMA intrinsic暴露稀疏模式。

3.4.2 Scheduling

RDNA 4架构的调度子系统面临的核心复杂度来源于ISA层面引入的两项变更：动态VGPR分配使寄存器资源从静态绑定变为运行时竞争资源，跨wavefront乱序内存返回打破了传统WGP级别的全局访存顺序假设。调度器需在维持双发射SIMD吞吐的同时协调这些动态行为。

Hardware Scheduler与Instruction Dispatch

RDNA 4的Hardware Scheduler是CU内部的控制中枢，负责管理CU内所有驻留的wavefront，并决定在每个时钟周期向SIMD和标量单元发射（dispatch）哪条wavefront的哪条指令。每个CU可驻留的wavefront数量上限与RDNA 3相近（第三方逆向测得每SIMD约16个Wave32 slot，每CU上限约20个Wave32，具体数值因SKU和动态VGPR模式而异），但动态VGPR模式下实际驻留数随运行时VGPR分配波动：一个初始以低VGPR配置运行的CU可能容纳接近上限的wave数，随着各wave逐步申请VGPR，有效occupancy动态收敛至资源均衡点。

Instruction Dispatch单元在每个周期内，从所有处于"就绪"状态的wavefront中选择指令进行发射。RDNA 4延续RDNA 3的双发射架构，允许同时发射一条向量指令和一条标量指令，或一条VOPD（双向量操作）指令。调度器通过检查wavefront的状态（是否等待数据、是否等待资源）和指令的依赖关系（data hazard），来做出发射决策。

动态VGPR分配触发时的调度行为：s_alloc_vgpr在标量ALU上执行，成功后硬件更新wavefront的VGPR有效范围，失败时SCC=0由shader处理（机制详见 3.4.1 节）。

Resource Allocation与Occupancy Control

动态VGPR模式将寄存器资源从静态绑定转为运行时弹性管理（指令语义与死锁避免机制见 3.4.1 节），调度器据此获得了更大的occupancy调控空间。

调度器的核心职责之一是latency hiding。当一个wavefront因等待VGPR分配结果或内存数据而停滞时，Hardware Scheduler会迅速切换到其他处于就绪状态的wavefront，以确保执行单元持续工作。这种机制将传统的内存延迟隐藏（通过多wavefront并行）扩展到了寄存器资源竞争的场景。

Latency Hiding与提示指令协同

RDNA 4的调度器利用ISA提供的指令级提示来增强latency hiding能力：

• S_DELAY_ALU：编译器插入此指令以提示调度器后续指令存在长延迟依赖，从而允许调度器在不破坏依赖关系的前提下，更自由地安排指令发射时机，或切换到其他wavefront。
• S_BARRIER_SIGNAL/WAIT：分离的屏障指令允许调度器在wavefront发出_SIGNAL后，继续发射该wavefront中不依赖同步结果的独立指令，直到遇到_WAIT才阻塞。这减少了workgroup级同步对发射率的干扰，提高了wavefront内部的指令级并行度。
• S_SINGLEUSE_VDST：调度器结合Operand Cache策略，跳过一次性值的缓存分配，降低VGPR bank conflict概率，提高双发射成功率。

跨Wavefront乱序内存返回的调度影响

RDNA 4引入的跨wavefront乱序内存返回机制要求调度器具备按wave独立的返回追踪能力。此前架构中，同一WGP内不同wavefront的内存返回在实际硬件调度中可能受全局顺序约束，即使某wave的请求已命中缓存准备好，也可能因等待其他wave的未完成的miss请求而在cache return scheduling层面被阻塞。RDNA 4中，各wavefront拥有独立的返回追踪队列，调度器在数据到达时即可将该wave标记为就绪并参与下一周期的发射仲裁，无需关心其他wave的访存进度。这类似于CPU多线程间内存访问无顺序保证的情况。这一改变优化的是 cache return scheduling 层面的 head-of-line blocking，不等价于放松 per-wave 的程序顺序或取代 wait counter 的依赖追踪功能，单 wavefront 内的请求次序仍由编译器通过细粒度 wait counter 保障。

这一改变使调度器的发射窗口扩大：在光追等延迟差异大的场景中，"快"wavefront（cache hit为主）不再被"慢"wavefront（cache miss为主）拖累，调度器有更大概率在每个周期找到就绪指令。硬件实现上需更复杂的总线仲裁和每wave缓冲管理，但收益在于CU有效utilization的提升和更充分的延迟隐藏。

3.4.3 Execution Unit

RDNA 4的CU执行层保持前代总体布局：每个CU含2个SIMD32向量单元 + 1个标量ALU + 专用加速器（RT Accelerator、Matrix Core）。未进一步加宽通用ALU宽度（如从双发射增至三发射），而是通过提升单元利用率和扩展专用加速器吞吐来推进性能。

标量ALU的浮点化与延迟优化

标量FPU的指令集、执行路径和APU场景收益见 3.3.1 节（RDNA 3.5 ISA）。RDNA 4将该机制从APU带入独立GPU，该节补充执行单元视角的差异点。

RDNA 4中标量FP32加法/乘法延迟为4个时钟周期，向量FP32加/乘则为5个周期，标量路径比向量路径快1个周期，进一步降低了uniform浮点计算的依赖链长度。

标量FPU的引入增加了少量硬件面积和静态功耗开销，但在先进工艺支撑下这个投入相对于收益可控。AMD未在标量ALU中实现复杂标量运算（如倒数平方根rcp/sqrt、三角函数sin/cos等），但提供了特殊的向量计算结果回写标量指令（如V_S_RSQ_F32计算倒数平方根并将结果写回SGPR），以避免为这些低频操作去堆叠标量专用硬件。编译器自动完成标量/向量路径的选择：常量浮点表达式→标量ALU，需要lane级并行的计算→向量SIMD，超越函数→向量回写标量指令。

SIMD向量管线与调度提示

RDNA 4的SIMD32向量单元继承RDNA 3的双发射架构：每个CU含2套SIMD单元，每周期最多可同时发出两条向量指令（或一条双发射VOPD指令）至两个SIMD并行执行，理论峰值每CU 128 FP32 FLOPs/周期（单发射baseline），在可双发射/VOPD的理想条件下可达256 FP32 FLOPs/周期（dual-issue peak）。该核心架构在RDNA 4中没有进一步加宽，AMD并未像过去GCN时代那样叠加更多并行lane（例如VLIW模式），也未增加每SIMD的wavefront slot数（第三方逆向测得约16个Wave32 slot/SIMD），而是依托软件调度和硬件hint将现有双发射单元的效率逼近峰值。

标量浮点和屏障分离等特性减轻SIMD的冗余工作和空转等待，使RDNA 4在相同SIMD硬件规模上获得更高的有效发射率。具体而言，标量ALU浮点化将原本需在VALU上执行的常量浮点计算（每指令64 lane重复计算）迁移至SALU（单计算服务全wave），等效释放了VALU发射槽；S_BARRIER_SIGNAL/WAIT减少了传统S_BARRIER导致的全wave空转周期，使SIMD在同步间隙中仍有其他就绪wavefront可调度；S_DELAY_ALU帮助调度器更准确地规避长延迟依赖链中的流水线气泡。三者的综合效果是在不增加ALU物理数量的前提下提高有效utilization。

RDNA 3时代引入的编译器提示S_DELAY_ALU在本代继续发挥作用：当编译器判断某条向量指令存在长延迟依赖时（如访问慢速资源），会提前插入该标量指令以提示硬件适当延后后续指令的发射。RDNA 4的调度器结合S_DELAY_ALU和S_BARRIER_SIGNAL/WAIT等提示，可以更智能地在每个wavefront内部优化指令流水，减少因data hazard和同步而浪费的周期。

第三代RT Accelerator

光线追踪性能在RDNA 4中通过第三代RT Accelerator（AMD内部代号"RT IP 3.1"）实现。每个CU内的固定功能Ray Accelerator单元经过重新设计：

Intersection Engine：RDNA 2/3时代每个RA只有1个交叉引擎，每周期最多处理4个AABB的光线相交测试或1个三角形相交测试；RDNA 4的RA含2个引擎，每周期合计可执行8个盒体测试或2个三角测试。交叉吞吐率翻倍需要上层算法的数据结构配合才能充分填满。

BVH8：加速结构从BVH4（每节点4个子节点）升级至BVH8（每节点8个子节点）。8宽BVH在每级遍历中提供更多并行可测试的子盒，充分填满两个交叉引擎的工作队列。树的分支因子扩大后遍历深度显著降低，更"扁平"的BVH树减少了到达叶子三角形所需的步骤，转化为更少的内存访问和更低的总延迟。

OBB（Oriented Bounding Box）：传统BVH使用AABB（Axis-Aligned Bounding Box），盒子边界与全局坐标轴平行。当场景几何并非轴对齐时，AABB会包络出相当大比例的空洞区域，物体旋转后，其外接轴对齐矩形往往包含大量空隙。光线射入这些空隙会误判需要进入节点，造成额外的无效遍历开销。OBB允许每个BVH节点的子节点共享一个最佳旋转坐标系，使包围盒随几何姿态倾斜，紧贴实际形状。

RDNA 4通过在每个BVH节点存储一个指向预定义旋转矩阵表的索引来实现OBB，每个矩阵将三个坐标轴按6比特编码引用一个二级表中的具体值，总共提供104种离散取向供选择。这种紧凑编码避免了为每个节点显式存储9个浮点数（3×3矩阵）的高昂代价，只需很小的元数据即可令所有子盒共享同一旋转系。OBB使包围盒体积平均缩减，降低了BVH总体节点数量和深度，进一步减少内存占用和遍历成本。代价是在交叉测试前需要对光线坐标进行一次矩阵变换，引入少量额外计算延迟。

AMD的软件分析表明，在Elden Ring或3DMark光追测试等场景下，RDNA 4借助OBB和其它BVH优化，可实现BVH总大小的缩减，构建时间也相应缩短。

BVH4x2双节点并行模式：为了充分利用双交叉引擎，RDNA 4还支持一种双BVH并行遍历模式。除了将每节点扩展为8宽外，硬件也允许同时取出两个独立BVH4节点一起送入两个交叉引擎测试（AMD称之为"BVH4x2"模式）。对应地，新ISA增加了IMAGE_BVH_DUAL_INTERSECT_RAY指令，可接受一对4宽节点作为输入，产出8个交叉结果并支持跨两节点的宽排序。在一些光线当前遍历路径不足8宽可测时，可将来自不同分支的节点配对，以避免交叉单元闲置。不过BVH4x2需要执行两次独立节点的访问和出栈，在缓存和LDS流量上并不如直接使用BVH8模式经济。实际应用中，驱动更倾向于构建原生BVH8以发挥最佳性能，BVH4x2作为一种兼容退路。

Pack and Sort机制：RA还增加了结果乱序缓冲来优化延迟利用率。在光线遍历过程中，不同光线因为命中了不同层级的缓存或需要取回内存数据，进展速度不一。过去RA按照提交顺序输出交叉结果，引入的结果乱序缓冲允许RA暂时跳过那些因等待内存而停滞的光线，优先让"快"的光线完成更多交叉测试。硬件对输出的交叉结果标记顺序编号，最终再按正确顺序排序写回，确保光追着色程序看到的结果顺序仍与程序次序一致。这种内部的细粒度动态调度在RA内部实现，与NVIDIA Ada架构SM级的Shader Execution Reordering（SER）不同：SER是在warp级对整个warp线程重组，而AMD的Pack & Sort是在单个RA内部对光线测试进行动态调整。它进一步提高了RA双引擎的利用率，特别是当某些光线受存储延迟影响时，不会阻塞其它光线的测试进展。

第二代AI Matrix Accelerator

为应对机器学习推理需求，RDNA 4对每个CU的Wave Matrix Multiply-Accumulate（WMMA）单元进行了系统升级。

RDNA 3中每个CU配备了2个矩阵FMA管线，执行16×16维度的矩阵乘法指令，支持FP16/BF16和INT8/INT4数据类型，理论上每CU每周期提供512个FP16或2048个INT4的FMA算力（dense，以FMA计2次运算）。在RDNA 4中，这些矩阵单元的内部并行度和数据路径宽度都有所强化：

注：RDNA 4的2:4结构化稀疏可在兼容模式下将等效吞吐再提升一倍；表格所列均为dense FMA吞吐。FMA以单条乘累加计2次运算。

这种提升来自两处：硬件算术单元的复用优化（低精度算术以更少资源实现更多并发运算）；结构化稀疏的支持。RDNA 4引入了类似NVIDIA Ampere张量核心的2:4稀疏权重加速：如果神经网络模型的权重矩阵经过2/4稀疏剪枝（即每4个数中有2个为零，且按固定位置模式存储零值掩码），矩阵单元即可跳过这些零乘运算，有效地将运算吞吐再提升一倍。结合稀疏和低精度两方面，RDNA 4在支持结构化稀疏的INT8矩阵乘法中，每CU每周期理论等效运算可高达8192 FLOP（dense情况下4096 FMA，稀疏跳过等效翻倍）。

实现这些提升并没有扩大矩阵单元的物理数量，主要通过精度换性能和跳过冗余计算来完成，对版图和功耗的影响相对温和。

在ISA层面，RDNA 4矩阵指令集相应增加了FP8/BF8支持，以及每种数据类型下稀疏矩阵乘加的指令或模式。硬件上增加了零值掩码加载和处理逻辑，保证跳过计算不影响结果正确性。

AMD还改进了矩阵运算的数据搬运效率。RDNA 4的输出fragment采用压缩存储，将矩阵分块所需的VGPR寄存器数量减半（每个Wave32的WMMA输出子矩阵所需VGPR从RDNA 3的8个降至4个），同样资源下可进行两倍规模的并行分块计算。GLOBAL_LOAD_TR_B128转置加载指令使矩阵数据在读取pass即完成行列对齐，减少显存读写和VGPR缓冲开销。这些改进对于大模型推理相当关键，因为GPU往往受限于片上高速存储，RDNA 4通过软硬件结合减小矩阵运算对寄存器和带宽的压力。

3.4.4 Register File

为了支撑更高的并发和新功能，RDNA 4对寄存器文件系统在分配机制和效率方面做了改进。尽管每个SIMD的物理VGPR容量仍为RDNA 3高端配置的192KB，但通过动态分配模式的引入，寄存器不再是固定束缚并发的瓶颈。同时，为了降低函数调用、异常处理等场景下寄存器保存/恢复的开销，AMD新增了专用的寄存器块搬运引擎（具体指令集与微架构细节在公开ISA中未完全披露，以下描述基于现有资料与合理推测）。

VGPR容量与动态分配机制

RDNA 4每个SIMD的VGPR总容量为192KB，折合最大VGPR编号0~255。在Wave32模式下每个VGPR宽1024-bit（32 lane × 32-bit）。静态分配下的occupancy约束逻辑与前代相同；动态VGPR模式的指令语义、块粒度与死锁避免预留策略见 3.4.1 节。以下补充寄存器文件视角的两个要点。

动态VGPR模式使硬件能够根据实际wavefront需求"按需供给"寄存器，提高寄存器利用率与吞吐率的折中效率。特别是在VGPR需求时变的compute shader中，动态模式相当于让不同阶段"借用"彼此的寄存器额度，保证了高需求时资源供应充足，低需求时不浪费资源占用，从而实现比静态分配模式下更高的整体并发。

动态VGPR也引入了新的复杂性。例如，如果多个wave同时申请额外寄存器且资源不足，就可能出现所有wave相互等待而陷入死锁，死锁避免机制正是为应对这一风险。在正常compute shader中循环等待的风险可控且极少，但应用层在高VGPR段引入跨wave循环依赖时仍可能打破机制假设。

寄存器块搬运引擎与函数调用优化

现代图形着色语言中广泛使用函数调用、闭包等抽象。以往当控制流跳转到一个需要新寄存器空间的函数（特别是独立编译的函数）时，编译器会安排一系列store指令将调用方一部分VGPR内容写出至栈空间（通常映射到LDS或显存），待函数返回后再用load指令读回。逐寄存器的spill/fill序列在深度调用或异常处理中开销尤为明显。

RDNA 4新增了寄存器块级别的spill/fill硬件加速（公开ISA未完全披露细节，以下基于现有资料与合理推断）。CU内增加的专用逻辑允许编译器使用特殊指令一次性搬运多达32个连续VGPR的spill/fill操作，相当于提供了一个"DMA式"的寄存器搬运引擎，在函数prolog/epilog中快速转储或调回大量寄存器内容，而不必逐寄存器执行冗长的读写指令序列。

更关键的是，编译器/驱动可以通过约定让调用方和被调用方协同：调用方知道哪些VGPR live，被调用函数只spill那些必要的VGPR，忽略未被使用的空闲寄存器，从而避免不必要的保存恢复。这一改进对于复杂着色器程序（例如包含多个独立编译的库函数调用）意义重大。过去shader编译器常通过内联展开函数来避免调用开销，但这会导致代码膨胀；有了快速的寄存器上下文切换能力后，可以更自由地使用函数结构而不用过分担心GPU上的性能损失。

VGPR架构优化与单次使用提示

RDNA 4保留了RDNA 3/3.5中的VGPR架构基本设计，包括多bank的VGPR文件与旁路的Operand Cache机制。每个CU内的VGPR被划分为多个bank（典型配置4个只读bank），每周期可并行读取多个操作数，但若两个读操作命中了同一bank则需顺序完成（bank conflict）。RDNA家族通过Operand Cache缓解这一问题：当某条指令的源操作数被判定在后续指令中还会复用时，硬件将其暂存于快速缓存中，下次访问直接提供而不重复访问VGPR。

RDNA 3.5引入的S_SINGLEUSE_VDST提示（如上所述）用编译器知道的信息指导硬件缓存策略。RDNA 4继续支持这一hint，并针对双发射场景对Operand Cache策略做出调整，使其在高速双发射下也能提供有效带宽。RDNA 4对VGPR的索引寻址和跨lane访问功能（如DS、DPP指令）也延续了RDNA 3.5的改进，取消了DPP指令只能一个标量源的限制，允许两个标量源操作数，为warp级register shuffle提供更大自由度。

RDNA 4依然维持每个Wave32最高可用VGPR数为256的上限。该上限在动态分配模式下变为逻辑上的可变上限（wave初始较小，可动态涨到≤256）。对比而言，Intel Xe架构每线程可用GRF寄存器数可达512个256-bit寄存器，但当前未支持动态分配；NVIDIA每SM物理寄存器容量约64KB，依赖每指令重用标志和setmaxnreg等手段手动调控。AMD RDNA 4选择了不同路径：增大物理容量+动态分配+编译器提示三管齐下，使VGPR系统既拥有一定"粗放冗余"来保证性能（大文件、硬件缓存），又具备"精耕细作"以提升效率（动态模式、提示指令）。

SCOPE / Temporal Hint 机制

RDNA 4引入了SCOPE和Temporal Hint机制，允许着色器向内存子系统提供访问模式的hint：

• SCOPE hint：指定内存访问的可见性范围，RDNA 4 ISA定义的scope名称为CU、SE、DEV、SYS四级（CU scope对应compute-unit/work-group级别，SE对应shader engine级别，DEV为设备级，SYS为系统级），帮助硬件优化缓存一致性操作的粒度。若编译器可证明某次写操作仅需对同workgroup可见，硬件可跳过全局一致性广播，减少无效化流量。
• Temporal Hint：指示数据的缓存复用策略，包括RT（reuse、期望近期复用）、NT（non-temporal、期望单次访问）、HT（high temporal、期望高频复用）、LU（last use、最后一次使用）等策略，帮助缓存控制器决定保留或驱逐该数据的优先级。对已知单次访问的大块数据标注NT可避免缓存污染；对高复用数据标注HT/LU可提升保留优先级。

这些hint不改变内存语义，只影响性能优化路径。编译器在分析访问模式后自动插入，开发者也可通过内在函数手动控制。

Wait Counter 细分

RDNA 4对wait counter机制进行了更细粒度的拆分，ISA暴露独立指令分别等待不同类别的memory operation：

• S_WAIT_LOADCNT：追踪buffer/global内存加载操作（BUFFER_LOAD、GLOBAL_LOAD等）的完成状态
• S_WAIT_SAMPLECNT：追踪纹理采样操作（IMAGE_SAMPLE等）的完成状态
• S_WAIT_STORECNT：追踪buffer/global内存存储操作的完成状态
• S_WAIT_DSCNT：追踪LDS/GDS操作（DS_READ/WRITE、DS_SWIZZLE、DS_BVH_STACK_*等）的完成状态
• S_WAIT_KMCNT：追踪scalar memory操作（S_LOAD/STORE访问常量/描述符缓存、S_BUFFER_LOAD）及kernel级操作的完成状态
• S_WAIT_EXPCNT：追踪export/export确认操作的完成状态
• S_WAIT_BVHCNT：追踪BVH相交操作（IMAGE_BVH*_INTERSECT_RAY等）的完成状态

在RDNA 3及之前架构中，vmcnt/lgkmcnt的较粗粒度导致一个常见问题：当wavefront同时存在VMEM操作（高延迟、高方差）和LDS操作（低延迟、确定性）时，S_WAITCNT等待LDS完成时可能被迫同步等待VMEM，即使VMEM数据尚未被后续指令消费。RDNA 4的独立counter允许编译器发出S_WAIT_DSCNT仅等待LDS操作完成而不阻塞VMEM流水线，释放等待间隙中的发射槽给其他就绪wavefront。从硬件实现角度，RDNA 4为每类counter维护独立的完成追踪队列，调度器根据指令编码中的counter类型选择对应的等待条件。这一变更对编译器后端可见，LLVM AMDGPU后端在RDNA 4 target下自动生成细粒度counter等待指令。旧S_WAITCNT指令保留向后兼容。Chips and Cheese 对 RDNA 4 实际着色器汇编的分析确认了这一拆分的形态：编译器可让全局内存、纹理采样与光追相交请求交错发射、分别等待；lgkmcnt 同样被拆分为面向标量内存的 kmcnt 与面向 LDS 的 dscnt，标量加载与 LDS 访问之间不再需要互相等待。

3.4.5 Memory Subsystem

RDNA 4的显存子系统做出了几项重大的架构调整，以配合翻倍的算力和全新的并发机制。在片上缓存层级上，L2缓存容量进一步扩容（高端GPU达8MB），而中间的L1数据缓存被移除，取而代之的是read/coalescing buffer。这一重大架构变化意味着L0和L2缓存承担了更多职责：L2成为唯一的中层缓存，其容量和吞吐需扩容以弥补L1的移除。Infinity Cache继续作为大容量末级缓存存在，但因回归单芯片设计后容量缩减为64MB，同时号称采用了第三代优化以提供更高的有效带宽。AMD在整个内存通路中引入了更积极的透明压缩和改进的乱序内存调度机制。

片上缓存层级调整：L1移除，L2增大

RDNA 4取消了传统的L1 Data Cache层级，代之以read/coalescing buffer作为L0与L2之间的过渡层。该buffer主要职责是将来自L0的零散读请求聚合成适合L2 bank宽度的突发传输，并提供有限的访存合并能力以减少冗余请求。L2 Cache容量在高端SKU上扩大至8MB（RDNA 3高端型号如RX 7900 XTX为6MB L2），且增加了bank并行度以吸收全部CU的并发访存压力。L2成为RDNA 4中唯一的中层缓存，承担所有CU的纹理、常量、全局内存请求的统一汇聚与分发。

这种"扁平化"两级缓存架构的trade-off如下：

• 少了一层缓存意味着缓存一致性协议维护逻辑简化，数据只需在L2和L0间来回，不存在L1与L2的冗余拷贝和一致性开销；L2的命中访问延迟相比L1 miss后访问L2的延迟更可预测，减少了延迟抖动；L2统一汇聚使跨CU的数据共享开销更低（L1通常为per-CU private，共享需走一致性协议）。
• 没有L1作为中间缓冲，L2面对并发CU请求的压力大增，必须足够大且够快，否则可能成为瓶颈。AMD通过增加L2容量和bank并行度来加强抗压性。

实测表明，RDNA 4的8MB L2在重负载场景表现出色，例如在光追这样的指针追踪负载中，大幅降低了落入Infinity Cache乃至显存的请求比例。Chips and Cheese在3DMark DXR测试中观察到RDNA 4明显减少了需要从Infinity Cache取数的数据量，这应归功于更大的L2能够容纳更多BVH节点和相关数据，不易被驱逐。

与NVIDIA策略的对比：Ampere/Ada/Blackwell架构大量提升SM片上L1/shared memory（Ada L1+shared可达164KB/SM）并把L2做得非常大（Blackwell RTX 5090为96MB L2），L2延迟介于AMD的L2和Infinity之间。NVIDIA趋向统一一个中等延迟的大L2来满足不同层次需求。AMD此前选择保持一个小而快的L2配合一个稍慢的大Cache（Infinity），RDNA 4此次的改变某种程度上靠拢了NVIDIA的"重L2"思路，更加倚重一级大缓存（L2）而减少层级。不过RDNA 4仍保留独立的Infinity Cache作为大容量末级缓存，形成L0 → read buffer → L2(8MB) → Infinity Cache(64MB) → GDDR6的四级层次，与NVIDIA的L1 → L2(大) → GDDR6三级层次仍有区别。

尽管完全取消L1 Data Cache在GPU中较为少见，但AMD此前在移动APU上已有类似探索。从性能实测来看，RDNA 4在大部分场景下并未因L1移除而拖慢，反而通过加强L2获得了更可控的缓存行为。不过可能存在一些corner case，例如高度局部但访问模式不规则的数据，过去能缓存在L1而现在直接打到L2，延迟增加1~2周期的影响有待社区进一步研究。

Infinity Cache与显存子系统

RDNA 4回归monolithic设计后，Infinity Cache以片上集成形式存在（非RDNA 3的MCD off-chiplet）。RX 9070系列配置64MB第三代Infinity Cache，容量较RX 7900 XTX的96MB缩减1/3，但因与GCD集成，访问延迟有所降低（免去跨die链路的至少几十个ns开销）。AMD宣称新一代Infinity Cache的效率提升，可能指采用了更先进的压缩和行列策略，使每字节缓存存储更有价值。

RDNA 4继续搭配GDDR6显存，旗舰SKU（RX 9070 XT）为256-bit 16GB GDDR6 @ 20 Gbps，带宽640 GB/s。这个带宽相比上一代旗舰RX 7900 XTX的960 GB/s有所下降，但AMD表示经过权衡仍足够满足需求。补偿机制包括Infinity Cache尽可能截流大量请求，以及更强的压缩算法。RDNA 4在广泛采用无损/近无损数据压缩方面有所投入，压缩技术贯穿SoC多个单元，包括显示引擎、媒体引擎和GPU核心的数据通路。片上缓存可直接存储压缩后的颜色/深度数据，尽可能延后解压，减少重复压缩-解压往返，从而明显减少内部总线和显存流量。即便在显示输出环节，RDNA 4也引入了帧缓冲压缩等手段降低多显示器空闲时的显存带宽消耗。RDNA 4至少沿用了RDNA 3的Delta Color Compression（DCC）并有所改良。

跨Wavefront乱序内存返回

RDNA 3及之前架构中，同一WGP（双CU）内的内存返回在实际硬件调度中可能受全局顺序约束：即使Wave A的读请求已命中缓存准备好，也可能因等待Wave B更早发出但尚未完成的miss请求而在cache return scheduling层面被阻塞。这种跨Wavefront的假依赖会导致性能损失，尤其在光追场景中：一个wavefront可能大量cache miss（遍历深层BVH），另一个wavefront多数cache hit，本可很快拿到数据继续执行，却因为cache return层面的顺序等待而平白停顿。

RDNA 4打破了这一限制。AMD在Hot Chips上披露，RDNA 4为不同着色器线程的访存增加了乱序完成队列，使得"后发先至"成为可能。即：如果 Wave A 稍晚发出的读请求 X 比 Wave B 先发出的请求 Y 更早拿到了数据，那么 X 可以直接返回寄存器，Wave A无需等待Wave B的Y完成。这类似于CPU多线程间内存访问无顺序保证的情况。

Chips and Cheese通过微基准测试验证了RDNA 4的此项改进：在RDNA 3上让两个Wave并行内存访问，一个完全cache miss串行依赖，另一个每循环有4个独立访问，结果观察到后者每等前者一次就只能执行4次访问，对应编译器将4个访存打包后用S_WAITCNT等待，而这个等待不光等自己的4个，还被迫等另一个Wave的miss。而在RDNA 4上，同样场景下快的Wave不再受慢Wave限制，可以持续完成更多访问，两个Wavefront各行其是。

Chips and Cheese 这组测试的设计精确地隔离了变量：慢 wave 在 1GB 数组上做依赖式指针追踪以保证全程 cache miss，快 wave 每次循环发出 4 次相互独立的访问；RDNA 3 上快 wave 的完成次数恰好是慢 wave 的 4 倍，与循环展开因子完全一致，进一步扩大展开因子则倍数同步上升，说明等待确实被另一个 wave 的未完成请求拖住。AMD 工程师 Andrew Pomianowski 在 Navi 4 Architecture Deep Dive 中对前代的约束有明确表述：RDNA 3 及更早架构对数据返回施加严格顺序，后发的请求即使数据早已就绪也不允许越过先发的请求。同一测试在 Renoir（GCN 时代）的集显上复现了相同行为，说明该约束贯穿 AMD 多代架构，并非 RDNA 独有。

从硬件实现角度推测，RDNA 4可能将原本共享的WGP访存返回队列拆分为每Wavefront私有的队列，每个队列独立追踪自己的请求次序。当返回数据准备好时，只需写入对应Wave的队列即可，不会阻塞其他队列的处理。硬件仍需保持单Wavefront内的请求次序不乱（shader依赖由编译器用细粒度wait counter保障），但不同Wavefront间则完全乱序。这种设计需要更复杂的总线仲裁和缓冲管理，但换来的好处是GPU可以像多线程CPU那样做到线程间无存储顺序保证，仅通过最终的同步或原子操作来显式控制顺序。

这一特性不同于NVIDIA Ada的SER（后者通过重新调度warp将访存模式相近的线程束聚合），AMD的是在硬件层面自动乱序返回，不需要软件介入。Nvidia自Turing架构起在SM内部分管理层级化内存返回队列，RDNA 4的加入使AMD GPU在此底层能力上获得对等支持。

为了让开发者安全利用这一特性，RDNA 4配套提供了细粒度的内存屏障（前述S_BARRIER_SIGNAL/WAIT）和全局原子/栅栏机制，使需要严格顺序的场合可以明确同步，其余则尽量并行执行。这一特性使GPU多Wavefront执行模型从"全局有序队列"演进为"各wave独立追踪"模型，在不规则内存访问场景（光追、图遍历、散列表查找）中减少"木桶效应"，让快的wavefront不被慢的拖累。

3.4.6 Function Feature

RDNA 4架构底层微架构的变更最终服务于上层图形渲染和通用计算功能。该节按渲染与计算两条路径分别梳理功能特性的演进及其与底层硬件机制的对应关系。

Graphics：光线追踪与路径追踪

RDNA 4的第三代RT Accelerator通过双Intersection Engine、BVH8和OBB三项硬件改进，使每射线的空间遍历效率在理论峰值上达到RDNA 3的2倍。这一提升的实际兑现程度取决于上层BVH构建质量和运行时遍历行为。

对开发者的直接影响在于BVH构建管线的改变：BVH8的节点宽度扩大使BVH树更扁平，到达叶节点的平均步数减少约30-40%（具体数值取决于场景几何分布），对应更少的内存访问和更低的遍历延迟。OBB节点使BVH总大小在旋转几何较多的场景中缩减约15-25%（AMD数据基于Elden Ring和3DMark光追测试场景），构建时间相应缩短，运行时内存占用降低。ISA新增的DS_BVH_STACK_PUSH8_POP1_RTN_B32、DS_BVH_STACK_PUSH8_POP2_RTN_B64指令为复杂遍历算法（如多光线打包遍历、选择性重启动遍历）提供原语支持，IMAGE_BVH_DUAL_INTERSECT_RAY支持BVH4x2双节点并行模式作为BVH8的兼容退路。

RDNA 4完整支持DXR 1.1+ API，包括光线标志（ray flags）等特性。OBB是硬件/驱动内部的BVH node压缩与intersection优化思路，并非DXR API向应用暴露的扩展。路径追踪等未来图形负载可从更紧凑的BVH构建和更新操作中获益，多光源、多反弹光线的处理通过双引擎的更高交叉吞吐获得加速。

光追性能的实际提升幅度受多种因素约束：BVH构建质量、场景几何复杂度、光线相干性、以及内存子系统的延迟特性。RDNA 4的Pack & Sort机制和跨wavefront乱序内存返回在不规则访存场景中减少了引擎闲置，但这些机制的收益与具体workload的访问模式强相关。

Graphics：传统光栅化

RDNA 4在传统光栅化管线的改进来源于三个层面的叠加：

着色器核心吞吐：FP32 ALU峰值吞吐和频率提升直接转化为像素着色、顶点着色速率的提高。标量ALU浮点化进一步释放SIMD发射槽供数据并行任务使用，在包含大量常量计算的像素着色器中可获得额外的有效吞吐。

几何处理：RDNA 4延续并优化了RDNA 3在光栅前引入的硬件三角形细粒度剔除单元，使无效三角形在更早的管线阶段被剔除，着色资源集中于有效图元。这一机制对高多边形场景（复杂角色模型、植被系统）中剔除率的提升有直接贡献。

绘制调用加速：Multi-Draw Indirect Accelerator（MDIA）允许GPU自主解析和执行一系列绘制命令，减少CPU-GPU往返。对大量小batch场景（复杂UI、粒子系统、植被渲染）中CPU侧的draw call开销有明显降低，因为GPU可以自主解析command buffer中的indirect draw序列而减少CPU干预。

像素输出效率：改进的像素合并（pixel merging）减少overdraw带来的冗余计算；Early Z测试在像素着色前剔除被遮挡片段；颜色压缩技术（Delta Color Compression）降低高分辨率下帧缓冲带宽占用。这些优化在高分辨率（4K及以上）和MSAA场景中收益更为明显，因为像素率和带宽需求随分辨率线性或超线性增长。

显示与多媒体

显示引擎方面，RDNA 4支持自适应刷新率（Adaptive-Sync）下的显存低功耗刷新（panel self-refresh），在多显示器待机场景下降低显存带宽消耗和功耗。Radeon图像锐化（Radeon Image Sharpening）主要基于驱动/后处理shader路径实现，在显示输出管线中对最终帧进行锐化过滤，无需占用3D着色器资源。

媒体引擎方面，视频编码器针对H.264、HEVC和AV1编码格式做了质量与时延优化，同等码率下画质提升，对游戏串流、视频会议等低延迟场景有利。解码端维持对主流格式的完整支持。这些媒体功能虽然不直接影响3D渲染性能，但降低了GPU在执行图形任务时因媒体任务抢占资源而产生的干扰。

Compute：矩阵与AI推理

RDNA 4第二代矩阵核心的硬件升级配合软件栈完善，使AI推理负载的可用性获得实质性提升。GPUOpen发布了RDNA 4专用的WMMA编程指南和算例，LLVM AMDGPU后端中_gfx12后缀的intrinsic暴露FP8/BF8运算和2:4稀疏模式。

输出fragment压缩存储是容易被忽视但影响可观的改进：每个Wave32的WMMA输出子矩阵所需VGPR从RDNA 3的8个降至4个，VGPR占用减半。这一变化的直接后果是：在相同VGPR预算下，矩阵分块的并行度可翻倍，大型矩阵乘法可以拆分得更细而无需担心VGPR耗尽。对于大模型推理中batch size和模型规模的上限，VGPR占用减半意味着可处理更大的中间激活张量。

结构化稀疏（2:4）与FP8/BF8的叠加在支持条件下提供理论峰值8倍于RDNA 3 FP16 dense的推理吞吐（FP8 2×数据路径扩宽 × 2×稀疏跳过 = 4×；INT8领域2×数据路径扩宽 × 2×稀疏跳过 = 4×；与RDNA 3 FP16 baseline综合对比可达8×）。AMD与HuggingFace合作提供经2:4剪枝和FP8量化的预优化模型以及更新后的推理runtime，降低了开发者利用稀疏加速的门槛。

实际推理吞吐能否达到理论峰值取决于多个约束：模型是否经过2:4结构化剪枝（非结构化稀疏无法被硬件加速）、权重矩阵尺寸是否对齐WMMA分块要求、以及显存带宽是否成为瓶颈（大batch推理中矩阵计算密度提高，但小batch中带宽限制更为突出）。

并行编程模型

RDNA 4底层调度和存储模型的改进为并行编程范式提供了新的可能性：

不规则数据访问：跨Wavefront乱序内存返回使图遍历、散列表查找等负载中不同Wavefront各尽其责，开发者无需手动同步warp的访存进度。硬件自动最大化并行度，避免了"最快线程等待最慢线程"的木桶效应。

函数调用与模块化：寄存器块搬运引擎（一次最多32个连续VGPR的spill/fill，公开ISA未完全披露细节）使CUDA/HIP代码中使用函数调用或有限递归的开销明显降低。此前编译器常通过强制内联来避免调用开销，导致代码膨胀；有了快速的寄存器上下文切换后，函数封装的可读性和模块化不必以性能为代价。

可配置同步原语：S_BARRIER_SIGNAL/WAIT分离屏障使类似CUDA cooperative groups或Vulkan subgroup操作的同步原语构建成为可能。库开发者可以在不牺牲性能的前提下实现producer-consumer、pipeline parallel等协作模式，因为SIGNAL发出后线程可继续执行独立计算，仅在需要数据时才阻塞等待。

这些改进为一些此前GPU上低效的计算模式提供了可行性，例如更通用的GPU task graph调度、依赖频繁分支和函数调用的动态执行模式等。不过，要充分利用这些优势，仍需编译器（LLVM AMDGPU后端）、驱动和运行时库的配合。AMD自RDNA 3.5起即在LLVM、ROCm等开源项目中推进对应支持，RDNA 4生命周期内这些软件组件的成熟度将决定硬件特性能否被充分挖掘。

3.4.7 小结

RDNA 4的微架构演进并非峰值算力的线性堆叠，而是针对GPU执行效率中一系列长期存在的结构性损耗进行定向修补。

动态VGPR分配通过运行时弹性调整寄存器占用，解决了inline ray tracing场景中遍历阶段低occupancy与命中阶段高VGPR需求的矛盾。配合死锁避免机制（预留7块保证至少一个wavefront能完成高VGPR段）和SCC状态反馈，使寄存器资源从编译时静态决策转化为运行时弹性调度。代价是调度复杂度的增加和申请失败时的busy-wait开销。

标量ALU浮点化（RDNA 3.5在APU首次引入，RDNA 4带入独显）将原本在SIMD阵列上重复64 lane的公共浮点计算迁移至标量管线，标量FP32延迟4周期对比向量路径5周期。SIMD发射槽释放且功耗降低，但增加了少量面积开销。复杂标量运算（rcp/sqrt/sin等）仍通过向量回写标量指令V_S_RSQ_F32等处理。

跨Wavefront乱序内存返回打破了WGP级别的全局访存顺序假依赖，通过每Wavefront私有返回队列实现"后发先至"，使快wavefront不再被慢wavefront的cache miss阻塞。这一变更使GPU多Wavefront执行模型从全局有序演进为各wave独立追踪。

L1 Data Cache移除并以read/coalescing buffer替代，L2容量翻倍至8MB，简化了缓存一致性协议，以大L2统一吸收全部CU的并发访存。某些高度局部性workload可能因此遭遇更高的首访延迟，8MB L2的bank并行度成为关键抗压因素。

第三代RT Accelerator通过双Intersection Engine（box 4→8/tri 1→2）、BVH8支持和OBB技术，使每CU光线测试吞吐翻倍。Pack & Sort机制在RA内部实现细粒度动态调度。第二代矩阵核心通过数据路径扩宽和2:4结构化稀疏支持，FP16/BF16吞吐2×、INT8/INT4吞吐2~4×，并新增FP8/BF8支持。

Wait Counter拆分为vmcnt/kmcnt/dscnt独立追踪，使编译器能精确等待特定类型内存操作完成。SCOPE和Temporal Hint机制为内存子系统提供访问模式提示，优化缓存行为和一致性操作粒度。

RDNA 4的取舍在典型游戏负载中的净收益为正，但在极端corner case中可能存在性能回退：L1移除使某些局部性极强的workload延迟增加；64MB Infinity Cache较RDNA 3的96MB缩减对大working set的覆盖能力下降；动态VGPR的管理开销在VGPR需求稳定的workload中不抵收益。这些边界条件是开发者和架构师在评估RDNA 4时需要权衡的约束。

3.5 Console

随着游戏主机进入次世代，GPU 架构的演进不再单纯沿袭 PC 显卡的路径，而是形成主机与 GPU 架构协同演进的格局。索尼与 AMD 的合作使 PlayStation 主机上的定制 GPU 满足游戏开发对性能和新特性的需求，还往往引领了 AMD 公版架构的方向。

从 PS5 所采用的 RDNA 2 架构首次将实时光线追踪引入主机，到 PS5 Pro 在中期升级中融合了下一代 GPU 技术（如 BVH8 光追加速和定制 AI 单元），再到面向未来的 PS6 (代号"Project Amethyst") 放出 Neural Arrays、Radiance Cores 等新方向，每一代主机 GPU 均成为架构技术的前置验证平台。下面从 GPU 架构工程师的视角，分析 PlayStation 5、PlayStation 5 Pro 和未来的 PlayStation 6 三代主机 GPU 的架构细节及演进脉络，重点关注这些定制架构在指令集、执行单元、内存子系统和渲染管线等 GPU-die-internal 层面的设计取舍。

该节聚焦于 GPU-die-internal 机制与 RDNA 公版架构的承接关系，涵盖 Command Processor → Wavefront Dispatch → CU/WGP → Wave Scheduler → Dependency/waitcnt → 执行单元 → SGPR/VGPR/LDS/Cache → 功能单元 → Writeback 的完整数据路径。 PS5/PS5 Pro/PS6 三代 GPU 的演进遵循统一执行模型：Command Processor → Wavefront Dispatch → CU/WGP → Wave Scheduler → Dependency/waitcnt → Scalar/Vector Operand → SGPR/VGPR/LDS/Cache → SALU/VALU/VMEM/SMEM/DS/TEX → Writeback → Dependency Clear。每一代在该路径上的特定节点做出改进：PS5 引入 RDNA 2 的 Wave32 和 Ray Accelerator；PS5 Pro 在 traversal stack 和 per-WGP SRAM 上做文章；PS6 瞄准 CU 间互联和 fixed-function traversal。

3.5.1 PlayStation 5

PlayStation 5 (PS5) 是 AMD RDNA 2 架构在游戏主机上的首次亮相，它在继承 RDNA 2 革新成果的同时，根据主机需求做出了若干取舍和平衡。RDNA 2 相较前代 GCN 架构完成范式转变，重点提升每时钟性能和能效，并引入了硬件光线追踪等新功能。对于 PS5 而言，如何在封闭平台上充分利用这些新特性、同时保持与前代开发模式的平滑过渡，是架构设计的核心约束，需在 APU 功耗/面积/成本三重限制下寻求最优解。

可变频率与热预算

PS5 的 GPU 基于 RDNA 2 架构定制，具有 36 CU和最高 2.23 GHz 的可变频率。这种 variable frequency 机制实为 APU 封装下的系统级热预算管理：GPU 频率与 CPU 活跃核心数、整机散热状态联动，由 on-die 功耗管理单元实时调控。当 CPU 负载较低时，GPU 可动态提升至更高频率；CPU 负载升高时，GPU 频率回退以维持封装总功耗。

ISA 与 Feature Set

为简化开发者迁移，PS5 GPU 基于 RDNA 2 架构定制，硬件 feature set 层面支持 Wave32、硬件光追等 RDNA 2 核心特性。ISA 与 PC 版 RDNA 2 在指令集层面高度对齐，但平台工具链、驱动栈与 PC 侧存在差异，不能直接等同于"兼容 AMD PC 图形 API 二进制"。Sony 官方公开信息主要覆盖性能目标与高层架构方向，具体 API 兼容边界以 Sony 平台文档为准。PS5 保留了 RDNA 2 的WGP (Workgroup Processor) 组织结构和双计算单元配置，每个 WGP 含2个 CU，共同调度波前执行。

执行单元与并发能力

在执行单元方面，PS5 GPU 的每个 CU 拥有64个流处理器，支持 Wave32/64 双执行模式，与 PC RDNA 2 相同。PS5 尽管采用了高达 2.23 GHz 的频率，但并没有因主频提升而牺牲并发能力：每个 CU 仍可保持最高32个并发波前 (即1024个并发线程) 的调度能力，这与 PC Radeon RX 6000 系列一致。

与 PC RDNA 2 的差异

PS5 GPU 的微架构核心与桌面 RDNA 2 一致，差异集中在物理规模（36 CU vs. 桌面端最多 80 CU）、频率策略（variable vs. 固定）和平台工具链。

几何引擎与光栅化管线

NGG/Primitive Shader 机制

PS5 GPU 引入了 AMD RDNA 系列的下一代几何（Next-Gen Geometry, NGG）引擎，也被索尼称为"Geometry Engine"。这实际上是 RDNA 架构用 Primitive Shader (图元着色器) 融合传统几何管线的一种实现。在 PS5 上，NGG/Primitive Shader 可以让 GPU 以 Compute Shader 类似的方式批量处理几何体，实现更可控的顶点处理和剔除。

封闭平台优势

由于 PlayStation 是封闭平台，索尼可以充分发挥 NGG 的潜力，确保开发工具链针对这种新模式进行了优化（相比之下，PC 上驱动最初对 NGG 支持不佳，而主机开发者可直接面向该架构编程）。几何剔除成为 PS5 可利用的优化点：开发者能够在 Primitive Shader 中编写定制的剔除逻辑，将不可见的三角形在光栅化前丢弃，减少后续管线负担。这对开放世界、大场景游戏尤为重要，定制剔除逻辑可在保证画面复杂度的同时减少后续管线负担。

微架构因果链

PS5 的几何管线创新属于开发范式的转变，而非纯粹堆硬件：硬件层面仍是 RDNA 2 提供的 2 个图形着色引擎，每个引擎每时钟可处理 4 个三角形的组装和光栅化（RDNA 2 相较前代在光栅化率上已提升一倍）。从微架构因果链看，NGG 的收益路径为：Primitive Shader 在 CU 内以 Wave32 执行剔除计算 → 剔除结果反馈至光栅化前端 → 减少无效图元进入像素着色阶段 → 降低后端渲染压力和显存带宽消耗。Sony 未增加固定功能单元数量，而是通过软件层的剔除策略让已有单元发挥更大效益。

与 PC RDNA 2 的对比

PS5 与 RX 6700XT 同属 RDNA 2 谱系，可作粗略同级参照，但两者在 CU 数、Infinity Cache 有无、ROP/带宽/功耗及驱动环境上差异较大，直接等价并不严谨。PS5 因封闭生态对 NGG 的充分运用，在几何处理效率上甚至可能优于部分同级 PC GPU。

初代光线追踪：性能与约束

Ray Accelerator 规格

PS5 GPU 是首批支持实时光线追踪的游戏机 GPU 之一，它集成了每 CU 一个Ray Accelerator (光线加速器)硬件，与 PC 版 RDNA 2 相同。每个 Ray Accelerator AABB 的相交测试，加速 BVH (包围体层次结构) 遍历，以及每周期可完成一次光线与三角形的相交计算。这使 PS5 理论上能够以硬件方式加速诸如阴影、反射中的光线碰撞检测，从而实现在受限功耗下达到基本的实时光追效果。在支持特性上，PS5 GPU 与 AMD RDNA 2 桌面卡保持一致，功能级别与 DXR/DX12 Ultimate 的光追能力类似，但 PS5 使用 Sony 自有图形 API（GNM/GNMX/SDK），并非 DirectX 12。开发者在 Sony SDK 中使用对应光追着色器接口，光线查询指令由硬件加速器执行，从而减少 Shader 负担。

性能约束

然而，PS5 光追能力相对有限是已知的现实。一方面，PS5 没有 AMD 在桌面 RDNA 2 系列上引入的 Infinity Cache，因此显存带宽成为光追性能的瓶颈之一（下面内存部分详述）。RDNA 2 世代的光追硬件属于初代实现，其限制在于：光线遍历过程中许多工作仍需由着色器来管理，例如 BVH 栈的维护和光线分支的处理。divergent时，Shader Core 常常在不同波前间执行不同光线路径的计算，出现严重的执行分歧，降低了硬件利用率。NVIDIA RTX 20 系列的 RT Core 在这方面也有类似问题，但凭借更高端的硬件投入依然领先性能不少。在同期对比测试（如 Digital Foundry 等第三方评测在同画质设置下的帧率对比）中，PS5 运行光追渲染时的帧率表现低于同时期 PC 高端 GPU [推断：具体差距因游戏和画质设置而异]，Xbox Series X 凭借略高的 GPU 频率（1.825 GHz vs 2.23 GHz）和更宽的显存总线（320-bit vs 256-bit）在部分光追场景中也有一定优势。

BVH4 设计取舍

开发者在 PS5 上往往只能启用较低级别的光追效果（如低分辨率反射、有限光线数量的阴影），以维持30或60FPS的帧率。PS5 光追性能受限还体现在一些设计取舍上。例如，其 BVH 加速结构采用 BVH4 (4叉树)每级节点最多包含4个子节点。相比之下，NVIDIA 当时采用 BVH2，但配合更强的遍历并行度。BVH4 结构下，每次遍历可并行测试4个包围盒，相对于 BVH2 提高一定并行性，但在复杂场景下树深仍较大。

实际游戏中的光追表现

总体来说，PS5 的光追硬件为开发者提供了"能用"的起点，但如果与 PC 上 GeForce RTX 系列那种全局光照、复杂反射效果相比还有不小差距。这种差距也是索尼和 AMD 在下一代架构中要重点改进的方面。

内存子系统与带宽权衡

统一内存规格

PS5 采用了统一内存架构16 GB GDDR6 显存既供CPU也供GPU使用，256-bit 总线宽度，数据频率 14 Gbps，总带宽 448 GB/s。与 AMD 桌面 RDNA 2 显卡 (如 RX 6800 XT, 256-bit @ 16 Gbps = 512 GB/s) 相比，PS5 的显存带宽偏低。

Infinity Cache 缺失

PC RDNA 2 引入了 128 MB Infinity Cache 来弥补带宽不足，这一大型片上 L3 缓存提供高达数 TB/s 的等效带宽提升。但在 PS5 定制 SoC 上，Infinity Cache 被完全舍弃。根据芯片显微照片分析，PS5 APU 上不存在类似大容量L3缓存的结构，Xbox Series X/S 亦是如此。原因可能在于：主机 SoC 空间和成本有限，索尼更倾向于将晶体管预算投入定制单元和CPU/GPU核心，而不愿增加大缓存(128 MB缓存对7nm工艺的面积消耗相当可观)。

多级缓存与 DCC 补偿

PS5 通过多层次缓存和压缩技术缓解带宽瓶颈。PS5 GPU 继承了 RDNA 2 的 L0/L1/L2 多级缓存设计：每个 CU 内有 16 KB L0 缓存，每个 Shader Array 配有 128 KB L1 数据缓存，全局共享 L2 达到数 MB 规模（die-shot 分析推测约 8–16 MB L2，无官方确认）。虽然没有额外的 L3，但更大的 L2 和改进的 L1 已经比上一代 GCN 主机（PS4 Pro）有数量级提升。

AMD 的 DCC 技术在 PS5 上得到延续和优化。DCC 可以在渲染输出（颜色、深度缓冲）时以无损方式压缩数据，典型压缩率可达到2:1甚至4:1，从而等效提升内存带宽。PS5 GPU 的着色器和光栅后端都直接支持压缩纹理/渲染目标的读写，这避免了不必要的解压操作。例如，G-buffer 读写过程中内存访问以压缩格式进行，减少了实际传输数据量。数据路径为：CU VALU 计算 → L0/L1 → L2 → DCC 压缩 → GDDR6 显存，反向时经 DCC 解压 → L2 → L1 → VGPR。

Cache Scrubber 与 SSD 协同

另外，索尼在 PS5 系统架构中加入了一些定制内存管理单元。Mark Cerny 曾提到 PS5 的"Cache Scrubber"和高效一致性引擎，用于配合超高速SSD将数据流直接注入GPU内存，而不破坏缓存一致性。这些细节属于系统层面的优化，其作用是在快速加载资源时自动清理相应缓存行，确保 GPU 及时访问更新的数据。对于开发者来说，这种机制是透明的，却提升了内存利用效率，减少了因数据无效而产生的带宽浪费。

成本与性能的折中

PS5 在内存子系统上做出了成本与性能的折中虽放弃了昂贵的Infinity Cache，但通过中等规模的片上缓存和成熟的压缩算法，再加上主机特有的统一内存管理，仍满足了 4K 游戏所需的数据吞吐。据第三方评测（如 Chips and Cheese 等微基准测试），4K 分辨率典型游戏负载下 Infinity Cache 在 PC RDNA 2 上的命中率约 60%（该数值随游戏 working set 大小波动显著）。PS5 没有这一级缓存，理论上等效带宽远低于 PC GPU。然而主机游戏通常针对固定硬件进行优化，例如控制渲染分辨率动态调整、资源预加载，从而将大部分显存访问命中在片上 L1/L2 缓存中。PS5 软件优化和硬件压缩是以"软补丁"形式弥补了Infinity Cache的缺席。当然，这种弥补并非完美，当遇到极端内存压力场景（如大量高分辨率纹理、光追场景下众多次级射线访问），PS5 带宽仍会吃紧，表现为帧率下降或需要降低渲染分辨率来维持稳定。但作为2020年的游戏机，PS5在带宽设计上的妥协是有意为之：优先保障典型负载下的效率，而把彻底解决高带宽需求的问题，留待后续的架构更新去完成。

Cache 数据路径总结

PS5 GPU 的 cache 数据路径为：CU VALU 访问 VGPR → L0 vector cache（16 KB/CU）→ L1 data cache（128 KB/Shader Array）→ L2（全局，约 8–16 MB，die-shot 推测值）→ GDDR6 显存。纹理采样路径为：Tex Unit → L1 texture cache → L2 → GDDR6。DCC 在 L2→显存和显存→L2 的边界处执行压缩/解压，对 CU 内 Shader 透明。Infinity Cache 在 PC RDNA 2 中的位置相当于 L2 和 GDDR6 之间的额外 L3 层，PS5 省略该层后，L2 miss 直接触发 GDDR6 访问，miss penalty 更大。

总结与竞品对比

PS5 的工程平衡

以 PS5 而言，索尼和 AMD 在有限硬件预算下打造出一款平衡的 GPU：它具备 RDNA 2 的高IPC和高频优势，填补了上一代主机 GPU 在着色效率上的短板，并通过硬件加速光追和高级几何着色为后续图形技术准备条件。

已知局限

然而，PS5 的局限也同样明显：没有额外缓存导致的带宽天花板、初代光追性能不足、缺乏专用 AI 加速单元等。这些不足在 2020 年尚属权衡取舍，但随着 NVIDIA 在 PC 图形领域推动实时光线追踪和 AI DLSS的快速进步，索尼/AMD 也意识到需要在下一步做出更激进的改进。

Xbox Series X 对比

同世代的微软 Xbox Series X 采用了与 PS5 相似的 AMD 定制 RDNA 2 GPU，但策略不同：微软选择了更"大而通用"的方案，即增加 CU 数量至 52 个、略降频率，以及利用更宽的显存总线（320-bit 搭配 10GB 高速 + 6GB 低速内存架构）来提升带宽。Xbox 并未引入索尼那样的独特几何引擎命名，可以看作一款接近公版规格的 RDNA 2 GPU。因此 Xbox Series X 在传统栅格性能上略有领先（算力 12 TFLOPS vs PS5 的 10 TFLOPS），但在定制优化方面缺乏索尼那样的创新点，例如没有专门为特定渲染技术做硬件增强。两种策略各有优劣：PS5 更专注于实际游戏场景的效率，Xbox 凭借额外资源提升纸面性能。索尼在几何处理和光追方面的积累为 PS5 Pro 和下一代提供了技术储备。

3.5.2 PlayStation 5 Pro

PlayStation 5 Pro（2024 年发布）是本世代中期的一次重要升级。与以往主机中期改款（如 PS4 Pro 主要提高分辨率输出）不同，PS5 Pro 追求性能提升，同时引入了下一代 GPU 架构的关键技术。Mark Cerny 在索尼总部的技术研讨会上详细介绍了 PS5 Pro 的架构改进，透露这款 GPU 结合了 RDNA 2 和 RDNA 3 的要素，并抢先实现了 RDNA 4 时代的部分特性。

具体而言，PS5 Pro 在GPU规模上从18个WGP增至30个WGP（算力提升67%），但更关键的是三大定制创新方向：几何前端增强、光线追踪单元升级和机器学习加速单元的引入。下面分别阐述这些改进，以及它们与 AMD 公版架构演进的联系。

几何管线与渲染前端改进

RDNA 3 几何技术嫁接

针对 PS5 在几何处理上的瓶颈，PS5 Pro 融合了 RDNA 3 部分几何管线技术来提升顶点吞吐和剔除效率。RDNA 3 架构对图形前端做出过优化，例如更智能的 Primitive Shader 调度和硬件级的微剔除。索尼在保持 Shader 程序兼容RDNA 2的前提下，将这些改进嫁接到 PS5 Pro GPU 中。PS5 Pro 仍使用 RDNA 2 的 NGG 编程模型，但"引擎盖下"某些执行路径经过优化。

固定功能剔除与 MDIA

例如，有理由推测 PS5 Pro 采用了 RDNA 3 提供的硬件快速剔除：RDNA 3 在图元着色阶段增加了固定功能单元，可自动剔除背面或细小三角形，而无需完全依赖着色器来判定。这种 fixed-function 改进在不改变开发接口的情况下提高了几何阶段整体效率，CU 内 Shader 无需执行剔除计算即可自动过滤背面/细小三角形，释放 ALU 资源用于顶点着色。还有报道指出 PS5 Pro 支持 RDNA 3 新增的 Multi-Draw Indirect Accelerator (MDIA) 单元，用于批量绘制调用处理，以降低 CPU 驱动开销。若该单元存在，这将使主机在场景中包含大量小物体时表现更佳，GPU 可直接处理成百上千的 Draw Call 而无需 CPU 逐次提交。

硬件规模与实际性能收益

除了内部架构优化，PS5 Pro 针对更高分辨率和更复杂场景可能出现的几何瓶颈，还依赖其增大的硬件规模来支撑。30 个 WGP 提供了更充裕的顶点着色能力，索尼声称在复杂场景下 PS5 Pro 的实际渲染性能比 PS5 提升可达 1.35–1.45 倍虽然没有理想状态下1.67倍那么高，但考虑到很多时候受限于几何和批处理，这个增幅相当可观。Mark Cerny 提到，一个在 PS5 上需耗时16ms的帧，PS5 Pro 可在约11ms完成，腾出的5ms预算可用于开启更多光追或改进材质效果。这背后就有几何管线提速的贡献：当原本受限于三角形处理的部分提速后，GPU 其他阶段才能充分利用扩展的算力。

几何增强的战略定位

索尼在研讨会上坦言传统光栅化管线的提升空间正变得有限。他们将 PS5 Pro 几何增强视为"把能挖的潜力都挖尽"，同时也清醒地认识到继续增加栅格管线性能收益递减。因此 PS5 Pro 在这方面的改进相对低调远不如它在光追和 AI 方面那么大。但这些"小改进"仍然发挥了重要作用：它确保了在开启光追、ML超分辨率等新特效后，基础的几何处理不会成为短板。渲染管线好比木桶，不能让某一块木板太短。PS5 Pro 通过融合 RDNA 3 技术将几何这一板适当加高，使整个管线更加均衡地扩展，为后来讨论的高级光追和 PSSR 提供了必要基础。

光线追踪单元升级：BVH8 与硬件栈管理

BVH8 升级

PS5 Pro 在光线追踪方面的升级跨越了一个完整世代。正如 Cerny 所说，索尼与 AMD 合作将"未来世代 (RDNA 4) 的光追特性首次带到 PS5 Pro"。最突出的改变有两点：BVH8 加速结构和硬件栈管理。BVH 节点宽度从 BVH4 提升至 BVH8，每个 WGP Intersection Engine 的吞吐翻倍：每周期 8 个 AABB 或 2 个三角形相交计算（PS5 为 4 AABB/1 三角形）。BVH8 以更少的层级表示相同空间，减少遍历步骤数，光线可以更快走完层次树。BVH8 的引入有效降低了光线-场景交互计算的开销，索尼宣称 PS5 Pro 光追纯计算速度相对 PS5 提升了 2–3 倍。这一结果与理论分析吻合：交叉单元吞吐提升2倍，加上栈管理优化带来的并行度提升（稍后详述），实际性能可达2-3倍区间。

硬件栈管理

更深层的改动是将栈管理从软件迁移至专用硬件。在PS5 (RDNA 2) 中，光线穿越BVH时需要在着色器里维护一个栈结构：记录遍历到哪个节点、哪些分支待处理。当光线击中复杂曲面或场景时，不同波前的光线可能走向完全不同的BVH分支，导致 Shader Core 执行高度分叉的逻辑。这正是之前提到的"divergent"情况，会明显降低 SIMD 利用率。PS5 Pro 通过专用硬件来管理BVH遍历栈，使这一过程对着色器完全透明。硬件栈管理器自动推送/弹出光线在 BVH 中的位置，无需 Shader 介入。两条微架构收益路径：其一，scalar ALU 资源释放，栈操作（地址计算、条件判断）的标量指令被消除，算力可用于实际相交计算；其二，硬件栈管理器可在光线层面隐式 reordering [推测：具体 reordering 机制未官方披露，以下分析为基于公开信息的合理推断]，将走向相似 BVH 分支的光线批量处理，减少 wavefront 间 divergence。NVIDIA Ada 架构的 Shader Execution Reordering（SER）目标一致：在硬件/驱动层重组光线执行任务。Sony 的实现很可能在硬件级完成了类似 SER 的功能[推测]，PS5 Pro 的栈管理硬件推测是在固定功能层面对光线进行队列化和重新排序，但 Sony 未公开其具体实现细节，将其直接映射为 RDNA 4 的 stack management/OOO/SER-like 机制属于架构推测。过去最令GPU头疼的曲面、毛发等复杂光追场景，现在也能较为平稳地运行，不会出现某几条"问题光线"拖慢整个波前的情况。

性能收益与同业对比

综合 BVH8 和硬件栈两项改进，PS5 Pro 光追单元达到了当时消费级GPU的第一梯队水平。虽然绝对性能仍比不上同期的 Nvidia RTX 4090 等顶级显卡，但PS5 Pro已经缩小了与竞品在光追上的代差。它也为游戏主机带来了此前不可行的方案：开发者可以考虑在主机游戏中引入更复杂的光线效果，Path Tracing。例如，在 PS5 Pro 发布后不久，已有技术演示展示使用路径追踪实现逼真的全局光照和反射，而仅通过 PSSR 超分辨率即可达到可玩帧率这是在原版 PS5 上无法实现的。而PS5 Pro的硬件升级使这一方案成为可能。AMD 在 RDNA 4 公版架构中引入了 BVH8 遍历和双光线交叉引擎，与 PS5 Pro 的技术方向一致，可视为[推测]主机定制经验向 PC 架构反馈的体现：PS5 Pro 可能提前验证了相关技术，为 RDNA 4 的商用提供了参考。但需注意，PS5 Pro 与 RDNA 4 之间不存在公开确认的直接技术继承关系，上述联系属于基于时间线和 feature 重叠的合理推断。

定制 AI 加速与 PSSR 超分辨率

AI 硬件整体定位

PS5 Pro 最重要的变化或许是 AI 硬件加速单元的加入和相应的 PlayStation Spectral Super Resolution（PSSR）机器学习超分辨率技术。面对 NVIDIA DLSS 在提升画质帧率上的成功，索尼选择走一条高度定制化的路线：在保证 PS5 Pro 向下兼容的同时，引入专用硬件来运行自己的超分算法，而非简单依赖常规着色器性能。PS5 Pro GPU 被称为"Enhanced GPU"，因为其中增加了一套由索尼和 AMD 联合设计的 AI计算硬件。根据官方透露，它具备每秒 300 万亿次整数运算 (INT8) 的推理性能，以及约 67 TOPS 的 INT16 性能。

本地 SRAM 架构

为了保持与 RDNA 2 Shader 模型的一致性，这套单元并非一个独立NPU，而是深度集成在 GPU 计算单元内部。具体实现上，索尼在每个 WGP 中增加了大容量的本地向量寄存器SRAM和一组新指令，从而使 WGP 能够以类似小型 AI 加速器的方式工作。PS5 Pro 的 AI 硬件由几个关键组件组成。超大本地寄存器文件/高速缓存：每个 WGP 额外增加了 512 KB 的本地超高速存储，全机共有约 15 MB（30 WGP × 0.5 MB）。这部分存储可以被新指令当作 scratchpad 来使用，相当于在 GPU 内部打造了一个容量可观、总带宽高达 200 TB/s 的专用AI缓存。15 MB 这个量级与一些移动 SoC 中的 NPU 内存接近，但带宽由于在片上，远超外部内存几个数量级。

专用 AI 指令集

索尼为 GPU 增加了 44 条专用 AI 指令，用于控制上述本地存储和执行矩阵计算。这些指令允许着色器程序以特殊模式运行，姑且称之为"AI 接管模式"。在该模式下，一个 WGP 专注处理一个 图像tile 的超分辨率计算，新的指令可以直接在 WGP 内读写那 512KB 高速SRAM，执行矩阵乘加等运算，而几乎不访问L2/显存。从架构上看，这类似把每个 WGP 变成一个小型AI加速器阵列：内部有充足算力（2个CU×64 ALU× 多倍 INT8 并行能力）和足够内存容纳神经网络的权重和中间特征图。

PSSR 算法设计

PSSR 采用轻量级 CNN 将低分辨率帧提升至目标分辨率，支持动态放大倍率，根据场景复杂度调整渲染分辨率。PSSR 的网络规模相对小（以降低延迟），但需要频繁处理不同时序的帧数据，因此前后还有预处理和后处理步骤。这些步骤在 GPU 上以常规计算实现，而卷积增强部分由AI硬件加速。索尼选择这种融合实现而非独立 NPU，也是因为专用 NPU 不擅长处理非卷积的图像处理步骤。

带宽瓶颈与解决

这一整套设计解决了什么问题呢？最主要的是显存带宽瓶颈。300 TOPS 的 INT8 算力听起来惊人，但如果每次运算都要访问显存中的数据，庞大的吞吐会被带宽拖累。实际测算表明，PS5 Pro 的 576 GB/s 显存最多只能支撑约 18 TOPS 的持续计算。超过 90% 的 AI 算力可能闲置。索尼和 AMD 认识到这一点，因此用上述大容量本地SRAM+新指令方案来确保尽量所有 AI 计算的数据都在片上完成。"每个 WGP 处理一个 tile"的方式，使得一个 tile 内 CNN 所需的输入特征、权重和输出都留存在 512KB 本地存储里，不需要频繁读写 L2/显存。据官方介绍，这样做让 PS5 Pro 在理想情况下几乎能榨干全部 300 TOPS 性能，用于 PSSR 的卷积运算。这正是索尼口中实现"Holy Grail（圣杯）"即**"神经网络完全在芯片上运行"**的第一步。虽然研讨会提到目前仍有部分中间数据不得不写回内存，但他们的长期目标是通过更大的片上资源和更优算法，实现真正零外部访问的全片上AI推理。

开发者视角

从开发者角度看，PSSR 作为系统特性被集成到 PS5 Pro 的渲染管线中，并提供了SDK接口。游戏可以以较低分辨率（比如1440p甚至1080p）进行光栅化和光追运算，然后调用 PSSR 在 GPU 帧缓存上直接完成到4K的放大。由于 PSSR 有专用硬件支撑，其延迟和占用资源远低于传统shader执行同等操作。这相当于给开发者"凭空"腾出了一大块 GPU 预算，可用于提升其他画质效果。例如，有了 PSSR 后，开发者可以大胆启用更高质量的光追（因为反正最终像素数较少），或者增加场景复杂度（因为最终都有AI补全细节）。等效来看，PSSR 把PS5 Pro的有效像素填充能力和像素着色能力放大了约2倍，正如索尼所言："将2倍放大提升到3倍放大，无异于把原有光栅/光追性能再翻一番"。他们甚至展望未来可以在主机上实现 "720p->4K (≈3X) 或 1080p->8K (4X) 的超级放大"，以取得远超当前水平的画质-性能平衡。

PS5 Pro 在不割裂生态的情况下实现了架构级的代际提升，同时为下一代架构积累了验证数据。从 AMD 的角度看，PS5 Pro 也验证了许多新技术在真实场景下的效果，例如 BVH8/SER硬件对于光追的意义、片上SRAM对于 AI 算法性能的意义等。这些经验直接反馈回 AMD 自身的 RDNA 路线图中：可以预见，RDNA 5 将更大力度地围绕光追与AI来设计。而索尼则通过 PS5 Pro 提前布局，在主机世代末期就积累了相关的软硬件协同开发经验。这一切最终汇聚到 Project Amethyst，即接下来要讨论的 PlayStation 6 规划蓝图中。

3.5.3 PlayStation 6 / Project Amethyst

技术方向与证据等级

2025 年的一次联合发布中，索尼和 AMD 罕见地提前披露了他们对下一代 PlayStation 主机 (PS6) GPU 技术方向的展望。代号为 "Project Amethyst" 的合作计划提出了三项创新：Neural Arrays (神经阵列)、Radiance Cores (光辉核心) 和 Universal Compression (全域压缩)。以下内容为基于公开披露的架构概念、行业传闻及技术原型分析，并非已确认的商用产品规格。证据等级分级：L1=Sony/AMD 联合公开披露方向；L2=高管/架构师公开演讲或采访；L3=供应链或可靠媒体爆料；L4=基于专利和架构趋势的合理推断。

设计哲学与定位

这些新理念目前尚处于公开概念与仿真阶段，Sony 与 AMD 将其定位为"未来几年内"可能落地的技术方向。从架构角度看，PS6 的设计哲学延续了在 PS5 Pro 上验证过的思路，即通过专用硬件模块 + 全栈协同优化，在 AI 和光追等关键领域取得突破，同时以全局数据压缩等手段解决性能与带宽瓶颈。这些技术很可能与 AMD RDNA 5 架构一脉相承（Mark Cerny 已深度参与 RDNA 5 设计），意味着它们若落地，将同时服务于 PlayStation 平台和 PC GPU 生态。

Neural Arrays：GPU 内的阵列化 AI 协同计算

Neural Arrays 是为了解决当前 GPU 在 AI 工作负载上效率不高的问题而提出的架构方案。传统 GPU 将大规模并行任务拆分到各个独立的 CU 上，各 CU 通过全局内存交换数据。这对于图形着色这样的任务尚可，但面对深度学习推理这类高度相关、需要大量数据共享的负载时就显得低效。Neural Arrays 的思路是：让 GPU 各计算单元之间能够像一个统一的AI加速器那样协同工作。

具体实现上，它需要在 GPU 内部建立一种高速低延迟的互连网络，使每个 CU (或 WGP) 可以直接与其他 CU 通信，而无需经由层层缓存和显存来中转。根据 AMD 和索尼的描述，Neural Arrays 类似于 GPU 内的 "Infinity Fabric" 网络，将所有 CU 互联起来。可以将其视为一种片上全局交换架构：当一个 CU 产生了中间计算结果，需要供其他 CU 使用时，可以经由 Neural Array Network 直接写入对方的本地存储或一个共享内存池，而不必把数据先写回L2/显存再由对方读出。这样做直接降低了 CU 间通信延迟 和 带宽消耗，使得跨 CU 协同计算的代价变小。对于大型神经网络推理，可以将不同层或不同卷积通道的计算分布到多个 CU，同时通过 Neural Arrays 保证它们的中间特征图几乎实时共享。

Tom's Hardware 将其形象地概括为："Neural Arrays 让 GPU 可以'一口气处理大块屏幕'的工作"。如果 PSSR 时代每个 WGP 处理一个 tile，那么 Neural Arrays 时代就可以让多个 WGP 合作处理更大的图像区域甚至整帧画面，避免过去那样硬性拆分带来的边界通信开销。

Neural Arrays 微架构挑战

实现 Neural Arrays 需要克服不少微架构挑战。首先是互连拓扑的设计：数十 CU 规模的 GPU die 上，任意 CU-to-CU 全连通开销过高。可能的设计包括分级结构（Shader Engine 内部全连通，跨 SE 经汇聚节点）或网格/环形拓扑 [推断]。其次是一致性和同步：当多个 CU 并行处理同一任务的一部分时，如何快速同步它们的进度、保证数据一致？这或许需要引入专门的硬件同步原语或修改现有波前调度机制，让多个波前跨 CU 协调执行。例如，硬件可以支持一种 "跨CUPersistent kernel" 模式，允许一个 GPU kernel 在多个 CU 上协同驻留运行，中间不必频繁由软件调度。这类似于 NVIDIA 在 Hopper 架构中引入的 Multi-SM Cooperative Groups 之类功能，让多个 SM 共享片上内存并同步执行大的矩阵运算 [推断]。

另一个关键要素是共享内存池。在 PS5 Pro 中，每个 WGP 有 512KB 本地 AI SRAM 来实现 tile 内数据回路。到了 Neural Arrays，这种片上存储可能会进一步扩大并支持跨CU访问。或许每组 CU (比如每4个CU一组) 共享几MB的 L1.5 级别高速存储，或者整个 GPU 引入一个更大的统一 L3 供 AI 用。这些都是合理推测 [推测]，因为为了让多 CU 共同处理一块数据，必须有一个大家都能快速读写的存储位置。开发者关注的指标如CU 间通信延迟、共享 SRAM 大小都会决定 Neural Arrays 的实际效用。

Universal Compression：全域数据压缩

Universal Compression 的动机

GPU 计算和渲染能力的快速增长，显存带宽和容量正成为新的瓶颈。前面讨论的 Neural Arrays 和 Radiance Cores 都指向一个事实：即使片上有再强大的算力，如果数据移动跟不上，最终性能仍受限。索尼和 AMD 提出了 Universal Compression，旨在构建一个覆盖全GPU数据流的压缩框架，优化带宽利用。它的理念是："在一切可能的情况下对数据进行压缩"，突破过去仅压缩纹理和渲染目标的局限。

设想机制

Universal Compression 设想为每一种数据类型找到合适的压缩方法，并在硬件层面自动执行压缩/解压，要做到对上层软件透明。设想的机制包括 [推断]：统一压缩引擎GPU 内可能会新增一个或一组压缩/解压单元，位于内存控制器附近，处理所有进出显存的数据流。它能够识别数据流类型并选择对应算法进行处理。在带宽敏感的路径上，例如L2 -> 显存的写回、显存 -> L2的读取，都通过这个引擎，确保尽可能以压缩格式传输。

类型感知压缩算法

不同数据有不同模式，通用压缩需要针对各类数据分别设计算法。例如，顶点/指数数据可以利用其空间连续性（quantization或三角重组算法）；光线队列数据（大量浮点坐标方向）可以用低精度表示（如 FP16 甚至 FP8）或位掩码等特殊结构压缩。AI 特征图本身可能已经是低精度 (INT8/FP16)，还能否进一步压缩？或许可以利用稀疏性或者视觉不敏感度进行有损压缩。关键是算法既要压缩率高，又需解压开销小，否则得不偿失。

压缩态直接处理

Universal Compression 的理想境界是**"压缩态即计算态"**，也就是数据即使保持压缩格式，也能直接被 GPU 消费或生产。举例来说，如果纹理一直以压缩块存储，那采样单元可以在解压同时完成过滤计算；又比如光追的BVH节点信息若采用某种紧凑编码，Radiance Core 可以直接在压缩形式下遍历，无需每访问一个节点就解压一次。实现这点需要在设计之初就将压缩方案融入数据路径。例如，可设想 AMD 在 RDNA 5 中为 BVH8 节点采用了一种定长压缩表示，使得Ray Accelerator可以一次读取一个cache line拿到多个子节点数据，这实际上就相当于压缩了BVH节点（相比按传统结构逐个读取节点）。

与 Neural Arrays/Radiance Cores 的协同

Universal Compression 将与 Neural Arrays 和 Radiance Cores 形成协同效应。Neural Arrays 生成的大量 AI 中间特征图若需要跨 CU 传输，可以先压缩再发送，降低通信流量。Radiance Core 维护的光线/路径队列也可以压缩存储，比如用更少bit描述方向、或者对相近的光线状态差分压缩，从而在批量调度光线时减小存储占用。更广泛地，它使得 GPU 可以"用压缩视角看待内存"：能压则压，尽量把珍贵的显存带宽用在刀刃上。渲染分辨率和特效复杂度每提升一步，对内存的需求都是指数级上涨，而经济可行的显存带宽提升却远跟不上（带宽增长受限于物理接口和功耗）。

行业对比与前景

从AMD高管的表态来看，Universal Compression 确定会出现在未来的 AMD GPU SoC 中，RDNA 5 极可能整体导入该技术，并提供相应的软件支持，让开发者无需手工管理压缩。对游戏开发者而言，这或许是"幕后"的改变因为压缩/解压由硬件透明处理，开发者看到的还是统一的内存模型。但其效果将体现在性能上：比如同样100GB/s的场景流量，在新架构上实际只消耗50GB/s的物理带宽，等价于显存效能翻倍。NVIDIA 在这方面走的是另一条路通过特定技术（如 SAMPLER FEEDBACK、纹理空间着色、Opacity Micromap、Displaced Micro-Mesh 等）来减少不必要的数据传输和存储。但这些方法往往各自为政、针对特定问题。AMD/Sony 的 Universal Compression 则是一种全局策略：用统一框架覆盖所有数据类型。如果成功，将对 GPU 架构产生长期影响。它甚至可能延伸到 CPU/GPU 统一内存的更广领域：例如未来 APU 中，Universal Compression 也可用于 CPU 端的数据（虽然目前重点在 GPU 数据）。在主机场景，统一内存大、多场景切换频繁，压缩通用数据（如体积光照表、粒子系统缓冲）都将为性能争取可观红利。

软硬件协同与 PS6 技术定位

Project Amethyst 的三项技术共享同一设计哲学：在 GPU die 内部通过专用硬件 + 数据压缩解决带宽和协同瓶颈。Neural Arrays 解决 CU 间通信，Radiance Cores 解决光追遍历效率，Universal Compression 解决数据移动开销。三者均处于早期概念/原型阶段，Sony 与 AMD 公开将其定位为面向未来架构的技术探索，具体规格和落地时间均未确定。Mark Cerny 已参与 RDNA 5 设计 （媒体报道），PS6 GPU 预计与 RDNA 5 PC GPU 在关键特性上保持一致，但这也属于基于现有合作模式的合理推测，并非官方承诺。软件生态层面，Sony 从 PS5 Pro 开始推动软硬一体设计（PSSR API、新指令封装），若上述技术最终商用，PS6 的每项新硬件预计伴随对应 API/SDK。但从微架构分析视角，Project Amethyst 相关描述属于公开概念/传闻/原型分析，硬件机制本身在未正式发布前均存在变更可能，这一部分内容应以此证据等级为前提阅读。

从 PlayStation 5 到 PS5 Pro 再到 PS6，主机 GPU 演进路径清晰：PS5 引入 RDNA 2 的高 IPC 和初代光追；PS5 Pro 验证 BVH8、硬件栈管理和片上 AI SRAM 的可行性，为 RDNA 4/5 提供实测数据；PS6 处于概念/原型阶段探索 Neural Arrays、Radiance Cores 和 Universal Compression，目标在 GPU die 内部通过专用硬件突破带宽与协同瓶颈。每一代的技术验证反哺 AMD 公版架构，形成主机-PC 协同演进的反馈回路。

3.5.4 Xbox Series X|S

Xbox Series X|S 是微软基于 AMD RDNA 2 架构定制的主机 GPU，与 PS5 同期发布。CU 组织和微架构与 PS5 一致（WGP/CU 结构、Ray Accelerator、NGG 引擎）。

Velocity Architecture

微软定义的 Velocity Architecture 包含四个组件：定制 NVMe SSD（Series X 2.4 GB/s）、硬件解压引擎（支持 LZ 和 BCPack，有效带宽约 4.8 GB/s）、Xbox 专用存储 API（绕过 CPU 直接将存储数据加载到 GPU 内存；PC 平台上的 DirectStorage API 最初即源自此 Xbox 技术，后独立演进为跨平台标准）、以及 Sampler Feedback Streaming (SFS)。

SFS 是 Xbox Series X|S 的独特特性，允许 GPU 在采样纹理时向 CPU 报告实际使用了哪些 mip level 和 tile，从而精确控制纹理流送粒度，只加载真正需要的纹理数据，明显减少内存占用和带宽浪费。

带宽分段

内存分段设计

Series X 采用分段内存设计：10 GB GDDR6（320-bit，560 GB/s）供 GPU 渲染数据，6 GB GDDR6（192-bit，336 GB/s）供 CPU 和系统数据。分段设计在成本与带宽间取得平衡，但要求开发者显式管理数据放置。Series S 采用统一 128-bit 总线，带宽进一步降低。

GPU 规格与 PS5 对比

GPU 规格与 PS5 相比，Series X 在传统栅格算力（12 TFLOPS vs. 10 TFLOPS）和显存带宽（560 GB/s 峰值 vs. 448 GB/s）上占优，Series S 在低端市场提供低成本选择。两者 GPU 微架构核心差异很小，均为 RDNA 2 WGP/CU 结构，含 Ray Accelerator，均不集成 Infinity Cache，依赖 L0/L1/L2 和 DCC 管理带宽。主要差异在系统级 I/O 策略（Xbox SFS vs. PS5 高速 SSD+Cache Scrubber）、CU 规模/频率权衡（Xbox 多 CU 低频 vs. PS5 少 CU 高频），以及内存架构（Xbox 分段 vs. PS5 统一）。

SFS 技术路径

Xbox Velocity Architecture 中 SFS 的技术机制为：GPU 采样纹理时，Sampler Feedback Unit 记录实际访问的 mip level 和 tile 坐标 → 反馈数据通过专用通道传至 CPU → CPU 根据反馈精确控制纹理流送，仅加载所需 tile。该路径减少了 GPU 侧 overfetch 和内存占用，等效提升了纹理带宽利用率。与 PS5 的高速 SSD+Cache Scrubber 方案相比，Xbox SFS 侧重 GPU-CPU 协同的纹理粒度优化，PS5 侧重存储到 GPU 的直通带宽；两者均解决存储-内存-带宽瓶颈，但优化节点不同。

四、CDNA

Graphics Core Next (GCN) 架构同时承担图形渲染和通用计算两种负载，其工程折中逐渐无法满足任一端的需求：图形管线中的光栅化、ROP、显示控制器等单元在纯计算场景下闲置浪费晶体管，而 GCN 的 Wave64 执行模型在延迟敏感的游戏负载中因单 wavefront 执行周期过长（4 周期）而效率不足。2019 年，AMD 将 GPU 架构正式分叉为两条独立产品线：RDNA 面向游戏图形场景，采用 Wave32 执行模型以降低单批次延迟、重构缓存层次以提升像素着色命中率；CDNA（Compute DNA）面向 HPC 与 AI 计算场景，延续 GCN 的 Wave64 执行模型，保留宽 SIMT 吞吐特征，并通过移除图形固定功能管线（光栅化引擎、几何装配、曲面细分、ROP、显示控制器等）将晶体管预算重新分配给计算单元、Matrix Core 和 HBM 内存接口。

执行模型层面，CDNA 1–4 维持 Wave64 作为基本调度粒度：每条 wavefront 64 个线程，映射到 CU 内 4 个 16-wide SIMD 上，4 个周期完成一轮执行。与 RDNA 的 Wave32（2 个 32-wide SIMD，单周期完成一轮）相比，Wave64 的指令发射频率更低，但单 wavefront 覆盖的并行度更高，在 occupancy 充足的高吞吐计算负载下，调度器每周期选择 wavefront 的开销更低（ready wave 队列中相同 wave 数量下，64-wide wave 的利用率统计方差更小）。CDNA 5 放弃了这一延续 15 年的模型，转为 Wave32/WGP 组织，这个断裂在 4.5 节展开。CDNA 产品线的核心差异化在于 Matrix Core：每个计算单元集成多个矩阵乘法加速单元，支持 MFMA/WMA 指令族，以 wavefront 粒度执行矩阵乘累加运算。Matrix Core 的操作数来自 VGPR（Vector General Purpose Register），结果写回 VGPR accumulator，其吞吐远高于逐元素执行的 VALU（Vector ALU）。

CDNA 1 到 CDNA 5 的演进围绕四条主线：（1）Matrix Core 的精度覆盖从 FP16 扩展到 FP64、INT8、FP8 及 MXFP4/6，每计算单元每周期矩阵运算吞吐增长三个数量级；（2）封装从单芯片 GCD 演进为 MCM 多 GCD（CDNA 2），再演进为 3D Chiplet 堆叠 + IOD（CDNA 3/4），最终演进为 XCD + FCD + IOD 三类功能 die 分离并以 3D 混合键合集成（CDNA 5）；（3）缓存层次从三级结构（L1→L2→HBM）扩展为四级（引入 Infinity Cache），再在 CDNA 5 中重组为 per-WGP 大容量 LDS + FCD 级 Global L2 + HBM4 的新三级结构；（4）执行模型从 Wave64/CU 延续四代后，在 CDNA 5 断代切换为 Wave32/WGP，GCN 执行模型在计算架构中的 15 年延续就此终结。

4.1 CDNA 1

CDNA 1（产品代号 Arcturus，对应 AMD Instinct MI100）是 CDNA 分叉的首代产品，2020 年发布。其在微架构层面的核心特征是：保留 GCN CU 结构但移除全部图形固定功能，引入初代 Matrix Core，采用 HBM2 高带宽显存，并将 L2 缓存扩展至 8MB。MI100 配置 120 个 CU，7nm 制程，TDP 约 300W。

4.1.1 ISA

CDNA 1 的 CU 继承 GCN 5 代设计：每个 CU 包含 4 个 16-wide SIMD16 向量单元、1 个标量 ALU（SALU）、64KB LDS（Local Data Share，软件可控 scratchpad）、32KB L1 数据缓存和 4 个 Matrix Core。Wave64 执行时，一个 wavefront 的 64 个线程在 4 个 SIMD 上各映射 16 个 lane，每周期推进 16 个线程的同一条指令，4 周期完成一轮 wavefront 指令。CU 内 wavefront 调度沿用 GCN 的硬件调度器（per-SIMD wave scheduler），每个 SIMD 可同时驻留多个 wavefront（典型配置下每 SIMD 8–10 个 wavefront，每 CU 共 32–40 个），通过 wavefront 切换隐藏访存和指令延迟。

CDNA 1 使用 GFX9 ISA 的超集，新增 MFMA 指令族。ISA 层面，MFMA 指令格式为 V_MFMA_CDIMxBDIMxADIM_ETYPE vdst, vsrcA, vsrcB, vsrcC，其中 CDIM/BDIM/ADIM 定义输出和输入矩阵的维度，ETYPE 定义元素数据类型。编译器可通过内联汇编或 HIP 内置函数（如 __builtin_amdgcn_mfma_f32_16x16x16f16）直接调用 Matrix Core。

4.1.2 Scheduling

调度器维护每个 wavefront 的状态：active（就绪可发射）、wait（等待内存/LDS/SFU 操作完成）、barrier（在同步点等待）。每个周期调度器从 active 队列中选择一个 wavefront，将其指令发射到对应的执行单元（VALU、SALU、VMEM、SMEM、LDS、Matrix Core）。当指令存在寄存器依赖时，硬件通过 scoreboard 或 waitcnt（wait count）机制阻塞 wavefront 直到依赖清除。CDNA 1 沿用了 GCN 的 waitcnt 模型：编译器在指令中编码等待的 outstanding memory/LDS 操作数，硬件在计数器归零后解除阻塞。

与 RDNA 的 Wave32 相比，CDNA 1 的 Wave64 在延迟敏感型负载（如短依赖链计算、小数据量 reduction）下响应更慢：单个 wavefront 完成一轮需要 4 周期，而 Wave32 仅需 1 周期。但在高并行度计算负载中，只要 occupancy（驻留 wavefront 数）足够，调度器可以在每个周期从就绪队列中选择不同 wavefront 发射指令，SIMD 利用率不因单 wavefront 延迟而下降。CDNA 1 针对纯计算场景优化了调度器仲裁逻辑，移除了图形负载下用于几何/像素阶段切换的逻辑，使纯计算 dispatch 的提交延迟和调度开销降低。

4.1.3 Execution Unit

CDNA 1 的 Matrix Core 是 CDNA 系列与 GCN/RDNA 的本质区别。每个 CU 的 4 个 Matrix Core 与 4 个 SIMD 一一对应，每个 Matrix Core 内部包含一个矩阵乘法累加阵列，支持 MFMA（Matrix Fused Multiply-Add）指令。MFMA 指令以 wavefront 为单位执行：64 个线程的 VGPR 提供矩阵操作数（A 矩阵和 B 矩阵元素），Matrix Core 执行乘累加后将结果写回 VGPR（accumulator 寄存器）。

完整的数据路径如下：

• 操作数加载：HBM2 → L2 → L1 → VGPR（通过 global load 指令，经 VALU 的 load/store 单元）
• 矩阵运算：VGPR A/B → Matrix Core 乘法阵列 → Accumulator VGPR C/D
• 结果回写：Accumulator VGPR → LDS（用于 wavefront 间数据交换）或 → L1 → L2 → HBM2

对于分块矩阵乘法（GEMM tile），LDS 承担 tile buffering 的关键角色：将 A/B 矩阵的子块从 HBM 预取到 LDS，供同一 workgroup 内多个 wavefront 的 Matrix Core 反复读取，减少对 L1/L2 的重复请求和 HBM 带宽压力。MFMA 指令执行时，操作数直接从 VGPR 读取，不能直接从 LDS 或内存获取，因此编译器或手写内核需要在 LDS 和 VGPR 之间显式移动数据，通过 ds_read/ds_write 指令完成 LDS ↔ VGPR 传输。

CDNA 1 的 Matrix Core 精度覆盖 FP16、BF16、FP32 和 INT8。以 FP16 为例，每个 CU 的 4 个 Matrix Core 合计每周期可执行 1024 个 FLOP 操作（等效 512 个 FMA），而同等 CU 的 4 个 SIMD（纯向量 ALU）每周期仅 128 个 FP32 FMA（256 个 FLOP），矩阵/向量吞吐比为 4:1。FP32 矩阵吞吐为 256 FLOPs/CU/周期，是向量 FP32 吞吐的 2 倍。INT8 矩阵吞吐为 2048 OPs/CU/周期，是 INT8 向量吞吐的 16 倍。MI100 整卡配置 120 个 CU，理论峰值 FP16 矩阵吞吐约 184 TFLOPS，FP32 矩阵吞吐约 46 TFLOPS，FP64 向量吞吐约 11.5 TFLOPS。

CDNA 1 的 Matrix Core 存在两个关键限制：其一，不支持 FP64 矩阵运算，双精度稠密线性代数（如 LAPACK 中的 DGEMM）仍需通过向量 ALU 逐元素执行，吞吐受限于 FP64 向量通路的 1/2 速率（相对 FP32）；其二，MFMA 指令的操作数只能从 VGPR 读取，无法直接从 LDS 或内存获取，因此分块矩阵乘法必须通过显式的 VGPR-LDS 数据移动来组织 tile，编译器或手写内核需要精细管理寄存器分配以避免 VGPR pressure 过高导致每 SIMD 驻留 wavefront 数减少、occupancy 下降。

4.1.4 Register File

CDNA 1 的寄存器文件继承 GCN 5 代设计但做了一项关键扩展：引入 Accumulator VGPR（AccVGPR）作为 Matrix Core 的专用输出目标。

VGPR 配置。每 CU 4 个 SIMD16，每 SIMD 配置 128KB 的物理寄存器空间，其中 256 个 32-bit 通用 VGPR 和 256 个 32-bit AccVGPR 共享这 128KB 空间。ROCm 文档标称 MI100 的 VGPR File 为"256 VGPR and 256 AccVGPR"per CU。SGPR 文件每 CU 12.5KB（约 800 个 32-bit SGPR，workgroup 间共享）。

AccVGPR 的设计动机。MFMA 指令的累加器 C/D 矩阵写入 AccVGPR（a[0:255] 编号空间），而非通用 VGPR（v[0:255]）。物理上 AccVGPR 与 VGPR 使用不同的 bank 组，使 Matrix Core 写回和 VALU 读取可在同一周期并行进行而不产生 bank conflict。AccVGPR 与 VGPR 之间的数据搬运需通过 v_accvgpr_read / v_accvgpr_write 指令（延迟约 4 周期），这是 MFMA 结果供后续 VALU 操作使用时的必经路径。

occupancy 约束。每 SIMD 物理空间 128KB，每 wavefront 最多使用 256 个 VGPR + 256 个 AccVGPR。若 kernel 使用 128 个 VGPR + 128 个 AccVGPR/wave，每 SIMD 可驻留约 2 个 wavefront（共 256 VGPR + 256 AccVGPR = 使用 128KB 中的 64KB × 2 = 128KB）。典型 GEMM kernel 使用 64–128 个 VGPR + 大量 AccVGPR（矩阵 tile 的累加器），occupancy 通常在 2–4 个 wave/SIMD。MI100 的 120 个 CU × 每 CU 4 SIMD × 2–4 wave = 960–1920 个活跃 wavefront，足以隐藏 HBM2 的 200–300 ns 延迟（需约 1000 个 wavefront 以完全隐藏延迟）。

与 GCN 5.1（MI60/gfx906）的区别。GCN 5.1 没有 AccVGPR，也没有 Matrix Core。MI100 引入 AccVGPR 是 CDNA 分叉时新增的物理寄存器资源，不是从 VGPR 中划分出来的逻辑分区。

4.1.5 Memory Subsystem

CDNA 1 的存储子系统围绕"大工作集、高带宽、低延迟 variance"的 HPC 需求设计，形成三级结构。

L1 数据缓存：每 CU 32KB，4-way set-associative，64B cache line，主要服务 VGPR 的标量/向量 load/store 请求。L1 与 LDS 在功能上分离：L1 为 per-CU vector data cache，写策略由指令类型与 cache policy 共同决定，对软件基本透明；LDS 为软件可编程的 scratchpad，通过显式地址访问。L1 的 32KB 容量对于计算负载中的数据复用有限：在 stencil 计算中，L1 可缓存相邻网格点的重复访问；但在大矩阵乘法中，tile 尺寸通常超过 32KB，L1 仅能缓存最内层循环的少量数据。

L2 缓存：全芯片共享 8MB，16-way set-associative，划分为 32 个 slice，每 slice 支持 64B/周期吞吐，总内部带宽约 3 TB/s。L2 承担三项职责：汇聚所有 CU 的 L1 miss 请求、服务跨 CU 的数据一致性（write-back 协议）、作为 HBM2 访问的汇聚和预取层。8MB 容量对于 MI100 的 120 个 CU 来说，每 CU 约分摊 68KB。在数据重用度较高的 HPC 负载（如迭代求解器、stencil 计算）中，L2 可明显降低 HBM 访问频率；但在 AI 训练的大模型参数访问中，8MB 相对模型参数量（数十 GB）微不足道，cache hit rate 较低。

HBM2：MI100 配置 32GB HBM2，4096-bit 总线（4 堆 × 1024-bit），pin 速率 2.4 Gbps/pin，带宽约 1.23 TB/s。HBM2 对比同期 RDNA 系列使用的 GDDR6（如 RX 5700 XT 的 448 GB/s），带宽高出约 2.7 倍，但容量成本也更高，HBM2 的 2.5D 封装（硅中介层 + memory die 堆叠）增加了封装复杂度和成本。HBM2 的访问延迟（从 CU 到 HBM，约 200–300 ns 量级）虽不比 GDDR6 低，但 HBM2 的 bank 数量多（每堆 8 个 bank group，32 个 bank）、行缓冲命中率更高，在大量并发请求下可维持较高的有效带宽。

4.1.6 封装与互联

单片 GCD 封装（120 CU，7nm），无需片间互联。

4.1.7 小结

CDNA 1 引入 XNACK（eXclude NACK）机制。关闭 XNACK 时，GPU 访问未映射页触发致命错误（page fault），适合性能可控的已知工作集场景。开启 XNACK 后，GPU 访问未映射页触发页故障中断，系统调入页面后重试 wavefront，支持超大虚拟地址空间的 oversubscription。XNACK 开启时，页故障处理延迟约数微秒，wavefront 重试可能导致流水线气泡，因此高性能计算通常关闭 XNACK，仅在开发调试或超大内存模型推理时启用。

CDNA 1 关键参数

4.2 CDNA 2

CDNA 2（2021 年发布，产品 AMD Instinct MI200 系列，包括 MI250/MI250X）在 CDNA 1 基础上引入两项关键改动：多芯片模块（MCM）封装，以及 FP64 向量/矩阵双通路的系统性强化。MI250X 为旗舰 SKU，含 2 个 GCD、220 个 CU、128GB HBM2e，TDP 约 560W。

4.2.1 ISA

CDNA 2 的 LLVM target 为 gfx90a，属于 GFX9 ISA 族的扩展。相对 CDNA 1（gfx908），核心 ISA 变化集中在 FP64 矩阵指令的引入。

新增 FP64 MFMA 指令。V_MFMA_F64_4x4x4_F64 和 V_MFMA_F64_16x16x4_F64 两条指令使 Matrix Core 具备 FP64 矩阵乘累加能力。操作数格式为 64-bit IEEE double，A/B 矩阵元素从 VGPR 对（2 个连续 32-bit VGPR）中读取，累加器写回 VGPR。这两条指令在 CDNA 1 的 gfx908 中不存在。

BF16 1K-op MFMA。新增 V_MFMA_F32_32x32x8_BF16_1K 等变体，将 BF16 矩阵吞吐从 CDNA 1 的 512 FLOPs/CU/周期提升到 1024 FLOPs/CU/周期。"1K"后缀表示每条指令一次处理 1024 个操作数对。

waitcnt 模型。延续 CDNA 1 的 s_waitcnt 机制，编译器在内存指令后编码 vmcnt/lgkmcnt/expcnt 三组计数器，硬件在计数器归零时释放 wavefront。CDNA 2 未对 waitcnt 语义做修改，但 GCD 间通信引入了新的 fence 指令（s_waitcnt_vscnt 配合 buffer_gl0_inv/buffer_gl1_inv）用于跨 GCD 一致性保证。

其他 ISA 扩展。新增 buffer_atomic_add_f64 等 FP64 原子操作指令，支持 HPC 负载中常见的归约操作不经 CAS 循环完成。新增全局内存 scope hint（buffer_load_dword 的 sc0/sc1 位扩展），让编译器向缓存系统声明数据的共享范围。

4.2.2 Scheduling

CDNA 2 的调度模型与 CDNA 1 同源：每 CU 4 个 SIMD16，每 SIMD 独立的 wave scheduler，Wave64 粒度调度。调度器逻辑未做结构性修改。

双 GCD 下的调度隔离。两个 GCD 各自独立运行调度器，不存在跨 GCD 的 wavefront 迁移。一个 kernel dispatch 被 Command Processor 按 workgroup 粒度分发到两个 GCD（由驱动层的 workgroup 分配策略决定），之后各 GCD 内部的 Shader Engine / CU / SIMD 调度独立运行。跨 GCD 的同步依赖全局 fence 和原子操作完成，不依赖硬件调度器协调。

occupancy 与调度效率。每 CU 仍维持最多 40 个驻留 wavefront（每 SIMD 10 个）。Wave64 在 occupancy 充足时每周期可从 4 个 SIMD 各选一个就绪 wavefront 发射，形成 4-way 并发。CDNA 2 的 FP64 向量通路全速化意味着 FP64 指令不再因半速执行而额外占用 SIMD 两个周期，调度器看到的 FP64 指令延迟与 FP32 相同，就绪 wavefront 的回填速度更快，高 FP64 占比的科学计算 kernel 在 SIMD 利用率上相比 CDNA 1 有结构性提升。

MFMA 指令的调度特性。MFMA 是多周期指令（典型延迟 32–64 周期），占用 Matrix Core 流水线期间不阻塞 SIMD 的后续向量指令发射，调度器可在 MFMA 执行的同时向同一 SIMD 发射非 MFMA 指令（如 VALU、LDS 操作），形成"overlap execution"。但 MFMA 结果写回 accumulator VGPR 前，读取该 VGPR 的后续指令会被 waitcnt 阻塞。

4.2.3 Execution Unit

CDNA 2 的 CU 结构在 CDNA 1 基础上做了两项关键修改，均围绕 FP64 双精度运算能力展开。

FP64 向量通路全速化。CDNA 1 及 GCN 的 FP64 向量吞吐为 FP32 的一半（每 SIMD 每周期 16 个 FP64 FMA 对比 32 个 FP32 FMA）。CDNA 2 将 FP64 向量单元扩充至全速：每 SIMD 每周期 32 个 FP64 FMA，CU 级 FP64 吞吐从 64 FLOPs/周期 提升到 128 FLOPs/周期。整卡 MI250X 的 FP64 向量峰值达到约 47.9 TFLOPS（2 GCD × 110 CU × 128 FLOPs/CU × 频率），约为 MI100（11.5 TFLOPS）的 4.2 倍。这一改动的工程动机来自 HPC 负载的反馈：科学计算（计算流体力学、气候模拟、量子化学）中 FP64 运算占比高，FP64 向量吞吐不足是 CDNA 1 的主要瓶颈。

FP64 矩阵运算支持。CDNA 2 的 Matrix Core 新增 FP64 MFMA 指令，每个 CU 的 4 个 Matrix Core 合计每周期可执行 256 个 FP64 FMA。FP64 矩阵吞吐由此达到 FP64 向量吞吐的 2 倍，为稠密线性代数（如 LAPACK 中的 DGEMM、Cholesky 分解、QR 分解）提供了专门的加速通路。MI250X 的 FP64 矩阵峰值约 95.7 TFLOPS。这组数字与 AMD 官方规格页逐项吻合：MI250X 标称 FP64 向量 47.9 TFLOPS、FP64 矩阵 95.7 TFLOPS、FP16 与 BF16 各 383 TFLOPS，对应 220 个 CU、1.7 GHz 峰值引擎时钟、128GB HBM2e 与 3.2 TB/s 峰值带宽。AMD 在 MI200 发布材料的对照注脚中同时给出 MI100 的基线（FP64 11.54 TFLOPS、FP32 矩阵 46.1 TFLOPS、FP16 184.6 TFLOPS），与 4.1 节参数表中的 CDNA 1 数据一致。

精度扩展方面，CDNA 2 的 Matrix Core 同时提升了 BF16 矩阵吞吐，从 MI100 的 512 FLOPs/CU/周期 提升到 1024 FLOPs/CU/周期，INT8 保持 1024 OPs/CU/周期。整卡 MI250X 的 FP16/BF16 矩阵峰值约 383 TFLOPS，约为 MI100（184 TFLOPS）的 2.1 倍。

4.2.4 Register File

CDNA 2 的寄存器文件配置与 CDNA 1 一致：每 CU 512KB VGPR（4 个 SIMD × 128KB/SIMD），每 SIMD 可容纳 256 个 32-bit VGPR × 最多 10 个 wavefront。SGPR 文件每 CU 12.5KB。

VGPR 与 occupancy 的约束关系。每个 wavefront 可使用的 VGPR 数量（由编译器分配）直接决定每 SIMD 能驻留多少个 wavefront。以 SIMD 128KB（= 256 × 32-bit × 10 waves）为例：若 kernel 使用 256 个 VGPR/wave，每 SIMD 只能驻留 1 个 wavefront；若使用 128 个 VGPR/wave，可驻留 2 个；64 个 VGPR/wave 可驻留 4 个。occupancy 下降意味着调度器可选择的就绪 wavefront 减少，内存延迟更难被隐藏。

Accumulator VGPR（AccVGPR）。CDNA 2 延续 CDNA 1 引入的 AccVGPR 概念：MFMA 指令的累加器结果写入 AccVGPR 而非通用 VGPR。AccVGPR 与 VGPR 共享同一物理存储空间（每 SIMD 128KB 总量不变），但在 ISA 层面使用独立编号（a[0:255]）。AccVGPR 的设计动机是减少 MFMA 写回对通用 VGPR bank 的竞争：Matrix Core 的结果写入 AccVGPR bank，与同一周期 VALU 读取 VGPR bank 不冲突。

FP64 对寄存器的影响。FP64 操作数占用 2 个连续 32-bit VGPR（一对），MFMA FP64 指令的 A/B/C/D 矩阵均以 VGPR pair 形式编码。FP64 kernel 的有效 VGPR 消耗是 FP32 kernel 的约 2 倍，occupancy 相应减半。这是 FP64 HPC 负载在 SIMD 利用率上通常低于 FP16/FP32 AI 负载的寄存器层面原因。

4.2.5 Memory Subsystem

每个 GCD 配置 6 组 HBM2e（64GB/GCD），两片合计 128GB。HBM2e 的 pin 速率提升至 3.2 Gbps/pin，每 GCD 带宽约 1.6 TB/s，整卡峰值 3.2 TB/s。HBM2e 对比 HBM2 的带宽提升约 30%，主要受益于 memory die 制程改良（从 21nm 到 14nm）和堆叠层数增加（从 4/8 层到 8/12 层）。

L2 缓存维持 8MB/GCD，16-way，32 slice，内部带宽数百 GB/s 级。CDNA 2 的全片 ECC 覆盖 HBM、L1、L2 和寄存器文件，满足超算长周期运行的可靠性需求。

4.2.6 封装与互联

MI250X 在单封装内集成两个对称的 Graphics Compute Die（GCD），每个 GCD 为独立芯片，含 110–112 个 CU（完整设计 112 个，部分 SKU 屏蔽 2 个），两片合计 220 个 CU。每个 GCD 拥有独立的 HBM2e 控制器（6 组/GCD）、L2 缓存（8MB/GCD）和 Infinity Fabric 链路控制器。两个 GCD 之间通过封装内部的 Infinity Fabric 高速 SerDes 链路互联，双向带宽 400 GB/s。

MCM 封装的工程动机是突破晶圆尺寸对单片 GPU 的面积限制：7nm 工艺下单个 GCD 的晶体管规模（约 300 亿+）和 die 面积（约 700mm² 量级）已接近光刻掩版和良率的边际，通过两片独立 GCD 可在不制造超大单芯片的情况下实现 CU 数量翻倍，同时提升良率（单片小 die 的缺陷密度容忍度更高）。代价是 GCD 间通信延迟：本地 HBM 访问延迟（从 CU 到本地 HBM）约 200–300 ns，跨 GCD 访问需经 Infinity Fabric 链路，延迟增加约 100–200 ns，形成 NUMA（Non-Uniform Memory Access）拓扑。软件需感知这一拓扑，通过 NUMA-aware 的内存分配策略将数据尽量放置在其消费者所在的 GCD 本地 HBM 中，避免跨 GCD 频繁访存。

两个 GCD 各自维护独立的 L2 缓存（各 8MB），通过片间协议实现缓存一致性探测（cache snooping）：当 GCD0 的 L2 miss 需要的数据可能驻留在 GCD1 的 L2 中时，GCD0 经 Infinity Fabric 向 GCD1 发送 probe 请求，GCD1 返回数据或 miss 响应。这一机制类似双路 CPU 的 cache coherency 协议，但增加了约数十 ns 的通信延迟。对于计算负载中常见的通信模式（如 bulk data transfer、all-reduce 的参数同步），400 GB/s 的 GCD 间带宽通常不构成瓶颈；但对于细粒度随机访问模式（如稀疏矩阵的指针追踪），NUMA 延迟增加可能导致有效吞吐下降。

MI250X 的 Infinity Fabric 外部链路（每 GCD 4 条 IF Link，共 8 条）用于多 GPU 互连和 GPU-CPU 互联，属于平台级互联范畴。在特定平台配置中，MI250X 可开启 GPU-CPU 缓存一致性模式，GPU 与 CPU 共享页表、直接访问主内存，由硬件保证缓存一致性。这一特性简化了异构编程模型，但其实现依赖于平台级的 Infinity Fabric 和 EPYC CPU 支持，不属 CDNA 2 微架构核心范畴。

4.2.7 小结

CDNA 2 的演进由 CDNA 1 的三项瓶颈驱动。单 GCD 的 120 个 CU 已接近 7nm 单片面积极限，无法继续扩展规模，因此 CDNA 2 引入双 GCD MCM 封装（每 GCD 112 CU）突破晶圆尺寸约束。FP64 向量吞吐仅为 FP32 的一半且 Matrix Core 不支持 FP64，使 HPC 科学计算无法充分利用硬件，因此 CDNA 2 将 CU 内 FP64 向量单元加倍（16→32 FMA/SIMD/周期），并在 Matrix Core 中扩展 FP64 乘法器阵列（新增 256 FMA/CU/周期的 FP64 data path），使 FP64 稠密线性代数获得 MFMA 加速通路（VGPR → Matrix Core FP64 阵列 → Accumulator VGPR），无需回退到逐元素的 VALU 路径。这些改进的代价是：GCD 间 NUMA 延迟增加，软件需 NUMA-aware 分配；MCM 封装复杂度提升（硅桥、TSV、封装基板）；TDP 从 300W 增至 560W，散热要求相应提高。

CDNA 2 关键参数

4.3 CDNA 3

CDNA 3（2023 年发布，产品 AMD Instinct MI300 系列）是 CDNA 系列演进中最激进的一代。其微架构层面的核心变化包括：从 MCM 双 GCD 演进为 3D Chiplet 多 XCD + IOD 架构；引入 Infinity Cache 作为片上级末级缓存（LLC），重构缓存层次为四级结构；扩展 Matrix Core 的低精度支持（TF32、FP8、2:4 结构化稀疏）；以及首次在同一封装内集成 CPU（MI300A APU 配置）。

4.3.1 ISA

CDNA 3 的 LLVM target 为 gfx940（MI300A）、gfx941 和 gfx942（MI300X），三者共属同一 ISA 族但有细微 feature set 差异（主要体现在 APU 配置下的一致性域范围）。相对 CDNA 2（gfx90a），ISA 层面的变化集中在三个方向：FP8 矩阵指令引入、结构化稀疏指令引入、以及内存模型的弱一致性调整。

FP8 MFMA 指令。新增 V_MFMA_F32_16x16x32_FP8_FP8、V_MFMA_F32_32x32x16_FP8_FP8 等指令，A/B 矩阵以 OCP E5M2 或 E4M3 格式编码（8-bit 浮点），累加器为 FP32。FP8 乘法器面积约为 FP16 乘法器的 1/4，同面积可布置 4 倍并行通道，使 FP8 矩阵吞吐达到 FP16 的 2 倍（4096 vs 2048 FLOPs/CU/周期）。FP8 指令支持 A 矩阵与 B 矩阵使用不同子格式（如 A 用 E5M2、B 用 E4M3），这在混合精度训练中有实际用途（前向传播用窄范围高精度 E4M3，反向传播用宽范围 E5M2）。

TF32 的处理方式。AMD 官方 CDNA 页面标注 TF32 为"software emulation"。ISA 中不存在 TF32 专用 MFMA 指令。实际实现是通过截断 FP32 尾数至 10 bit 后以 FP32 通路执行，由编译器或库层完成截断。这与 NVIDIA 的硬件原生 TF32 通路不同。

结构化稀疏指令。新增支持 2:4 稀疏模式的 MFMA 变体（每 4 个元素中至少 2 个为零）。稀疏矩阵以压缩格式存储（非零值 + 2-bit 索引），Matrix Core 的输入逻辑解码索引后仅将非零操作数送入乘法器。这使 FP8 稀疏模式下峰值可达 8192 FLOPs/CU/周期。

内存模型调整。CDNA 3 将 L1 一致性域从全局收窄：L1 和 LDS 不再自动保持跨 CU 一致性，一致性责任上推至 L2。ISA 层面的体现是新增了更细粒度的 fence 指令和 scope 修饰：s_waitcnt 之外新增 s_waitcnt_vscnt（向量存储计数器），buffer_gl0_inv 和 buffer_gl1_inv 的语义区分本地和全局缓存失效范围。开发者或编译器需在跨 CU 通信点显式插入 L2 scope 的 fence，否则 L1 中的数据对其他 CU 不可见。

waitcnt 模型演进。延续 vmcnt/lgkmcnt/expcnt 三组计数器，但 vscnt（vector store count）成为跨 CU 可见性的关键计数器，写操作在 vscnt 归零后保证对 L2 可见。编译器需在 MFMA 写回与后续跨 CU 通信之间正确编码 vscnt 等待。

4.3.2 Scheduling

CDNA 3 的调度模型维持 Wave64 + per-SIMD wave scheduler 的基本架构，但多 XCD 的 Chiplet 拓扑对全局调度引入了新的层次。

XCD 内部调度。每个 XCD 含 38 个 CU（完整设计），每 CU 4 个 SIMD16，调度逻辑与 CDNA 1/2 一致。每 SIMD 最多驻留 10 个 wavefront，每 CU 最多 40 个。调度器从 active 队列中按 round-robin 或 oldest-first 策略选择就绪 wavefront 发射。

XCD 间的 workgroup 分配。Command Processor（位于 IOD）负责将 kernel dispatch 的 workgroup 分发到 8 个 XCD。分配策略由硬件实现：默认按 round-robin 将连续 workgroup ID 映射到不同 XCD，以均衡负载。若 kernel 的 workgroup 数量不是 XCD 数的整数倍，尾部 XCD 空闲时间无法被利用（称为 tail effect）。开发者可通过 workgroup 数量对齐来缓解。

弱一致性对调度的影响。L1 一致性域收窄为 CU 本地之后，跨 CU 的数据通信需经 L2 scope fence。workgroup 内跨 CU 的 barrier 同步（如 s_barrier + memory fence）的延迟增加，因为 fence 需等待 L1 write-back 到 L2，再触发其他 CU 的 L1 失效。典型影响场景是大 workgroup（占据多个 CU 的线程组）的 barrier 同步开销上升。CDNA 3 的 MI300X 在 ROCm 调优指南中建议将频繁同步的 workgroup 尺寸限制在单 CU 容量内（≤ 1024 线程 × Wave64 = 16 个 wavefront）。

Matrix Core 与调度的协调。MFMA 指令延迟在 CDNA 3 中随格式变化：FP8 MFMA 的延迟（约 16–32 周期）短于 FP64 MFMA（约 64 周期），因为 FP8 乘法器阵列宽度更大、pipeline 更短。调度器对 MFMA 指令不做特殊处理，它只是一条多周期指令，执行期间调度器可继续向同一 SIMD 发射其他类型指令（如 LDS 操作、标量指令）。FP8 kernel 中 MFMA 的短延迟使"等待 MFMA 完成"的窗口更小，对 overlap 的要求更高。

4.3.3 Execution Unit

CDNA 3 的 Matrix Core 在精度覆盖和操作效率上显著扩展。

TF32（Tensor Float 32）：10-bit 尾数 + 8-bit 指数格式，由 NVIDIA 在 Ampere 中提出，CDNA 3 跟随支持。TF32 矩阵吞吐 1024 FLOPs/CU/周期，与 FP32 等效。TF32 的定位是在矩阵乘法中兼顾 FP16 的速度和接近 FP32 的数值范围：TF32 的 8-bit 指数范围与 FP32 相同（可表示更大/更小的数值），10-bit 尾数精度介于 FP16（11-bit 有效）和 FP32（24-bit）之间，适合对精度敏感但可容忍少量舍入误差的训练场景（如梯度累积）。

FP8：支持两种格式（E5M2 和 E4M3，OCP 标准），矩阵吞吐 4096 FLOPs/CU/周期。FP8 的 4× 吞吐提升（对比 FP16 的 1024 FLOPs/CU/周期）来自 Matrix Core 内部将乘法器位宽减半后的面积和功耗释放：FP8 乘法器面积约为 FP16 乘法器的约 1/4，同面积下可布置 4 倍数量的并行乘法通道。MI300X 的 FP8 矩阵峰值约 2614 TFLOPS。AMD 官方规格页给出的整卡峰值与此口径一致：FP8（E5M2/E4M3）2.61 PFLOPS、FP16/BF16 1.3 PFLOPS，结构化稀疏下分别翻倍至 5.22 PFLOPS 与 2.61 PFLOPS，对应 304 个 CU、1216 个 Matrix Core 与 2.1 GHz 峰值引擎时钟。

2:4 结构化稀疏：要求每 4 个元素中至少有 2 个零（50% 以上稀疏率），Matrix Core 可成对处理非零数据，实现最高 2× 有效吞吐提升。即 FP8 稀疏模式下峰值可达 8192 FLOPs/CU/周期。稀疏加速的硬件实现方式是将零元素跳过而非执行乘零操作：Matrix Core 的输入逻辑检测 2:4 模式的压缩索引，仅将非零操作数送入乘法器阵列，节省乘法器功耗并允许更宽的并行发射。结构化稀疏要求权重矩阵在训练中以 2:4 模式剪枝，对模型精度有一定影响，需配合感知训练（aware training）或后处理微调。

精度扩展的代价是 CU 面积增加：TF32 和 FP8 乘法器需要独立的 datapath 和格式转换逻辑，2:4 稀疏需要额外的索引解码和路由逻辑。CDNA 3 通过 5nm 制程的密度提升部分抵消了这一面积增加。

SFU（Special Function Unit）吞吐翻倍，以匹配 Matrix Core 吞吐提升后 softmax、activation 函数的计算需求。在 Transformer 网络的 Attention 模块中，Q×K 矩阵乘法（由 Matrix Core 执行）后的 softmax 归一化（exp、sum、divide，由 SFU 和 VALU 执行）若速度不匹配，会形成 pipeline bubble。CDNA 3 的 SFU 增强缓解了这一问题。

每 CU 的标量 ALU 和分支控制逻辑也得到加强，支持更复杂的控制流（如动态计算图的条件执行、嵌套循环的间接跳转）。

4.3.4 Register File

CDNA 3 的寄存器文件配置相对 CDNA 2 有一项关键变化：VGPR 总容量从 512KB/CU 保持不变，但 AccVGPR 的地位正式化为独立寄存器空间，ROCm 文档标称 512KB VGPR per CU。

VGPR 配置。每 CU 4 个 SIMD × 128KB/SIMD = 512KB 总 VGPR（通用 VGPR + AccVGPR 共享物理空间）。每 SIMD 最大 256 个 32-bit VGPR × 10 waves 的配置不变。SGPR 文件每 CU 12.5KB。

AccVGPR 的扩展使用。CDNA 3 的 FP8 和稀疏 MFMA 指令均使用 AccVGPR 作为累加器目标。由于 FP8 MFMA 的操作数维度更大（32×32×16 或 16×16×32），单条指令消耗的 AccVGPR 数量更多（16×16 FP32 累加器 = 256 个 32-bit 寄存器 per wave）。开发者在手写 GEMM kernel 时需精细规划 AccVGPR 分配，避免累加器寄存器不足导致指令序列化。

寄存器压力与 occupancy 的工程权衡。MI300X 的 304 个 CU 意味着全芯片 VGPR 总量为 304 × 512KB ≈ 152MB。但每个 CU 的 occupancy 仍受单 SIMD 128KB 约束。FP8 矩阵 kernel 的典型 VGPR 使用量约 128–160 个/wave（含输入 tile、累加器、地址寄存器），对应每 SIMD 1–2 个 resident wave。低 occupancy 在 CDNA 3 中不如 CDNA 1/2 时代那样严重影响性能，因为 Matrix Core 的高吞吐可在少量 wave 下即饱和（矩阵运算的 arithmetic intensity 高到不需要频繁内存等待）。但对 memory-bound 的非矩阵 kernel（如 reduction、normalization），低 occupancy 仍直接导致 SIMD 利用率不足。

L1 cache line 加宽对 VGPR load 的影响。CDNA 3 的 L1 cache line 从 64B 增至 128B，单次 L1 miss 填充的数据量翻倍。对于连续 VGPR load（如矩阵 tile 的行/列加载），128B line 可在一次 miss 中覆盖 32 个 FP32 VGPR 或 64 个 FP16 VGPR 的数据，减少 miss 次数和填充延迟。

4.3.5 Memory Subsystem

CDNA 3 的缓存层次重构是 CDNA 1–4 中变化最大的部分（CDNA 5 的重组另当别论），从 CDNA 1–2 的三级结构扩展为四级：

L1 数据缓存：每 CU 32KB，128B cache line（从 CDNA 1/2 的 64B 翻倍），4-way set-associative。128B line 的动机来自 HPC 负载的访问模式分析：矩阵行/列读取、stencil 计算中的网格点访问通常具有强空间局部性，128B line 可在单次 miss 填充中带回更多连续数据，降低 miss rate 和填充开销。L1 到 L2 的总线宽度同步加倍，提升 miss 填充带宽。

L2 缓存：每 XCD 4MB，16-way，16 个并行通道（每通道 256KB），支持每周期 4 路并发读取、每路 128B，即 2KB/周期的读带宽。XCD 级 L2 承担三项职责：一是汇聚本 XCD 内所有 CU 的 L1 miss 请求；二是作为 XCD 间一致性探测的最低层缓存。CDNA 3 的一个重要变化是 L2 之下（L1 和 LDS）不再自动保持跨 CU 一致性，需要软件在需要时显式插入 memory barrier/fence。这种弱一致性模型下，L1 可在无需 snoop 其他 CU 的状态下高速运行，L2/LLC 负责解决跨 CU、跨 XCD 乃至 CPU 的数据同步。这一设计与 CDNA 1–2 的全局 L1 coherence 不同，后者在每次 L1 write 时触发跨 CU 的 invalidation/snooping，在 120+ CU 的规模下 snoop 流量成为瓶颈。CDNA 3 通过将一致性责任上推至 L2，释放了 L1 的带宽和功耗。

Infinity Cache（LLC）：4 个 IOD 各集成 64MB，总计 256MB。Infinity Cache 定位为"memory-side cache"：仅缓存 HBM3 中的数据，不接收来自下层 L2 的 write-back 脏数据。这一定位意味着 LLC 与 HBM 控制器紧耦合，功能类似 CPU 架构中的 L4 cache，其设计目标是降低 HBM3 访问频率、提升有效带宽。Infinity Cache 内置跨 XCD snoop filter：当某 XCD 的 L2 miss 需要的数据可能驻留在另一 XCD 的 L2 中时，先在 Infinity Cache 中查询共享状态（coherence directory），若命中则直接返回数据，避免直接触发远端 XCD 访问。

从 data path 角度看，一次完整的 CU → memory 访问经过以下路径：

1. CU 发起 load/store → L1（32KB）hit：直接返回，延迟约 10–20 周期。
2. L1 miss → L2（4MB/XCD）hit：经 XCD 内部 crossbar 路由到对应 L2 channel，延迟约 100–200 周期。
3. L2 miss → Infinity Cache（256MB）hit：经 XCD → IOD 路由，LLC tag 匹配后从 IOD SRAM 返回数据，延迟约 300–500 周期。
4. LLC miss → HBM3：经 IOD 内存控制器，HBM3 row activate → column read → 返回数据，延迟约 500–800 周期。

四级缓存的关键设计参数决定了各级对不同类型负载的效率：对于模型参数可部分放入 LLC 的 AI 推理（如数十亿参数的 Transformer），LLC hit 可将延迟从 500–800 周期降至 300–500 周期，同时减轻 HBM3 带宽压力；对于数据重用度低的流式计算（如 Monte Carlo 模拟），LLC 作用有限，HBM3 带宽成为硬约束。

HBM3：MI300 系列配置 8 堆 HBM3，MI300X 容量 192GB，MI300A 容量 128GB。HBM3 的 pin 速率约 4.8 Gbps/pin，较 HBM2e（3.2 Gbps）提升 50%，单堆带宽提升约 50%。8 堆 HBM3 的总线宽度为 8192-bit（8 × 1024-bit），MI300A 带宽约 5.3 TB/s。HBM3 的堆叠层数增至 12 层，单 die 容量提升使总容量可达 192GB（MI300X）。

4.3.6 封装与互联

CDNA 3 摒弃了 CDNA 2 的双 GCD MCM 方案，改用更细粒度的 Chiplet 分解，动机是进一步提升集成规模并优化不同功能模块的工艺适配。

• XCD（Accelerator Complex Die）：计算 die，每片含 38 个 CU（完整设计），5nm 制程。MI300X（纯 GPU 配置）含 8 个 XCD，共 304 个 CU（部分 SKU 屏蔽至 228 个活跃 CU）。
• IOD（I/O Die）：有源中介层 die，6nm 制程，负责 HBM3 内存控制器、Infinity Cache、Infinity Fabric 接口、电源管理和 XCD 间一致性协调。MI300X 含 4 个 IOD，每 IOD 管理 2 个 XCD。

XCD 与 IOD 之间通过硅中介层（silicon interposer）的密集金属走线互联，物理上采用 2.5D/3D 混合封装。与 CDNA 2 的 MCM 相比，XCD + IOD 分解的核心优势在于工艺解耦：计算逻辑（XCD）可在最先进节点（5nm）上压缩面积和功耗，而 I/O 和缓存逻辑（IOD）可在成本较低的节点（6nm）上实现更大的 SRAM 容量（Infinity Cache 需要大量 SRAM 面积，在 6nm 上实现的每 MB 成本低于 5nm）。每个 XCD 保持独立 CU 阵列和本地 L2 缓存，但全局内存请求统一路由到 IOD 的 HBM3 内存控制器和 Infinity Cache。

XCD 间通信路径：同一 IOD 下的两个 XCD 通过 IOD 内部 crossbar 通信，跨 IOD 的 XCD 间通信经 IOD-to-IOD 互联。最坏情况下，XCD A 到 XCD B（不同 IOD）的通信需经 XCD-A → IOD-A → IOD-B → XCD-B 三段路由，延迟高于 CDNA 2 的 GCD 间直接 Infinity Fabric 链路。但 XCD 数量增加（从 2 GCD 到 8 XCD）提供了更大的并行度扩展空间。

CDNA 3 同时推出 MI300A（APU 配置），在同一封装内集成 6 个 XCD（共 228 个 CU）和 3 个 Zen 4 CPU CCD（共 24 核），共享 128GB HBM3 和 256MB Infinity Cache。CPU 与 GPU 通过片上 Infinity Fabric 互联，由 IOD 的 CM（Coherence Manager）和 CS（Cache Snooper）模块协调缓存一致性。APU 形态消除了传统 PCIe 互联方案中 CPU-GPU 间 >10 µs 的通信延迟和 ~32 GB/s 的带宽瓶颈，CPU 线程可直接访问 GPU HBM 中的数据，GPU kernel 也可直接访问 CPU 内存。但 MI300A 的固定功耗预算（TDP 约 550W）需在 24 核 CPU 和 228 个 CU GPU 之间分配，实际可用 GPU 功耗低于 MI300X，峰值 FP16 矩阵吞吐相应降低。

4.3.7 小结

CDNA 3 的改进直接回应 CDNA 2 的三项瓶颈。双 GCD MCM 方案无法进一步扩展（超过 2 片 GCD 的封装复杂度激增），因此 CDNA 3 转为 8 XCD + 4 IOD 的细粒度 Chiplet 架构。HBM2e 带宽（3.2 TB/s）在 383 TFLOPS FP16 矩阵峰值下已接近 memory-bound，CDNA 3 引入 256MB Infinity Cache 作为独立 LLC 层，将 L2 角色从"大容量缓存"转变为"一致性汇聚层 + 带宽放大器"，同时将 L1 cache line 从 64B 增至 128B。缺少 FP8/TF32 导致大模型训练效率不及竞品，CDNA 3 在 Matrix Core 中扩展 TF32/FP8 乘法器和 2:4 稀疏处理逻辑，稀疏模式下可通过 zero-skip 绕过部分乘法器；L1 在弱一致性模型下无需跨 CU snoop，本地带宽提升。代价是：XCD 间一致性需经 IOD 路由，最坏情况延迟高于 GCD 内通信；弱一致性模型要求软件显式管理 L1 一致性（插入 fence/barrier）；Chiplet 封装的热密度和功耗管理复杂度增加（MI300X TDP 约 750W）。

CDNA 3 关键参数

4.4 CDNA 4

CDNA 4（2024–2025 年，产品 AMD Instinct MI350 系列）在 CDNA 3 的 Chiplet 基础上进行架构重组和精度重定义。核心设计方向：矩阵运算吞吐在低精度（FP8 及以下）上再翻倍，引入 MXFP（Microscaling Floating Point）格式族，同时策略性降低 FP64 矩阵运算吞吐，将有限硬件预算向 AI 训练/推理倾斜。旗舰 SKU MI355X 含 8 个 XCD、2 个 IOD、约 256 个 CU、288GB HBM3E，TDP 高达 1400W。

4.4.1 ISA

CDNA 4 的 LLVM target 为 gfx950，延续 GFX9 ISA 族但引入了 MXFP 相关的指令扩展。

MXFP 格式的 ISA 支持。MFMA 指令族新增 MXFP4、MXFP6、MXFP8 操作数类型。MXFP 指令的编码在标准 MFMA 格式基础上扩展了缩放因子字段（scale descriptor），每条指令额外指定一组 SGPR 地址用于加载块缩放因子。缩放因子格式为 E8M0（8-bit，仅含指数位），以 32 元素为一个 block 共享一个缩放因子。硬件在 MFMA 执行前自动将 MXFP 尾数按缩放因子解压为内部宽格式，解压不占用 VALU 或额外周期。

OCP Microscaling 标准对齐。CDNA 4 的 MXFP 实现严格遵循 OCP（Open Compute Project）定义的 Microscaling 标准，包括 block size 32、缩放因子 E8M0、以及 FP8 的 E5M2/E4M3 两种子格式。这使 CDNA 4 的低精度训练/推理结果可与其他遵循 OCP 标准的加速器（如后续 Intel Gaudi 系列）在数值上保持一致性。

SCOPE hint 扩展。CDNA 4 在内存指令中引入 SCOPE hint 位（对应文档中的 sc0/sc1/nt 修饰符扩展），允许编译器向缓存控制器声明该内存操作的一致性需求范围。scope 从窄到宽分为：wavefront-local → workgroup-local → agent（全 GPU）→ system（含 CPU）。窄 scope 的操作不触发更高层级的 snoop 或 flush，减少缓存一致性开销。这一机制将缓存一致性的管理粒度从"全局 fence 或无 fence"细化到逐条指令级别。

其他指令改动。SFU 指令的吞吐翻倍由硬件实现（非 ISA 语义变化，但 LLVM 的指令延迟表需要更新）。Packed math 指令（V_PK_*）扩展到更多 FP16/BF16 操作组合。

4.4.2 Scheduling

CDNA 4 的调度模型维持 Wave64 + per-SIMD wave scheduler，与 CDNA 1–3 一脉相承。调度器的核心改进围绕 Matrix Core 吞吐翻倍后如何维持流水线满载。

Matrix Core 占用时间缩短。CDNA 4 的 MXFP4 Matrix Core 每周期处理的操作数量是 CDNA 3 FP8 的 2–4 倍，但单条 MFMA 指令的 pipeline 延迟并未同比增加（仍约 16–32 周期）。每条 MFMA 指令完成后下一条可更快发射，调度器看到的"MFMA 占用窗口"缩短。对 overlap 的影响：留给 LDS/memory 操作插入的窗口变窄，kernel 需要更精确的指令交错（interleaving）来维持 overlap。

SFU 吞吐翻倍的调度含义。SFU 在 CDNA 3 中是 softmax 流水线的瓶颈（MFMA 完成后 SFU exp/sum 跟不上）。CDNA 4 SFU 吞吐翻倍后，exp/log 指令的延迟减半，调度器可更快释放 SFU 依赖的 wavefront。"MFMA → SFU → MFMA"这类 Attention 层的典型指令序列在 CDNA 4 上的流水线 bubble 明显缩减。

IOD 数量减半对调度的间接影响。CDNA 4 从 4 IOD 减为 2 IOD，每 IOD 管理 4 个 XCD。Command Processor 到 XCD 的 workgroup 分发路径缩短（跳过一级 IOD 间路由），dispatch 延迟降低。但单 IOD 的仲裁压力增大（需同时服务 4 个 XCD 的内存请求），在 memory-bound 负载下 IOD crossbar 可能成为带宽瓶颈。

LDS 带宽与调度。MFMA 的操作数来自 VGPR，VGPR 的 tile 数据来自 LDS。LDS 带宽不足时 VGPR 等待 LDS read 完成，MFMA 因操作数未就绪而无法发射，调度器被迫选择其他 wavefront。CDNA 4 的 LDS 带宽提升（bank 并行度增加）缓解了这一链条中的等待，使 Matrix Core 更容易维持峰值利用率。

4.4.3 Execution Unit

CDNA 4 的矩阵运算改进集中在精度格式创新和操作数并行度提升两方面。

MXFP 格式族：CDNA 4 引入 Microscaling Floating Point（MXFP）格式，包括 MXFP8、MXFP6 和 MXFP4。MXFP 将一组数值（如一个 32 元素向量块，称为"microvector"或"block"）共享一个缩放因子（scale factor，通常为 FP8/E8M0 格式），每个元素仅存储尾数部分（8/6/4 bit），缩放因子在 microvector 粒度上统一应用。这种块级缩放（block scaling）相比逐元素缩放减少了指数位的重复存储：在 MXFP4 中，每 32 个元素仅需一个 8-bit 缩放因子（覆盖全组），32 个元素各存 4-bit 尾数，总计 136 bit（含缩放因子），而 FP4 逐元素格式需要 32 × (1+2+1) = 128 bit（4-bit 含符号、指数、尾数），块缩放的额外开销仅 8 bit，但数值范围远大于固定 FP4。

MXFP 的硬件实现：Matrix Core 在执行 MXFP 运算时，先从内存加载缩放因子和尾数块，在输入乘法器前将尾数按缩放因子还原为内部宽格式（如 FP16 或 FP32），执行乘累加后再按输出缩放因子量化。CDNA 4 的 Matrix Core 内置了 block scaling 的专用 datapath，缩放因子的加载和应用不占用额外 VGPR 或 VALU 周期。

CDNA 4 的 Matrix Core 对 MXFP4 提供每 CU 每周期 16384 次操作（含缩放因子的应用和解缩放），整卡 MI355X 的 FP4 矩阵峰值约 10 PFLOPS。对比 CDNA 3 的 INT8 峰值 2614 TFLOPS，CDNA 4 在 4-bit 精度下实现了约 3.8× 的吞吐提升。MXFP6 和 MXFP8 的吞吐按位宽比例递减（MXFP6 约 2/3 的 MXFP4 吞吐，MXFP8 约 1/2）。

FP8/FP16 提升：CDNA 4 通过 Matrix Core 设计优化（更宽的乘法阵列 + 更高工作频率），FP16/INT8 矩阵吞吐相对 CDNA 3（MI325X）提升约 1.9×。MI355X 的 FP8 峰值约 5 PFLOPS（密集模式），支持 2:4 结构化稀疏后峰值可达 10 PFLOPS。FP16/BF16 峰值约 2.5–5 PFLOPS（取决于稀疏模式）。

FP64 矩阵策略性降低：CDNA 4 的 FP64 矩阵峰值约 78.6 TFLOPS（MI355X），约为 CDNA 3（MI325X，163.4 TFLOPS）的 0.48×。这一取舍的硬件原因清晰：Matrix Core 的 FP64 乘法器面积远大于低精度乘法器（FP64 乘法器面积约为 FP16 的约 4–6 倍），在 CU 面积固定的情况下，增加 FP8/MXFP 通路需占用原本分配给 FP64 乘法器的面积。CDNA 4 选择将更多硅面积分配给 FP8/MXFP 乘法器阵列，牺牲 FP64 矩阵通路的规模。但 FP64 向量 ALU 仍维持全速（每 CU 每周期 64 FMA），传统 HPC 科学计算中不依赖矩阵单元的负载（如偏微分方程求解、Monte Carlo 模拟、粒子输运）不受影响。FP64 矩阵吞吐的降低主要影响依赖 DGEMM 的稠密线性代数库（如某些 LAPACK 例程），这些负载在 CDNA 4 上若无法利用 FP64 矩阵通路，则需回退到 FP64 向量通路执行（当前公开资料未明确排除 FP64 MFMA 存在，但 FP64 矩阵吞吐相对前代确有下降）。

为避免矩阵吞吐显著提升后辅助运算成为瓶颈，CDNA 4 的 SFU 吞吐相对 CDNA 3 提升约 2×，覆盖 exp、log、rcp、sqrt 等超越函数。Transformer 网络中 Attention 模块的"矩阵乘法 → softmax → 矩阵乘法"流水线中，softmax 的 exp 和归一化运算若速度不足，会形成 pipeline bubble，限制有效吞吐。CDNA 4 的 SFU 增强使 softmax 计算速度与矩阵乘法匹配。

标量处理器新增矩阵指令辅助功能：Matrix Core 的部分和（partial sum）可直接输出到标量通路（经专用 bypass 总线）供后续非线性计算使用，减少 VGPR 中转和显式 load/store 指令。这一 datapath 优化对于"矩阵乘法 → bias add → activation"的常见神经网络层序列可减少数条指令和数百周期的延迟。

4.4.4 Register File

CDNA 4 的寄存器文件配置延续 CDNA 2/3 的结构：每 CU 4 个 SIMD × 128KB/SIMD = 512KB VGPR 总量。每 wave 最多 256 个 32-bit VGPR（含 AccVGPR 共享空间），SGPR 文件 12.5KB/CU。

MXFP 对寄存器的影响。MXFP4 操作数位宽极窄（4-bit），但 MFMA 指令的输入仍以 32-bit VGPR 为单位组织，每个 VGPR 可打包 8 个 FP4 元素。一条 V_MFMA_F32_32x32x64_FP4 指令需要的 A 矩阵输入为 32×64 = 2048 个 FP4 元素，占用 2048/8 = 256 个 VGPR（恰好用满单 wave 的全部 VGPR 容量）。FP4 kernel 的 tile 尺寸选择因此受寄存器容量硬性约束：32×32 tile 需要 128 VGPR，32×64 需要 256 VGPR，更大 tile 不可行。

块缩放因子的寄存器开销。MXFP 指令的缩放因子通过 SGPR 传入（每 32 元素一个 8-bit 缩放因子）。一个 32×64 的 A 矩阵 tile 含 2048 个元素，需要 2048/32 = 64 个缩放因子。这些缩放因子从内存加载到 SGPR，不占用 VGPR，但 SGPR 文件容量有限（每 CU 12.5KB），大 tile 的缩放因子可能导致 SGPR 压力。实际中编译器通过分批加载和复用策略管理。

occupancy 在 CDNA 4 中的新平衡。CU 从 38 减至 32 个但 Matrix Core 吞吐大幅提升（FP8 5 PFLOPS vs CDNA 3 2.6 PFLOPS），意味着单 CU 的矩阵计算密度更高。高 arithmetic intensity 的 GEMM kernel 只需少量 resident wavefront 即可饱和 Matrix Core（1–2 个 wave/SIMD 即可维持峰值），低 occupancy 不再是性能问题。但 memory-bound 的非 GEMM kernel（如 layer normalization、element-wise operations）仍需高 occupancy 来隐藏延迟，这类 kernel 应使用少量 VGPR 以最大化 wave 驻留数。

4.4.5 Memory Subsystem

LDS：CDNA 4 的每 CU LDS 维持 64KB，但带宽和 bank 并行度有所提升（AMD 未完全公开微架构细节）。WMMA（Wave Matrix Multiply-Accumulate）执行时，A/B 矩阵子块从 HBM3E → L2 → L1 → VGPR 加载，计算中间结果经 LDS 在 wavefront 间共享和复用。LDS 带宽不足会导致 Matrix Core 等待操作数，形成 backpressure，LDS 带宽提升直接决定 Matrix Core 能否维持峰值利用率。

L2 和 Infinity Cache：每 XCD L2 维持约 4MB。Infinity Cache 容量为 256MB（2 × IOD × 128MB 或等效组织），与 CDNA 3 保持一致，以匹配更大规模模型参数集的缓存需求。LLC 容量增加的直接动机是大模型推理中的权重缓存：一个 700 亿参数的 FP16 模型约需 140GB 存储，远大于任何片上缓存容量，但模型在单次前向传播中按层顺序访问权重，当前层的权重（数 GB）可部分缓存在 LLC 中，LLC hit 可减少 HBM 访问。

HBM3E：MI355X 配置 8 堆 HBM3E，容量 288GB，总带宽 8.0 TB/s。HBM3E 对比 HBM3 的带宽提升约 50%，pin 速率约 6.4 Gbps/pin，堆叠层数可达 16 层。288GB 的容量使 MI355X 可在单卡上容纳更大规模的模型（如 700 亿参数 FP16 模型约 140GB，留有余量用于激活和 KV cache）。

8 TB/s 的 HBM3E 带宽对比 FP8 矩阵峰值 10 PFLOPS 的 arithmetic intensity 约为 1250 FLOP/byte。典型 AI 负载的 arithmetic intensity：稠密 GEMM 约为数百到数千 FLOP/byte（取决于 tile 尺寸），注意力机制约为数十到数百 FLOP/byte。HBM 带宽在 attention 机制中通常是瓶颈，CDNA 4 通过 Infinity Cache 缓存 KV cache 和 LDS 复用计算中间结果来缓解。

4.4.6 封装与互联

CDNA 4 维持 XCD + IOD 的 Chiplet 分解，但 IOD 数量从 4 个减为 2 个，每个 IOD 管理 4 个 XCD 和对应的 HBM3E 内存堆栈。IOD 数量减半的工程动机是简化互连拓扑、降低 XCD-IOD 通信延迟：CDNA 3 中 8 个 XCD 与 4 个 IOD 的互连需要较复杂的 crossbar 或 ring 路由，而 CDNA 4 中每个 IOD 只需服务 4 个 XCD，路径更短、仲裁更简单。代价是每个 IOD 的面积和功耗增加（管理更多 XCD 意味着更大的 crossbar 和 coherence directory）。

MI350 系列配置 8 个 XCD，每 XCD 含约 32 个 CU（从 CDNA 3 的 38 个减少），整卡共约 256 个 CU。CU 数量减少但单 CU Matrix Core 规模增大，属于"用强核替换部分核"的面积重分配策略。这一策略的合理性来自矩阵吞吐的 CU 级效率提升：若单 CU Matrix Core 吞吐提升超过 CU 数量减少的比例，整卡峰值仍可增加。MI355X 的实际数据表明这一策略成功：尽管 CU 从 304 减至 256（减少 15.8%），FP8 矩阵吞吐从 2614 TFLOPS 增至 10 PFLOPS（提升约 282%）。

4.4.7 小结

CDNA 3 的 FP8 矩阵吞吐（2614 TFLOPS）在千亿参数级 GPT 模型训练中仍不够用（batch size 受限），HBM3 带宽（5.3 TB/s）与矩阵吞吐的 arithmetic intensity 也不匹配。CDNA 4 的应对方式是将每 CU Matrix Core 乘法阵列加宽，新增 MXFP4/6/8 处理逻辑和 block scaling datapath，并将每 XCD CU 数量从 38 减至 32 以释放面积给 Matrix Core。IOD 数量从 4 减至 2，简化互连拓扑。数据通路新增 MXFP4/6/8 路径（含块缩放因子的加载、解压和应用），SFU 吞吐翻倍以匹配矩阵后的 softmax/activation 流水线，标量通路可直接消费 Matrix Core 部分和输出（bypass 总线）。HBM3 升级为 HBM3E（pin 速率 4.8→6.4 Gbps/pin）。代价是 FP64 矩阵吞吐减半（面积重分配至低精度通路），每 IOD 热密度增加，288GB HBM3E 容量成本高于前代，TDP 从 750W 增至 1400W，散热从风冷升级为液冷。

CDNA 4 关键参数

4.5 CDNA 5

CDNA 5（2026 年 7 月发布，产品 AMD Instinct MI400 系列）是 CDNA 产品线上架构范式的断裂点。此前四代 CDNA 的执行模型都建立在 GCN 的 Wave64 + CU 结构之上，CDNA 5 同时放弃了这两者：执行宽度从 Wave64 转为 Wave32，计算单元从 CU 转为 WGP（Work Group Processor）。这不是渐进式改良，RDNA 的执行模型被引入纯计算架构，CDNA 与 RDNA 在执行层面的公共基座从这里开始对齐。旗舰 SKU MI455X 含 8 个 XCD（2nm）、2 个 FCD（Fabric and Cache Die，3nm）、2 个 IOD（3nm），320 亿晶体管，432GB HBM4，TDP 未公开但为直液冷设计。

4.5.1 ISA

CDNA 5 使用全新的 ISA（AMD 已于发布一周后公开完整的 832 页 ISA 参考手册），与前代 GFX9 系 ISA 存在断代级差异。

Wave32 执行模型。所有指令以 32 线程为一个 wavefront 执行，映射到单个 32-lane SIMD 上，单周期发射完成。VOPD（Vector Operand Packed Dual）双发射指令仅在 Wave32 下合法。这与 CDNA 1–4 的 Wave64（4 周期完成一轮）形成根本性断裂：ISA 层面上 CDNA 5 不再支持 Wave64 编码。

WMA 指令族替代 MFMA。矩阵乘加指令从 V_MFMA_* 更名为 V_WMA_*（Wave Matrix Multiply-Accumulate），语义不变（D = A × B + C），但操作数条带化映射按 Wave32 的 32 lane 分布。WMA 指令覆盖的格式完整：FP32（16×16×4）、FP16/BF16（16×16×32）、FP8/BF8（16×16×64 和 16×16×128）、FP4/FP6（16×16×128 带块缩放）。FP8 与 BF8 可在同一条指令中混用（A 矩阵 FP8、B 矩阵 BF8）。新增 V_WMA_SCALE_* 变体支持 MXFP4/MXFP6/MXFP8 的块缩放（block-scale 16/32 和 fractional scaling）。

结构化稀疏指令。VSWMAC_*（Sparse Wave Matrix Multiply-Accumulate）支持 2:4 结构化稀疏，稀疏 A 矩阵 × 稠密 B 矩阵，累加器为 16×16 FP32。

超越函数增强。新增原生 tanh 指令（此前需用 exp 组合近似），超越函数单元（SFU）吞吐相对 CDNA 4 翻倍。softmax 和 activation 计算的瓶颈因此进一步缓解。

数据格式转换指令。大量新增 FP8↔FP16↔FP32↔BF16 的 pack/unpack/convert 指令，用于 tensor 在不同精度间的快速格式搬运。新增原生 BF16 向量数据类型支持。

指令预取机制。由于 CDNA 5 采用激进的指令预取，所有 shader 末尾必须额外填充 64 个 DWORD（256 字节）的 padding，官方建议用 S_CODE_END 指令填充，否则预取硬件可能读到未初始化的内存。

4.5.2 Scheduling

WGP 内含 4 个 32-lane SIMD 单元和 4 个标量单元（SALU），共享常量缓存。每个 WGP 最多同时驻留 32 个 workgroup（每 workgroup 最多 1024 work-item），最多 64 个 resident wave，是 CDNA 4 每 CU 驻留 wavefront 数的两倍。更多 resident wave 给调度器更多独立工作片段来隐藏内存延迟。

Wave32 的调度优势：指令延迟更短（单周期 vs. 四周期）；分支发散代价更低（至多 32 线程停顿而非 64）；寄存器压力更小（每 wave 消耗的 VGPR 减半），使更多 wave 同时驻留。

4 个 SIMD 可并发执行（co-execute）：一个 SIMD 启动新指令的同时，早先启动的多周期操作在另一个 SIMD 的下层流水线中排空。packed vector 指令可在单次发射中携带 64 线程的工作量（两个 Wave32 背靠背打包），这使 SIMD 在纯向量负载下的有效吞吐与 Wave64 时代持平。

4.5.3 Execution Unit

向量 ALU。每个 WGP 含 4 个 SIMD32，每 SIMD 每周期 256 个 packed FP32 操作（含 32 lane × 8 的打包模式）。新增原生 BF16 向量通路。

Matrix Core（WMA 引擎）。每个 WGP 含 4 个矩阵单元，每单元每周期 8192 个 FP4 操作（或 4096 个 FP8/BF8 操作），WGP 级矩阵吞吐为 65536 个 FP4 ops/周期。整卡 MI455X（256 WGP，2.4 GHz）的峰值：

相对 CDNA 4（MI355X），MXFP4/MXFP8 峰值均为 4× 提升。FP64 矩阵和向量吞吐各为 5 TFLOPS，远低于 CDNA 4 的 78–82 TFLOPS。CDNA 5 在 FP64 上的策略性削减比 CDNA 4 更彻底，HPC 科学计算负载转由专门的 MI430X SKU 承载（MI430X 计划 2027 年发布，将启用更多 FP64 通路）。

超越函数单元（SFU）。吞吐相对 CDNA 4 再翻倍（连续两代翻倍），新增原生 tanh 指令。softmax、GELU、SiLU 等激活函数的计算速度与矩阵单元匹配。

4.5.4 Register File

每个 SIMD32 配置 128KB 向量寄存器文件，单个 wave 最多可寻址 1024 个 32-bit VGPR，是 CDNA 4 每 wave 256 个 VGPR 的 4 倍。寄存器带宽同步翻倍。

更大的 per-wave VGPR 容量意味着 kernel 可以在不 spill 的情况下持有更大的 tile 或更多中间结果（如整个 attention head 的 KV 缓冲），减少 LDS/HBM 的中转。64 个 resident wave × 每 wave 1024 VGPR 的配置使 WGP 总寄存器容量达到 4 × 128KB = 512KB 向量寄存器。

标量寄存器（SGPR）：每 WGP 8KB 标量寄存器文件，用于地址计算、循环计数器和块缩放因子等全 wave 共享数据。

4.5.5 Memory Subsystem

CDNA 5 的存储层次经历了一次从上到下的重建，最大变化是删除了 Infinity Cache 并以大容量 L2 替代。

WGP 本地存储。每 WGP 384KB（320KB LDS + 64KB 向量数据缓存），LDS 带宽翻倍。一个 workgroup 可申请最多 320KB 的 LDS。全 GPU 合计 96MB LDS。LDS 与向量缓存的容量可在一定范围内动态重分配。

指令/常量缓存。每 WGP 64KB 指令缓存 + 16KB 常量缓存。

L2 缓存（Global L2）。分布于 2 个 FCD（Fabric and Cache Die），每 FCD 96MB，合计 192MB，聚合带宽 54 TB/s。L2 按 96 个 1MB block 组织，可缓存 GPU 内存中的任意地址。两个 FCD 的 L2 通过中央 Infinity Fabric 保持一致性。

删除 Infinity Cache。CDNA 4 的 256MB Infinity Cache 在 CDNA 5 中不复存在。替代逻辑：192MB L2（分布在 FCD 上，物理上紧邻 HBM4 控制器）的单块带宽已达 CDNA 4 整个 Infinity Cache 的 1.5 倍，两块合计带宽为 3 倍。AMD 的设计判断是：在 HBM4 带宽已达 23.3 TB/s 的前提下，memory-side LLC 的边际收益下降，不如把晶体管预算分配给更大的 per-WGP 本地存储（96MB LDS）和更宽的 L2。

HBM4。12 堆 HBM4，每堆 2048-bit 接口（是 HBM3E 的 1024-bit 的两倍），合计 24576-bit 总线。容量 432GB，峰值带宽 23.3 TB/s（是 CDNA 4 的 8 TB/s 的 2.9 倍）。HBM4 的物理接口宽度翻倍是本代带宽跃升的主要来源。

Tensor Data Mover（TDM）。每对 SIMD 旁配备一个 TDM 单元，负责 LDS 与 HBM/L2 之间的结构化张量数据批量搬运。TDM 新增 LDS↔DRAM 直接传输能力，无需经过 VGPR 中转，减少数据搬运的寄存器和指令开销。

组播内存操作（Multicast Load）。单次内存读取可同时广播至多个 WGP，减少对同一权重/参数的冗余内存流量。对 AI 推理中所有 WGP 同时读取相同模型权重的场景，组播可将有效内存带宽利用率提升数倍。

4.5.6 封装与互联

Chiplet 构成。MI455X 采用 CoWoS-L 先进封装 + 3D 混合键合（hybrid bonding）。物理组成：

• 8 个 XCD（Accelerator Complex Die）：2nm GAA 工艺（TSMC N2），每 XCD 含 2 个 Shader Engine、32 个 WGP。3D 混合键合堆叠在 FCD 之上。
• 2 个 FCD（Fabric and Cache Die）：3nm 工艺（TSMC N3P），每 FCD 含 96MB Global L2 缓存和 6 个 HBM4 堆栈的 192-channel 内存控制器。每 FCD 管理 4 个 XCD（即 8 个 Shader Engine）。
• 2 个 IOD（I/O Die）：3nm 工艺，包含 PCIe 6.0 控制器、AMD AI-NIC 接口、UALoE 链路控制器和 Infinity Fabric 互联。

拓扑。4 个 XCD 混合键合在每个 FCD 之上，两个 FCD 对称排列于封装中央，通过中间的 Infinity Fabric 通道互联。两个 IOD 分列封装两端。

Scale-up 互联：UALoE。每个 MI455X 配备 36 条 UALoE（Ultra Accelerator Link over Ethernet）链路（每 IOD 36 条 × 2 个 IOD = 72 lanes），单 GPU scale-up 带宽 3.6 TB/s（双向），是 CDNA 4 的 7 条 Infinity Fabric 链路（1.07 TB/s）的 3.4 倍。UALoE 基于开放的 UALink 标准，支持 72 个 GPU 组成单一共享内存域（AMD Helios 机柜配置）。

Scale-out 互联。每 GPU 支持最多 3 块 AMD Pensando Vulcano 800 AI-NIC，提供 600 GB/s 双向 scale-out 带宽（是 CDNA 4 单 NIC 400 Gb/s 的 6 倍）。

Host 接口。PCIe 6.0 x16 或 UALink x8（@128 Gb/s），以 Infinity Fabric 协议运行，提供 256 GB/s 双向硬件一致性带宽连接 EPYC Venice CPU。

4.5.7 小结

CDNA 5 的改动由 CDNA 4 的四项瓶颈驱动。Wave64 在 AI 推理中延迟过高（单 wavefront 4 周期完成），小 batch / 低并行度场景 SIMD 利用率不足，因此 CDNA 5 将执行模型切换为 Wave32/WGP，单周期完成一轮发射。CU 结构的 16-lane SIMD × 4 组织限制了指令并行性，WGP 内 4 个 32-lane SIMD 的新布局释放了更多并发空间。HBM3E 带宽 8 TB/s 在 10 PFLOPS 矩阵吞吐面前仍为瓶颈，CDNA 5 升级为 12 堆 2048-bit HBM4（23.3 TB/s），同时删除 Infinity Cache，以 FCD 上的 192MB Global L2 替代。scale-up 方面，7 条 IF 链路被 36 条 UALoE 链路替代（3.6 TB/s），72 GPU 可组成单一共享内存域。数据通路上，矩阵指令从 MFMA 更名为 WMA，操作数按 Wave32 重映射；TDM 支持 LDS↔DRAM 直传；新增组播加载减少权重冗余流量。代价是 FP64 矩阵和向量均降至 5 TFLOPS（面积全面倾斜至低精度 AI），GCN 执行模型的 15 年延续性断裂，老 kernel 需重新编译，散热复杂度进一步提升（直液冷 + EAM 模块形态）。

CDNA 5 关键参数

CDNA 5 的 Wave32 转向终结了 GCN 执行模型，但这是 UDNA 统一路径上的验证阶段，不是统一本身。

GCN 的 Wave64 执行模型从 2012 年的 Tahiti 开始，跨越整个 GCN 时代（5 代）和全部 CDNA 1–4，在 AMD 的计算架构中存活了 15 年。CDNA 5 放弃 Wave64、转为 Wave32，并将计算单元从 CU 切换为 WGP，这不是参数调整，而是执行范式的更替。从 ISA 层面看，CDNA 5 不再支持 Wave64 编码，老 kernel 需要重编译，VOPD 双发射等新指令仅在 Wave32 下合法。GCN 执行模型在 AMD 的全部产品线中不再有对应硬件，这个事实成立。

但执行模型统一不等于架构统一。CDNA 5 没有图形前端，没有光栅化引擎、没有 ROP、没有显示控制器、没有 RT Core。RDNA 4 没有大规模 Matrix Core 阵列、没有 HBM、没有 rack-scale 互联。两者在功能模块层面的分歧没有缩小，只是底层执行基座对齐了。AMD 公开预告的 UDNA 是另一件事：一套硬件同时承载图形管线和计算矩阵通路，而非两条产品线各自向对方借一个子集。

这条验证路径的逻辑是渐进的。RDNA 2 引入 Wave32 + WGP 作为图形架构的标准执行模型（2020）。CDNA 3 的 MI300A APU 首次在同一封装内集成 RDNA 系 CCD 与 CDNA 系 XCD，验证了异构 die 间的 Infinity Fabric 一致性互联（2023）。RDNA 4 在 ISA 层引入了面向计算的 SCOPE hint 和增强型 waitcnt 模型，把一致性管理粒度拉近 CDNA。PS5 Pro 的定制 GPU 在 RDNA 2 基础上嫁接了 per-WGP AI SRAM 和专用矩阵指令，验证了图形架构承载 AI 加速通路的可行性。CDNA 5 在计算侧完成了对称动作：把执行模型从 GCN/Wave64 切到 RDNA/Wave32。每一步都是朝 UDNA 方向验证了一个具体的技术子集（一致性域、执行粒度、ISA 兼容性、异构封装），但没有任何一步是完整的统一。

CDNA 5 是这条验证路径上最关键的一步，因为它动了最底层的东西：执行模型。执行模型一旦对齐，上层的 ISA 编码格式、编译器后端、调度策略、寄存器分配逻辑都具备了统一的物理基础。但 UDNA 需要解决的不只是执行基座：图形管线的固定功能阶段以什么形式与矩阵通路共存？传统 Draw 语义在统一架构中是保留为一等原语还是退化为 Dispatch 的特化路径？资源绑定模型是 Descriptor Table 还是纯指针？这些问题在 CDNA 5 中连问都不需要问，因为它没有图形。真正的统一需要在同一块硅片上同时回答这些问题，那是 UDNA 的工作，不是 CDNA 5 的。

4.6 小结：CDNA 1–5 的演进因果链

4.6.1 五代演进的决策逻辑

CDNA 系列的演进可归纳为三个维度的递进：Matrix Core 精度覆盖、缓存层次深度、封装集成规模。这三个维度之间存在耦合约束：Matrix Core 吞吐增长要求缓存和内存带宽同步提升以维持利用率，而封装规模扩展又为更多 CU 和更大缓存提供了物理空间。

Matrix Core 精度覆盖的演进

从 FP16 到 MXFP4 的精度降级涉及数值格式、硬件乘法器面积、软件训练策略和模型精度保证的系统工程，远不止位宽缩减。CDNA 4 的 MXFP4 在 4-bit 下仍通过 block scaling 保持可用数值范围，其硬件代价是缩放因子的存储和加载带宽：每 32 个 MXFP4 元素需加载一个 8-bit 缩放因子，额外带宽开销约 8/(32×4) = 6.25%，相对可忽略。

缓存层次的四级化

CDNA 1–2 的缓存层次为 L1（32KB/CU）→ L2（8MB 全片）→ HBM，三级结构。CDNA 3–4 引入 Infinity Cache 作为 LLC，形成 L1（32KB）→ L2（4MB/XCD）→ Infinity Cache（256MB IOD）→ HBM 的四级结构。

Infinity Cache 的引入动机可从 arithmetic intensity 分析推导：CDNA 1 HBM 带宽 1.23 TB/s 对应 FP16 矩阵吞吐 184 TFLOPS，arithmetic intensity 约 150 FLOP/byte，典型 GEMM 的 intensity（约 100–1000 FLOP/byte，取决于 tile 尺寸）与 HBM 带宽大致匹配。CDNA 4 HBM 带宽 8 TB/s 对应 FP8 矩阵吞吐 10 PFLOPS，arithmetic intensity 约 1250 FLOP/byte，远超 HBM 带宽能支撑的 intensity，必须依赖 LLC 和 LDS 的数据复用来降低 effective memory traffic。Infinity Cache 的"memory-side cache"定位（只缓存 HBM 数据，不接收 L2 write-back）简化了 coherence 协议（无需处理 L2 write-back 的 dirty 数据），但要求工作集具有良好的时间局部性，而模型权重在推理中逐层读取、多次复用，恰好符合这一条件。

各级缓存的带宽关系：L1 → L2 的带宽约数百 GB/s/CU 级，L2 → Infinity Cache 的带宽约数十 GB/s/XCD 级，Infinity Cache → HBM 的带宽为 5.3–8.0 TB/s（整卡级）。带宽逐层递减但容量逐层增加，符合 cache hierarchy 的设计原则。

封装规模的演进

CDNA 1 单片 GCD（120 CU，7nm，die 面积约 700mm²）。CDNA 2 双 GCD MCM（220 CU，6nm GCD，每 GCD 约 700mm²，封装总面积更大）。CDNA 3 8 XCD + 4 IOD Chiplet（304 CU，5nm XCD，6nm IOD，硅中介层面积明显增大）。CDNA 4 8 XCD + 2 IOD Chiplet（256 CU，3nm XCD，6nm IOD，3nm 密度提升使单 XCD 面积减小但晶体管密度更高）。CDNA 5 8 XCD + 2 FCD + 2 IOD（256 WGP，2nm XCD，3nm FCD+IOD，3D 混合键合 + CoWoS-L，新增 FCD 承载 192MB L2 和 HBM4 控制器）。

封装规模的扩展遵循 Chiplet 路线的工程逻辑：单片 die 的面积和良率限制迫使多 die 集成，但 die 间通信延迟和一致性复杂度随 die 数量增加。CDNA 3 的 8 XCD 需要 IOD 协调一致性，XCD 间最坏情况延迟高于 CDNA 2 的 GCD 间延迟。CDNA 4 通过减少 IOD 数量（4→2）和优化互连路径来部分缓解这一问题，同时 3nm 制程的密度提升使每 XCD 可在更小面积内集成更强的 Matrix Core。CDNA 5 引入 FCD 作为功能分离的缓存/控制 die，XCD 通过 3D 混合键合堆叠在 FCD 之上，进一步缩短 XCD 到 L2/HBM 的物理距离。

4.6.2 CDNA 与 RDNA 的分叉本质

CDNA 和 RDNA 的分叉不止是功能取舍（图形 vs 计算），也是执行模型、数据通路和硬件资源分配的根本差异（以下对比基于 CDNA 1–4 与 RDNA 1–4，CDNA 5 已转向 Wave32/WGP，详见 4.5 节）：

Wave64 与 Wave32 的差异曾是两条产品线设计哲学的分水岭：Wave64 追求单 wavefront 覆盖更大并行度，在高 occupancy 计算负载下调度器每周期需选择的 wavefront 数量更少，调度开销和仲裁逻辑更简单（每 CU 4 个 SIMD 每周期最多 4 个 wavefront 发射，调度器压力恒定）；Wave32 追求单 wavefront 快速完成，在低并行度图形负载（小 draw call、像素着色）中延迟更低。CDNA 5 放弃 Wave64 转向 Wave32/WGP，这一分水岭在执行层面已经消失，分叉的残余仅剩图形前端的有无和 FP64 通路的配置差异。

4.6.3 ECC 与可靠性

CDNA 全线支持 HBM ECC，覆盖 HBM、L1/L2 缓存及寄存器文件等多级存储。ECC 机制包括 SECDED（Single Error Correction, Double Error Detection）、on-die ECC、link CRC/retry 以及 chipkill/RAS 等多种实现，具体方案因产品代际和存储层级而异。AMD 官方给出的 HBM 带宽标称值通常为产品可用峰值口径，已整合各类可靠性机制的净效应。

ECC 对可靠性的保障（单比特纠错、双比特检测）是超算和长周期 AI 训练的必需，HBM 的 row hammer、宇宙射线引发的单比特翻转在高密度存储中概率不可忽略。在评估 memory-bound 负载的有效带宽时，不宜将 ECC 简化为固定的带宽折扣，而应结合具体产品的官方标称值和实测有效带宽。软件优化方向仍是提升 cache hit rate（优化数据布局以提高时间/空间局部性）和 LDS 复用率（增大 tile 尺寸以在 LDS 中缓存更多数据）来降低对 HBM 带宽的依赖。

4.6.4 分区模式

MI300/MI350 系列支持将物理 GPU 划分为多个逻辑设备，以适配多租户或不同粒度的并行负载。分区基于 XCD 的独立性实现：

CPX 模式下每个 XCD 的 HBM 子集可独立寻址，跨 XCD 一致性开销降至最低（无跨分区通信），但单任务可用的内存容量和带宽相应减少。SPX 模式提供最大单任务性能，但多任务间缺乏硬件隔离。分区模式的选择属于平台级部署策略，不影响单 XCD 内部的微架构执行模型。

4.6.5 ROCm 的角色

ROCm（Radeon Open Compute）是 CDNA 硬件特性的软件暴露层，其功能覆盖三个层面：

1. 编译器层：ROCm 的 LLVM/MLIR 编译器将 HIP（类 CUDA 的 C++ 扩展）代码编译为 CDNA ISA，包括 MFMA 指令的自动或手动生成、VGPR 分配策略、LDS tiling 优化。每代 CDNA 的新 MFMA 格式（如 CDNA 3 的 FP8、CDNA 4 的 MXFP4）需要编译器新版本支持。
2. Runtime 层：ROCm Runtime 管理 GPU 内存分配、kernel 提交、多 XCD 的 NUMA-aware 内存放置、XNACK 模式切换。CDNA 的多 XCD 拓扑由 Runtime 暴露给应用，应用可通过 hipMemAdvise 等 API 控制数据放置策略。
3. 库层：ROCm 提供 rocBLAS（BLAS 库）、rocFFT（FFT 库）、MIOpen（深度学习基元库）等，将 CDNA 的 Matrix Core、缓存层次特性封装为标准 API。库的优化程度直接决定 CDNA 硬件性能能否被用户代码充分利用，例如 rocBLAS 中 GEMM 的 tiling 策略需匹配各级缓存容量和带宽。

CDNA 架构的演进节奏与 ROCm 版本绑定：CDNA 1 的 MFMA 需 ROCm 4.x，CDNA 2 的 FP64 MFMA 需 ROCm 5.0+，CDNA 3 的 FP8 需 ROCm 5.5+，CDNA 4 的 MXFP 需 ROCm 7.x，CDNA 5 的 WMA 指令和 Wave32 执行模型需 ROCm 8.x。ROCm 的成熟度（编译优化质量、库覆盖度、调试工具完善度）是 CDNA 架构性能能否被用户代码充分利用的关键变量。

4.6.6 跨代关键参数对比

上表中 FP16/FP8 矩阵吞吐与 FP64 向量吞吐的差距体现了 CDNA 系列的核心设计取向：专用 Matrix Core 的加速效率远高于通用向量 ALU。CDNA 5 的 FP8 矩阵吞吐 20 PFLOPS 是 FP64 向量吞吐 5 TFLOPS 的 4000 倍，这一比率在 CDNA 4 约 122 倍（10 PFLOPS / 82 TFLOPS），在 CDNA 1 约为 16 倍（184 TFLOPS / 11.5 TFLOPS），反映了五代之间专用/通用计算资源分配的持续倾斜。这一倾斜的驱动力是 AI 负载（尤其是生成式模型）对低精度矩阵运算的需求增长远超传统 HPC 对 FP64 的需求增长。

从工程约束角度看，Matrix Core 的低精度通路扩展受限于 CU 面积和功耗。CDNA 4 在 FP64 矩阵上的策略性降低（从 163 TFLOPS 降至 78.6 TFLOPS）是在固定 CU 面积下将硅预算重新分配给 AI 相关通路的工程决策。FP64 向量通路保持全速确保了传统 HPC 负载仍有基本性能支撑，但依赖 FP64 矩阵加速的稠密线性代数库在 CDNA 4 上可能面临矩阵通路缩窄或回退到向量通路的风险（AMD 官方 CDNA 页面列出 CDNA4 Matrix data type support 包含 FP64，MI355X 标称 FP64 Performance 78.6 TFLOPS，但未明确区分 vector/matrix 口径），实际吞吐需结合具体指令集和库版本确认。

缓存层次的演进同样反映工程约束：从 CDNA 1–2 的三级缓存到 CDNA 3–4 的四级缓存，Infinity Cache 的引入是 HBM 带宽增长慢于 Matrix Core 吞吐增长的必然结果。若无 LLC，CDNA 4 的 8 TB/s HBM 带宽在 10 PFLOPS 矩阵吞吐面前将成为硬瓶颈。Infinity Cache 的命中率取决于工作集的局部性特征：模型权重在推理中的逐层顺序访问具有良好的时间局部性，KV cache 在自回归生成中的滑动窗口访问具有良好的空间局部性，因此 LLC 对生成式 AI 推理的效率提升尤为突出。

CDNA 五代的事实到此处已经齐备。这条产品线上还有一层与系列主线直接相关的含义：当一块 GPU 的硅片上不再存在任何图形单元，图形 API 的那些一等抽象还能找到多少物理对应物。

CDNA 证明图形 API 的复杂抽象是碎片化时代的产物，非 GPU 的固有需求。这五代硬件给出的提示是：图形固定功能可以拆得一件不剩，而 GPU 照常运转。光栅化引擎、几何装配、曲面细分、ROP、显示控制器全部移除，晶体管预算划给 CU/WGP、Matrix Core 与 HBM 接口，连调度器的阶段切换逻辑一并删除；CDNA 1–4 的执行模型坚守 GCN 的 Wave64，以每 SIMD 8–10 个驻留 wavefront 隐藏延迟；CDNA 5 更进一步，连 Wave64 也放弃了，转为 Wave32/WGP，彻底采用 RDNA 的执行模型。内存吞吐由 HBM 加片上缓存承担：带宽从 1.23 TB/s 爬到 23.3 TB/s，CDNA 3–4 叠加 256MB Infinity Cache，CDNA 5 以 192MB Global L2 替代。

CDNA 是一个极限样本：图形 API 语义在纯计算域的需求是零。硬件只为 compute 设计时，Descriptor 消失了，资源就是指针，换绑等价于换一批 SGPR 初值；Pipeline Barrier 消失了，同步退化为 workgroup 内 barrier 与显式 fence 的内存序；Draw 消失了，前端只剩 kernel launch。指针、launch、内存序，就是硬件要求的全部。

这从反方向印证了系列主线：图形 API 的复杂抽象是图形硬件碎片化时代的产物，而非 GPU 的固有需求。2.1.5 节已给出正面证据：Descriptor 正是固定纹理寻址路径时代留下的代偿。拆光碎片化硬件后，这些抽象连一个物理对应物都找不到。

五、思考与展望

AMD GPU 架构从 TeraScale 的 VLIW 并行模型到 GCN 的标量 SIMD，再到 RDNA 的高频设计和 CDNA 的专用计算加速，设计哲学、微架构权衡和战略决策持续演变。

5.0 统一透镜：Latency-Hiding Stack（延迟隐藏栈）

AMD GPU 架构史上的每一次重大演进，都可以定位到"延迟隐藏栈"的某一层或多层上。GPU 的执行流程可以抽象为一条贯穿所有层级的数据通路：Command Processor 解析命令缓冲区 → ACE/MES 将工作分派到队列 → Shader Engine/WGP 做工作分发 → Wave Scheduler 从就绪队列中选择 wavefront 发射指令 → 指令读取 SGPR/VGPR/LDS/Cache 中的操作数 → SALU/VALU/VMEM/SMEM/DS/TEX 执行 → 结果写回寄存器文件 → Dependency/waitcnt 标记解除 → 下一条指令进入调度窗口。这个栈从上到下分为五层，每一层对应这条通路中的一个关键阶段。

第一层：队列/前端层

CP / ACE / MES / Queue Manager / priority / preemption。这一层决定 GPU 如何接收和分发工作，是任务粒度和调度策略的边界。GCN 的 CP+ACE 设计允许同时存在多个独立的命令队列（图形队列 + 计算队列），ACE 负责在这些队列之间做硬件级的并行调度，这是异步计算的基础。RDNA 继承了 ACE 机制并增加了对更多并发队列的支持。CDNA 进一步将前端替换为 MES（Microcode Engine Scheduler）+ 多队列设计，支持数百个独立计算队列的并发提交，反映了数据中心 GPU 对多租户、多任务并行提交的需求。前端层的演进逻辑是：从 GCN 的"图形为主+计算辅助"到 CDNA 的"计算为主+批量并行提交"，队列数量和管理复杂度持续增加。

第二层：工作分发层

Shader Engine / Shader Array / WGP / CU 分发。这一层决定工作如何从队列分发到具体的执行单元。WGP（Workgroup Processor）的引入（RDNA 1）是这一层的重要变化：RDNA 将两个 CU 的资源池化形成一个 WGP，一个 WGP 内共享 LDS 和调度资源，使得小 workgroup（如 64~128 线程）的执行效率提升，因为不需要跨多个独立 CU 来分配资源。RDNA 3/4 延续了 WGP 设计，CDNA 则回归独立 CU 的强计算分发模式，因为数据中心 workload 通常 workgroup 规模较大，CU 级独立调度的自由度更重要。这一层的核心权衡在于：池化资源提高小 workload 效率 vs. 独立资源提高大 workload 的并行度。

第三层：波前执行层

ready wave selection / issue / waitcnt / barrier / scoreboard。这一层是 GPU 执行效率的核心，决定每个周期哪个 wavefront 的指令被发射。GCN 采用 Wave64 模型：一个 64-thread wavefront 在 4-cycle 内在 16-wide SIMD 上完成单指令发射，依赖高 occupancy（每个 SIMD 挂起 10 个 wavefront，全 CU 40 个）来隐藏延迟。RDNA 1 引入 Wave32：一个 32-thread wavefront 在 1-cycle 内在 32-wide SIMD 上完成发射，单 wavefront 执行延迟从 4 cycle 降至 1 cycle，降低了对超高 occupancy 的依赖。RDNA 3/4 进一步引入 S_DELAY_ALU hint 和优化的 scoreboard 机制，允许更精确的指令间延迟插入，减少 waitcnt 开销。CDNA 保留了 Wave64 模式，因为计算 workload 的线程粒度通常较大，Wave64 的向量利用率更高。

这一层的调度路径可以细化为：Wave Scheduler 维护每个 wavefront 的状态（ready / waitcnt / barrier / sleeping），每个周期从 ready 集合中按照优先级选择一个 wavefront，检查其下一条指令的 operand 是否在 SGPR/VGPR 中可用、目标功能单元（SALU/VALU/VMEM/SMEM/DS）是否有空闲槽位、scoreboard 是否有冲突，若全部满足则发射指令并标记 dependency。发射后，若指令有延迟（如 VALU 指令依赖前一条 ALU 结果），scheduler 插入对应的 waitcnt 计数；若指令访问 LDS/VMEM，scheduler 将 wavefront 移入等待队列，直至 memory transaction 完成。

第四层：资源层

VGPR / SGPR / LDS / cache / bandwidth / RT stack / matrix tiles。这一层决定执行单元能够同时驻留多少工作，直接影响 occupancy 上限和实际吞吐。GCN 的 VGPR 分配是静态的：每个 wavefront 在启动时申请固定数量的 VGPR，整个生命周期占用这些寄存器，若 VGPR 需求大则 occupancy 下降。RDNA 4 引入动态 VGPR（Dynamic VGPR）分配：wavefront 可在运行时按需申请额外 VGPR，在 raytracing 等复杂着色器场景下提高 occupancy，但限制为仅 Wave32 计算着色器可用，且动态与非动态 wavefront 不能混跑在同一 CU 上，引入死锁避免机制（预留部分 VGPR 保证至少一个 wave 可升级）。Infinity Cache（RDNA 2）在资源层引入了非对称创新：128MB on-die cache 将约 60~80% 的显存访问转化为片上命中，在 256-bit GDDR6 接口上提供接近 512-bit 总线的有效带宽，代价是 die area 和功耗。CDNA 系列则通过 HBM 高带宽显存和大容量 LDS/寄存器文件来服务计算密集型 workload。

第五层：系统层

chiplet / IF / HBM / CPU-GPU 协作 / multi-GPU / partitioning。这一层决定 GPU 如何与系统其他组件协作。RDNA 3 的 GCD+MCD chiplet 设计是这一层的标志性演进：GCD（Graphics Compute Die）使用 5nm 工艺承载主要计算和图形逻辑，MCD（Memory Cache Die）使用 6nm 工艺承载内存控制器和 Infinity Cache，通过 5.3 TB/s 的 Infinity Link 连接。这种拆分允许不同模块使用最适合的工艺节点，提升良率并降低成本，代价是 chiplet 间通信延迟和一致性管理复杂度。MI300 的 XCD+MCD+IOD 设计将这一思路推向极致：多个 XCD（GPU Compute Die）围绕中央 IOD（I/O Die）布置，配合 HBM3 堆叠，提供高达 5.3 TB/s 的显存带宽和 192 GB HBM3 容量，支持 SPX/DPX/CPX 三种分区模式以适配不同 workload 的并行需求。

代际演进映射

将全文各代际变化归入这五层，可以得到以下映射关系：

这个框架的价值在于：每一代架构的核心贡献可以定位到具体层级，代际之间的演进逻辑不再是孤立的 feature 列表，而是沿延迟隐藏通路的系统性改进。后续各节的分析在这个框架下展开。

5.1 设计哲学的演进

从编译期 ILP 到运行期 TLP：VLIW → GCN

TeraScale 架构采用 VLIW（Very Long Instruction Word）设计，每个 ALU group 包含 4-5 个并行操作槽位，由编译器在编译期静态调度。这一设计的根本瓶颈在于：编译器必须找到足够多的独立指令（ILP）才能填满所有槽位，而实际 workload 中图形着色器和通用计算内核的 ILP 往往不足。实测中，典型图形着色器的平均 ILP 约为 3-4，VLIW5 的平均槽位利用率仅 60%~80%，远低于理论峰值。更关键的是，当控制流出现分支分歧时，VLIW 的静态打包会被动态执行的 mask 打乱，编译期优化成果在运行时失效。

2011 年 GCN 抛弃了 VLIW，改为纯标量 SIMD ISA。GCN wavefront 执行模型采用 Wave64：每个 wavefront 64 个线程，硬件在运行期通过 wavefront 切换来隐藏延迟，不再依赖编译器静态打包。GCN 的每个 CU 包含 4 个 16-wide SIMD，每个 SIMD 可同时追踪约 10 个 wavefront（全 CU 共 40 个 wavefront，约 2560 并发线程），通过高 occupancy 覆盖内存访问延迟。相比 VLIW，GCN 的 tradeoff 是：单线程每周期只能发射一条标量指令（牺牲每线程 ILP），但通过硬件多线程调度获得等效的总体吞吐，同时显著降低编译器复杂度。这一转变的实质是：用硬件复杂性（更大的 register file、更复杂的 scheduler、更多的上下文保存资源）换取软件易用性和通用计算适配性。

RDNA 与 CDNA 的分野：通用架构的终结

GCN 时代 AMD 采用一套通用架构同时服务于图形和计算。实践表明这种"一刀切"策略存在效率瓶颈：GCN 的 Wave64 高延迟模型在中小 workload（低三角形数、低像素填充）场景下利用率不足，而 NVIDIA 同期的 Maxwell/Pascal 通过 32-thread warp 在这些场景下表现更优。在计算领域，GCN 又因 ROCm 生态建设滞后未能充分兑现硬件潜力。

2019 年 AMD 开启架构分流：RDNA 系列专注游戏图形，CDNA 系列专注数据中心计算。RDNA 架构的关键调整包括：Wave32 降低单 wavefront 执行延迟、WGP 资源池化提高小 workload 效率、多级缓存体系（L0/L1/L2/Infinity Cache）降低显存依赖、Navi 10（RX 5700 XT）在 7nm 工艺下以 2560 SP 和 225W TDP 达到与 Radeon VII（GCN，3840 SP，295W）相近的游戏性能，验证了效率优先路线的可行性。CDNA 架构则剥离图形固定功能单元（光栅器、纹理单元、显示输出），将 die area 释放给 Matrix Core（MI100 起）、大容量 LDS/寄存器文件和 HBM 接口，专注计算密度和内存带宽。

这一分野的结果是：AMD 需要并行维护两套 ISA 和微架构，开发者和工具链也需要分别适配。2024 年后 AMD 公开提出 UDNA（Unified DNA）统一架构方向，计划在 RDNA 4/CDNA 4 之后重新融合，表明专用化与通用化的取舍是一个动态平衡。

从峰值吞吐到实战能效

GCN 时代以峰值 TFLOPS 为主要宣传指标，但实际应用效率偏低。Vega 10（Vega 64）配备 4096 个流处理器和 HBM2 显存，单精度峰值约 12.6 TFLOPS，但在实际游戏中受限于指令调度效率和显存延迟，大量 ALU 处于等待数据状态。同期 GTX 1080 Ti（3584 CUDA Core，峰值 11.3 TFLOPS）在多数游戏中帧率更高，说明架构效率比 ALU 数量更能决定实际性能。

RDNA 系列的设计重心从"做大峰值"转向"垫高实际效率"：

• NGG（Next-Generation Geometry）引擎：硬件级加速 primitive culling 和 mesh shader 路径，提高实际场景中的几何处理吞吐。
• Infinity Cache：128MB on-die cache 在 1080p-4K 游戏 workload 下可将约 60~80% 的显存访问转化为片上命中（命中率因 workload 而异），在 256-bit GDDR6（512 GB/s 理论带宽）上实现约 1.66 TB/s 的有效带宽（实测值，workload 依赖）。
• 改进的缓存层级：RDNA 1 引入统一 L1 cache，RDNA 2/3 持续扩充 L2 和 Infinity Cache 容量，减少对显存带宽的依赖。
• Wave32 降低延迟敏感度：单个 wavefront 执行延迟从 4 cycle 降至 1 cycle，在低并行度场景（小 draw call、低分辨率）下 scheduler 不需要维持极高 occupancy 就能保持功能单元繁忙。

最终效果是：Radeon RX 5700 XT（RDNA 1，2560 SP，225W）的游戏性能接近 Radeon VII（GCN，3840 SP，295W），SP 数量减少 33%，功耗降低 24%。这说明在工艺节点相同（均为 7nm）的情况下，架构效率提升带来的收益可以超过单纯的 ALU 规模扩张。

从单片大芯片到 Chiplet 异构集成

制程演进和规模报酬递减使单一巨型 GPU die 的成本急剧上升。RDNA 3 成为首款采用 Chiplet 设计的游戏 GPU：GCD（5nm）承载主要计算和图形逻辑，MCD（6nm）承载内存控制器和 Infinity Cache，通过 Infinity Link（5.3 TB/s）连接。这种拆分的工程逻辑是：5nm 工艺下 SRAM 密度收益不如逻辑门线性，将大容量缓存放在 6nm 节点制造可以降低成本和功耗。Chiplet 方案还允许突破单颗 die 的尺寸限制，通过堆叠更多 MCD 扩展总资源。

MI300 系列将 Chiplet 设计推向极致：多个 XCD（GPU Compute Die）围绕 IOD 布置，配合 HBM3 堆叠，集成最多 13 个小芯片（CPU+GPU+HBM），通过 2.5D/3D 封装实现。代价是：chiplet 间一致性管理、跨 die 延迟差异、驱动层验证复杂度都需要额外投入。AMD 的 Infinity Fabric 在这一层提供 die 间互连带宽，但 chiplet 间延迟始终高于 on-die 通信，这要求 scheduler 在任务分配时考虑 NUMA（Non-Uniform Memory Access）特性。

5.2 根本性权衡

吞吐量 vs 延迟：Wave64 与 Wave32 的取舍

GPU 架构中高吞吐（通过海量并行线程提升每周期处理总量）与低延迟（单一批次快速完成）之间存在结构性冲突。这个冲突的根源在于 scheduler 资源与 register file 容量的约束：更多的并发 wavefront 意味着更高的吞吐潜力，但也意味着每个 wavefront 分到更少的执行周期，单个 wavefront 的完成时间延长。

GCN 选择 Wave64：64-thread wavefront 在 16-wide SIMD 上需 4 cycle 完成单指令发射。这一选择的收益是：单条指令覆盖 64 个 thread，向量 ALU 利用率高；每个 CU 可挂起 40 个 wavefront（约 2560 线程），在 bandwidth-bound workload 下通过高 occupancy 隐藏显存延迟。代价是：单个 wavefront 的指令延迟为 4 cycle，在低并行度场景（如小 draw call、低三角形数量）中，如果 wavefront 数量不足以填满所有 SIMD，功能单元会出现空闲周期。实测中 GCN 在 1080p 低负载游戏中表现逊于 NVIDIA Kepler/Maxwell 的 32-thread warp，原因在于：小 workload 无法产生足够的 wavefront 来利用全部 SIMD，而 Wave64 的单批执行延迟又无法让单个 wavefront 快速通过流水线。

RDNA 选择 Wave32：32-thread wavefront 在 32-wide SIMD 上 1 cycle 完成发射。收益是：单 wavefront 执行延迟降至 1/4，scheduler 不需要维持极高 occupancy 就能保持 SIMD 繁忙；小 workload 下即使 wavefront 数量较少，单个 wavefront 也能快速完成，功能单元空闲周期减少。RDNA 1 每个 CU 包含 2 个 SIMD32（取代 GCN 的 4 个 SIMD16），单个 CU 的理论 wavefront 容量下降，但通过更快的单批执行来弥补。RDNA 3/4 进一步支持 dual-issue，在特定条件下单个 SIMD32 每周期可发射两条独立指令，提高了单 CU 的指令吞吐。

CDNA 1–4 在计算场景下继续使用 Wave64，因为数据中心 workload（矩阵乘法、大规模并行仿真）通常线程粒度大，Wave64 的向量利用率更高；RDNA 也保留了对 Wave64 的兼容模式。这种"双模"设计在当时反映了吞吐与延迟的权衡针对不同 workload 特征的参数化选择。但 CDNA 5 彻底放弃了 Wave64（ISA 层面不再支持 Wave64 编码），说明 AMD 最终判定 Wave32 在高吞吐计算中也能通过更多 resident wave 和 packed 执行达到等效利用率。这个判定的落地条件是寄存器文件翻倍（1024 VGPR/wave）和 WGP 内 64 wave 驻留能力。

通用性 vs 专用性：RDNA/CDNA 分野与 UDNA 回归

GPU 从固定功能走向可编程通用是长期趋势，但"通用"的边界在哪里是持续争议的问题。GCN 是 AMD 追求通用性的顶峰：同一套 CU 设计同时服务于图形着色和通用计算，同一套 ISA 同时编译游戏 shader 和 HPC 内核。实际结果是：GCN 在游戏场景下因计算导向设计牺牲了部分图形效率（如光栅化、纹理采样的专用资源不足），在计算场景下又因 CUDA 生态优势未能充分收割市场。

RDNA 的专用化路线：移除 GCN 中服务于计算但对游戏不常用的特性（如 FP64 单元大幅缩减），将 die area 投入图形专用资源（改进的光栅器、更大的纹理单元、更多的 ROP）。RDNA 1 的 FP64 吞吐降至 FP32 的 1/16（GCN 为 1/2 或 1/4），这一取舍对游戏 workload 几乎无影响，但明显降低了 ALU 面积和功耗。CDNA 的专用化路线则相反：完全移除图形管线（无光栅器、无纹理单元、无显示输出），将 die area 投入 Matrix Core、大容量 register file/LDS 和 HBM 接口。CDNA 2（MI250X）的 Matrix Core 提供 383 TFLOPS FP16/BF16 吞吐，同期 RDNA 2（RX 6900 XT）仅 46 TFLOPS FP16，专用化的计算效率优势约为 8 倍。

专用化的代价是生态割裂：开发者需要为 RDNA 和 CDNA 分别优化，AMD 需要维护两套编译器后端、两套驱动栈、两套性能调优工具。AMD 高管公开讨论过统一 RDNA/CDNA 的 UDNA 方向 （AMD 官方声明）意味着 AMD 判断专用化带来的效率红利已不足以抵消生态和研发成本，回归统一架构成为新的平衡点。这种"通用→专用→通用"的螺旋演进，是对"普适性"和"极致性"在不同市场条件下的动态评估。

峰值性能 vs 应用效率：Vega 的教训与 Infinity Cache 的非对称创新

Vega 10（Vega 64）配备 4096 SP、12.6 TFLOPS FP32 峰值、483 GB/s HBM2 带宽，硬件规格在当时属顶级水平。但实际游戏帧率仅与 GTX 1080（8.8 TFLOPS）相当，远低于 GTX 1080 Ti（11.3 TFLOPS）。问题的根因在于 Vega 的架构效率低下：

• 指令调度瓶颈：GCN 5.0 的 4-issue 前端在实际 workload 中难以持续饱和，许多 cycle 只有 1~2 个 issue slot 被使用。
• 显存延迟敏感：HBM2 虽提供高带宽，但访问延迟仍明显高于 on-die cache，GCN 对 cache 的依赖不足导致大量 ALU 等待显存数据。
• Workload 适配不良：Vega 的 Rapid Packed Math（FP16）和 HBCC（High Bandwidth Cache Controller）在游戏 workload 中未被充分利用，专用硬件的利用率低。

RDNA 2 的 Infinity Cache 是一项非对称创新：不增加显存总线宽度（保持 256-bit GDDR6），而是在片上集成 128MB cache。AMD 内部仿真数据显示，游戏 workload 中 shader 对数据的重复访问率较高，128MB cache 可覆盖 60~80% 的显存访问。实测中，RX 6800 XT（4608 SP，256-bit GDDR6+128MB IC）在 4K 游戏中与 RTX 3080（8704 CUDA Core，320-bit GDDR6X）表现接近，尽管 SP 数量和显存带宽规格均低于对手，验证了架构效率对实际性能的放大作用。

这一权衡说明：在工艺进步放缓（摩尔定律减速）的条件下，单纯增加 ALU 数量和显存带宽的"堆料"路线性价比递减，通过架构层面的优化（cache 层次、指令调度、workload 适配）提高单位晶体管的实际贡献度更具工程价值。

架构复杂性 vs 开发者生态

架构特性引入的硬件复杂度最终会传导到软件生态中。TeraScale 的 VLIW 是前车之鉴：编译器需要精确调度 ILP、避免 bank conflict、填充 NOP，开发者的优化负担重，实际利用率远低于峰值。GCN 改用标量 ISA 和硬件调度后，编译器不再负责底层 wavefront 调度，大大降低了开发门槛。

RDNA 3/4 的动态 VGPR 是一个复杂度与生态的当代案例。动态 VGPR 允许 wavefront 在运行时申请额外 VGPR，解决固定分配下复杂着色器（如 raytracing）因 VGPR 需求大而导致 occupancy 低的问题。但这一机制引入了新的约束：仅 Wave32 计算着色器可用、动态与非动态 wavefront 不能混跑同一 CU、需要死锁避免机制（预留部分 VGPR 保证至少一个 wave 可升级完成）。这些约束增加了编程模型的复杂度和驱动验证的负担。相比之下，Infinity Cache 对软件完全透明，属于"即插即用"型创新，生态适配成本为零。

ROCm 与 CUDA 的生态差距是另一个维度的教训。NVIDIA 自 2007 年起持续投入 CUDA 生态建设，形成了覆盖深度学习（cuDNN）、线性代数（cuBLAS）、通信（NCCL）等领域的完整库体系。AMD 的 ROCm 平台 2016 年才启动，且投入资源相对有限，导致即使 CDNA 硬件在峰值规格上具有竞争力（如 MI250X 的 383 TFLOPS FP16 vs. A100 的 312 TFLOPS），用户迁移成本仍构成 adoption 障碍。生态建设的滞后意味着硬件优势无法充分变现。

5.3 战略得失复盘

ACE 的前置布局

GCN 1.0（2012 年，Southern Islands）引入 ACE（Asynchronous Compute Engine），硬件层面支持图形队列与计算队列的并发调度。这一设计在发布初期并未被游戏 workload 充分利用（DX11 时代驱动层调度为主），但随着 DX12/Vulkan（2015-2016 年）的兴起，异步计算成为标准特性，ACE 的硬件支持转化为实际性能收益。对比之下，NVIDIA Kepler/Maxwell 早期版本的异步计算支持依赖软件调度或有限硬件队列，在 async compute workload 下表现不如 GCN。

ACE 的技术价值在于：它允许 GPU 在图形流水线空闲周期（如 rasterization 等待、ROP 阻塞）中穿插执行计算任务，提高功能单元利用率。从延迟隐藏栈的视角看，ACE 属于第一层（队列/前端层）的创新，它增加了"任务级"的并行度，与第三层（wavefront 级）的延迟隐藏形成互补。前置布局的代价是：ACE 占用额外 die area（每个 ACE 包含独立的队列管理和调度逻辑），在未被充分利用时成为面积开销。

Infinity Cache 的非对称创新

RDNA 2 研发阶段，AMD 面临的选择是：上马 384-bit 或 512-bit GDDR6 总线以提升带宽，还是通过 cache 层次优化来缓解带宽压力。前者需要更宽的 memory controller 和 PCB 布线，成本和功耗代价高；后者需要在 die 上集成大容量 SRAM，面积代价高。AMD 选择了后者：128MB Infinity Cache 在 6nm MCD 上实现，配合 256-bit GDDR6 提供足够的有效带宽。

这一决策的工程依据是：内部仿真数据显示游戏 workload 中显存访问具有明显的时间局部性和空间局部性，128MB 容量可覆盖多数 1080p-4K 游戏场景中的热点数据。实测中 RX 6800 XT 的有效带宽达到约 1.66 TB/s，相当于 512-bit GDDR6（约 1 TB/s）或更宽总线的水平，而实际 die cost 和功耗低于同等带宽的宽总线方案。Infinity Cache 对开发者完全透明，无需 API 适配或代码修改，属于低生态成本创新。

Chiplet 战略的工程逻辑

RDNA 3 的 GCD+MCD chiplet 设计在工程层面解决的核心问题是：5nm 工艺下 SRAM 面积缩放比例落后于逻辑门，若在 5nm GCD 上集成全部 Infinity Cache，die area 和成本会显著上升。将 cache 移至 6nm MCD，可以在保持性能的同时利用更成熟工艺的成本优势。MI300 的 XCD+MCD+IOD 设计则将 chiplet 策略推向多芯片集成：不同功能模块（CPU、GPU、HBM）使用各自最优的工艺和封装技术，通过 2.5D/3D 集成实现单片无法达到的规模。

Chiplet 的代价包括：die 间互连带宽和延迟（Infinity Link 5.3 TB/s 虽高，但仍低于 on-die 布线延迟）、跨 die 一致性管理复杂度、驱动验证工作量倍增。AMD 通过 Infinity Fabric 协议层抽象了部分复杂性，但 chiplet 间的 NUMA 特性仍需在调度层面考虑。

技术债务：GCN 的高占用低 IPC

GCN 的每个 CU 设计容纳 40 个 wavefront（约 2560 并发线程），追求高 occupancy 下的最大吞吐。这一设计的隐含假设是：workload 始终能提供足够的并行度填满所有 wave slot。在实际游戏中，这一假设经常不成立：1080p 低分辨率场景下 triangle/pixel 数量不足，无法生成足够的 wavefront；小 draw call 场景下前端吞吐量成为瓶颈，wavefront 生成速度跟不上消耗速度。结果是：GCN 在低并行度场景下 IPC（每周期每线程指令数）偏低，功能单元空闲周期比例高，表现为"高并发低 IPC"的结构性短板。

这一设计选择的技术债务在 Vega 时代集中爆发：Vega 64（4096 SP）在 1080p 游戏中与 GTX 1080（2560 CUDA Core）互有胜负，SP 数量优势未能转化为帧率优势。根本原因是 NVIDIA Pascal 的 warp scheduler 在 low-occupancy 场景下仍能保持较高的 issue rate，而 GCN 的 wave scheduler 对 occupancy 的敏感度更高。

Vega 的游戏性能短板

Vega 10 理论指标亮眼但实际游戏表现未达预期（具体数据与根因分析见 5.2 节"峰值性能 vs 应用效率"）。Vega 的教训促使 RDNA 架构在游戏 workload 适配方面进行了系统性改进：Wave32 降低延迟敏感度、多级 cache 减少显存依赖、NGG 引擎加速几何处理、专用 Ray Accelerator 应对光追 workload。

ROCm 生态滞后

ROCm（Radeon Open Compute）平台 2016 年启动，比 CUDA（2007 年）晚了 9 年。这 9 年的差距导致：深度学习框架（TensorFlow、PyTorch）的 CUDA 后端成熟度和优化程度远高于 ROCm/HIP 后端；科学计算库（cuBLAS、cuDNN、NCCL）的 CUDA 版本性能领先；开发者习惯和知识积累围绕 CUDA 生态形成。即使 CDNA 2（MI250X）在峰值 TFLOPS 上具有竞争力，用户迁移的代码改动成本和性能不确定性仍构成 adoption 障碍。

AMD 近期加大对 ROCm 的投入（ROCm 6.x 系列增加对更多 GPU 架构的支持、改进 HIP 转换工具），但生态建设具有网络效应和路径依赖，追赶需要持续投入和时间积累。

矩阵加速单元的延迟布局

NVIDIA 2017 年（Volta 架构）引入 Tensor Core，专用矩阵乘加单元在 AI 训练 workload 中提供高达 125 TFLOPS FP16 吞吐。AMD 直到 2020 年（CDNA / MI100）才推出 Matrix Core，2022 年（RDNA 3）在消费级 GPU 中引入 AI 加速指令。这 3~5 年的延迟使 AMD 在 2017-2022 年的 AI 训练市场增长期中未能有效参与，NVIDIA 通过 Tensor Core + CUDA 生态的组合占据了 AI 加速器市场的主导地位。RDNA 3 每 CU 配备 2 个 AI 矩阵 FMA 单元，PS5 Pro SoC 集成 ML 硬件，表明 AMD 已认识到 AI 协处理的重要性，但起步延迟造成的市场格局难以短期逆转。

5.4 未来战场推演

"四重墙"约束

GPU 架构的传统改进空间正受到四重物理和经济约束的压缩：

功耗约束：空气冷却方案下单卡功耗天花板约为 350W~400W，超过此阈值需要液冷或特殊供电方案，成本和部署复杂度随之上升。RDNA 4 旗舰 RX 7900 XTX 已接近 355W，后续架构在相同功耗预算下的性能提升必须来自效率改进而非单纯堆料。

显存带宽约束：HBM 提供高带宽但成本高昂且容量受限（HBM3 单 stack 最高 24GB，8-stack 封装极限约 192GB）；GDDR6X/GDDR7 频率提升放缓，256-bit/384-bit 总线已接近 PCB 布线和信号完整性极限。Infinity Cache 类型的片上缓存是非对称缓解方案，但 cache 容量受 die area 约束，128MB~256MB 已是当前工艺的合理上限。

成本约束：最先进制程（3nm/2nm）的晶体管单位成本不再遵循摩尔定律的下降趋势，巨型 monolithic die 的良率问题使成本呈指数增长。Chiplet 设计通过良率改善和小 die 组合缓解这一问题，但封装复杂度（2.5D/3D 堆叠、硅中介层、EMIB 等）带来额外成本。

软件复杂性约束：GPU 微架构的高度复杂化（动态调度、多层级 cache、chiplet 一致性、AI/RT 专用单元）使驱动和编译器优化难度倍增。开发者面对异构编程模型（GPU + CPU + AI 加速器）、多线程同步、cache 一致性等概念的学习曲线陡峭。

这四重约束相互耦合：更高功耗需要更复杂散热，更大 cache 需要更大 die area，更复杂架构需要更多软件投入。传统"制程升级 + 规模扩张"路线的性价比递减，架构师需要在约束空间内寻找非线性突破点。

UDNA 统一架构

AMD 已公开提出 UDNA 作为 RDNA 与 CDNA 之后的统一架构方向 （AMD 官方声明）。这一决策的技术逻辑是：RDNA/CDNA 分野后，两套 ISA 和微架构的并行维护成本持续上升，软件生态被分割（ROCm 需分别适配 CDNA 和 RDNA），开发者面临选择困惑。统一架构可以集中研发资源、统一软件栈、降低生态适配成本。

UDNA 的预期技术特征：继承 CDNA 的强计算能力（Matrix Core、大容量 HBM 接口、高带宽缓存）和 RDNA 的图形专长（Ray Accelerator、高频能效优化、WGP 调度模型），在一套微架构中通过配置参数（CU 数量、HBM vs. GDDR、RT 单元数量）区分游戏和计算 SKU。这种"同源异构"设计意味着硬件层面的功能单元共存：光追单元和矩阵单元在同一 die 上共享资源，scheduler 需要同时处理图形、AI 和计算 workload 的混合调度。

UDNA 的风险在于：统一架构的通用性可能牺牲专用架构的极致效率。CDNA 去除图形管线后获得的面积和功耗优势将不复存在，UDNA 需要在 die area 预算中同时容纳图形和计算资源。若市场继续向 AI 计算倾斜，图形单元的面积开销可能成为效率负担。AMD 的应对策略可能是通过 Chiplet 设计（如 GCD 承载通用计算 + 可配置图形 die）在统一架构内实现模块化定制。

Project Amethyst 与下一代游戏架构

2025 年 AMD 与索尼公开了联合研发的 Project Amethyst 合作方向，已确认的内容包括：索尼 2026 版 PSSR（PlayStation Spectral Super Resolution）的算法和神经网络来自此项合作 （AMD 官方声明）。更远期的 Radiance Cores、Neural Arrays、Universal Compression 等技术方向，应视为早期架构研究项目，尚未有公开的产品化时间表 [推断]。

基于公开信息的有限分析：

Neural Arrays：描述为将多个 CU 协作组成统一的 AI 加速引擎。从微架构视角看，这涉及 CU 间数据共享和同步机制的扩展：当前 GPU 中 CU 间的数据交换依赖 L2 cache 和显存，延迟较高；Neural Arrays 若在 CU 间建立更高速的数据通路（如专用片上网络或扩展 LDS 共享），可降低大规模神经网络推理中的通信开销。实现层面可能涉及：扩展的片上互连带宽、CU 间的同步原语增强、scheduler 对 AI workload 的协同调度支持。对渲染管线的潜在影响是：AI 后处理（超分辨率、降噪）不再局限于单个 CU 或 shader 阶段，而可以跨 CU 协同处理整帧数据。

Radiance Cores：描述为专用光线/光照处理单元，负责 ray traversal 和光照计算。从架构层面看，这类似于 NVIDIA RT Core 的演进方向：将 BVH traversal 和 ray-triangle intersection 从通用 ALU 卸载到专用硬件。当前 AMD 的 Ray Accelerator（RDNA 2/3/4）已提供硬件级 BVH traversal，Radiance Cores 可能在此基础上扩展路径追踪相关的功能（如 neural radiance caching、重要性采样加速）。如果同时承担光照缓存计算，则需要在专用单元中集成一定量的存储（如 radiance cache buffer）和轻量计算能力。

Universal Compression：描述为对纹理、几何、光照缓存等数据进行压缩，降低显存带宽和容量占用。这一方向的技术基础在 PS5 时代已有实践（Kraken 解压加速），扩展到通用数据维度需要：吞吐更高、延迟更低的压缩/解压算法（可能引入机器学习驱动的自适应压缩）、硬件级解压单元集成到显存控制器路径中、对 GPU cache hierarchy 的透明支持（压缩数据在 cache 中保持压缩状态，减少 cache footprint）。对 AI 和光追 workload 的协同价值在于：压缩后的模型权重和 BVH 数据体积减小，可在有限显存下支持更大规模的网络模型和更复杂的场景。

以上分析基于公开声明和行业推断 [推断]，不应视为已确认的产品规格。Project Amethyst 的技术方向反映了游戏 GPU 架构的三个演进趋势：AI 推理与图形渲染的紧密融合、光追计算从"可用"到专用化、数据压缩作为缓解存储墙的基础能力。

潜在范式转变

综合已知约束和行业研究动向，GPU 架构在未来 5~10 年可能面临以下结构性变化：

异构紧密融合：数据中心层面，CPU+GPU+AI Engine 的多 chiplet SoC（如 MI300 系列）将持续演进，统一内存和 cache 一致性架构使不同核自由访问数据。消费级层面，CPU 与 GPU 的封装集成度提高（类似 Apple M 系列 SoC 的内存统一架构），PCIe 通信延迟被消除。CXL 等新型互连协议和高速 die-to-die 接口使异构芯片协作更透明。对 AMD 而言，APU（CPU+GPU 集成）经验和 MI300 的 chiplet 集成经验可在这一趋势中复用。

计算资源的弹性配置：RDNA 3 的 CU 已支持在渲染、AI、光追之间共享资源，后续架构可能进一步推进这一理念：通过 ISA 和微架构协同，GPU 根据 workload 类型动态重配置部分流水线（如加载特殊微码切换 ALU 模式、动态调整 cache/shared memory 比例）。这种弹性设计的代价是控制逻辑复杂度增加，需要 scheduler 具备 workload-aware 的调度能力。收益是：同一块硅片在不同 workload 下的有效利用率提升，避免"为峰值能力付出永驻面积代价"。

AI 与图形的管线融合：当前 AI 在图形中的角色主要是后处理（DLSS/FSR 超分辨率、降噪），未来的演进方向是 AI 参与渲染管线的中间阶段（如 neural texture 生成、AI 驱动的 LOD 选择、neural radiance cache 参与光照计算）。GPU 架构需要为此提供：AI 单元访问渲染缓存和材质数据的专用通路、张量运算与光栅流水的低延迟协同、渲染管线中间数据对 AI shader 的可见性。这一融合方向对 API 设计提出新要求：下一代图形 API 可能需要原生支持 AI shader 与图形 pipeline 的混合编排。

新型互连与封装：当电气互连逼近物理极限（高频信号衰减、功耗增加），光互连（silicon photonics）可能进入 GPU 架构视野。短期（2025-2030）内更现实的演进是：3D 堆叠技术将 cache 或 HBM 直接堆叠在计算 die 上方（如 MI300 的 HBM3 2.5D 堆叠），chiplet 间通过更高密度的互连技术（如 hybrid bonding）实现更低延迟和更高带宽。AMD 在 CPU 领域的 3D V-Cache（Zen 4/5）经验可能向 GPU 领域迁移：在计算 die 上垂直堆叠 SRAM cache，突破平面工艺的 cache 容量限制。

以上范式转变基于当前物理约束和技术储备的方向性分析。每一方向的实际落地取决于工艺成熟度、成本可行性和 workload 需求的演进节奏。UDNA 统一架构是 AMD 公开承诺的下一步，CDNA 5 的 Wave32/WGP 转向已经完成了执行基座的对齐，但图形管线与矩阵通路的共存方式、Draw 语义在统一架构中的归宿等关键决策，仍待 UDNA 正式披露时揭晓。

参考文献

引用的第三方实测与官方资料如下（正文中对应位置均已标注来源）：

1. AMD, RDNA Architecture（GPUOpen 公开演示材料）: https://gpuopen.com/download/RDNA_Architecture_public.pdf
2. Chips and Cheese, "AMD's RDNA 2: Shooting For the Top"（Chester Lam）: https://chipsandcheese.com/p/amds-rdna-2-shooting-for-the-top
3. Chips and Cheese, "Microbenchmarking AMD's RDNA 3 Graphics Architecture"（Chester Lam）: https://chipsandcheese.com/p/microbenchmarking-amds-rdna-3-graphics-architecture
4. Chips and Cheese, "RDNA 4's 'Out-of-Order' Memory Accesses"（Chester Lam）: https://chipsandcheese.com/p/rdna-4s-out-of-order-memory-accesses
5. AMD, AMD Instinct MI250X 官方规格页: https://www.amd.com/en/products/accelerators/instinct/mi200/mi250x.html
6. AMD, "New AMD Instinct MI200 Series Accelerators Bring..." 新闻稿（2021-11-08，含 MI200-01 性能注脚）: https://www.amd.com/en/newsroom/press-releases/2021-11-8-new-amd-instinct-mi200-series-accelerators-bring-.html
7. AMD, AMD Instinct MI300X 官方规格页: https://www.amd.com/en/products/accelerators/instinct/mi300/mi300x.html