当前位置：首页 > news >正文

AMD RDNA3 GPU架构解析

news 2025/9/4 12:32:48

本文会通过把AMD的RDNA3架构为例比喻为**“施工公司”**工作模式，深入理解GPU如何高效处理顶点着色、像素计算等任务。

WGP（Work Group Processor）：相当于一个大型施工公司，负责统筹管理两个施工队。
CU（Compute Unit）：每个WGP下属的两个施工队。
SIMD模式：每个施工队会有两个小分队，小分队采用“批量施工”模式——比如挖土就所有点位一起挖土，倒混凝土就全部一起倒混凝土，铺钢筋就一起铺钢筋，即使有的点位提前完成了挖土，也要等其他的点位都完成才能倒混凝土（这就是Single Instruction Multiple Data (SIMD)，单指令多数据架构——每个线程各自处理一个顶点或者像素，执行相同的指令，但是处理不同的数据）。

Wave32和Wave64：
基于SIMD模式，施工小分队的工作要么32点位一组一起干，或者64点位为一组一起干（wave32/wave64，即32线程一组或者64线程一组）。也就是wave32和wave64。
- Wave32模式：32个点位（线程）为一组，适合复杂任务（如分支判断多的场景）。
- Wave64模式：64个点位为一组，适合简单重复任务（如大规模矩阵计算）。
wavefront
- 如果施工小分队只有一个任务，那当这个任务中发生等待材料送达、等待水泥这些情况的时候，就会浪费时间。所以施工队会做多个任务。（任务相当于RDNA3的wavefront 的概念，wavefront 类似于 NVIDIA 的 warp，都是调度和执行的基本单位。每个 wavefront 包含多个线程，通常是32个。这些线程在同一个指令下同步执行，换句话说，同一个 wavefront 中的线程会执行相同的指令，但处理不同的数据。
- 每个施工队会做多少个任务要看资源的情况，最多做16个任务（因为RDNA 3则每个SIMD有16个slot）。
- 同一时刻一个施工小分队只能执行一个任务（一个SIMD上一次只能执行一个wavefront）。
- 任务不必按顺序执行，也不需要连续地执行完一个任务中的所有步骤。（分配的这些wavefront不必按顺序执行，也不需要连续地执行完一个wavefront的所有指令）

顶点/像素处理：当GPU需要顶点或800万像素，比如说绘制三角形，那么顶点着色器处理3个顶点；如果渲染4K画面，那么片段着色器需要处理830万像素。不管是3个顶点还是830万像素，硬件都会自动将它们打包：
- 每凑满32或64个点位，就分配给一个小分队。
- 程序员无需手动分组，完全由硬件和驱动自动完成。
计算着色器例外：compute shader需显式指定线程组大小（如[numthreads(64,1,1)]），这是唯一需要程序员干预的场景。

编译器与驱动的幕后优化：
- 分支复杂任务（如光线追踪中的条件判断）：优先选择Wave32模式，减少分支等待时间。
- 计算密集型任务（如纹理生成）：采用Wave64模式，最大化吞吐量。
程序员无需干预：优化过程完全由编译器和驱动根据代码特征自动完成。

资源类型	比喻	技术对应	容量限制（每CU）	特性
ALU	施工工人	算术逻辑单元	128个	同一时间只服务一个Wavefront
SGPR	公共工作手册	标量寄存器（常量、全局变量）	1024个	全队共享，内容统一
VGPR	各个施工点位工具箱	向量寄存器（线程私有变量）	2048个	每个线程独立占用，限制分队数量
LDS	公司内部仓库	本地数据存储（线程组共享内存）	64KB （验证？）	仅限本WGP使用，跨公司不可共享

VGPR的致命影响：
若每个Wavefront需256个VGPR，则每CU最多驻留 (2048 / 256 = 8) 个Wavefront，导致50%的算力闲置。
LDS的协作限制：
若一个线程组申请32KB LDS，则同一WGP最多同时运行2个线程组（64KB / 32KB）。

减少VGPR占用
- 复用寄存器变量，避免冗余存储。
- 示例：将临时计算结果直接用于下一阶段，而非创建新变量。
规避分支发散
- 用掩码运算替代条件分支（如 result = a * mask + b * (1 - mask)）。
- 统一控制流：尽量让所有线程走相同逻辑路径。
LDS的智慧使用
- 高频访问数据预加载到LDS（如粒子系统的位置信息）。
- 避免单个线程组占用超过50% LDS容量。
工具辅助分析
- 使用 Radeon GPU Profiler 监控Occupancy和资源瓶颈。
- 关注编译器警告（如VGPR/LDS超额分配提示）。