1. 从改一版RTL到定义一代架构先厘清问题边界很多人第一次接触GPU微架构设计时脑子里想的其实是我要做一个更快的GPU。这个想法本身没错但它离一代新的微架构还差着十万八千里。我在实际参与和观察过若干次架构迭代之后最大的体会是改一版RTL、加几个执行单元、把频率拉高这些叫改进而一代新的微架构是ISA、编程模型、存储层次、调度机制、验证方法学同时发生结构性变化的结果。先把问题边界划清楚。GPU微架构设计这个领域横跨计算机体系结构、数字电路设计、编译器、驱动开发、仿真验证几个方向。你如果只是想把某个开源GPU核比如一些教学用的软核跑通那属于实现层面而怎样才算得到一代新的微架构问的是架构演进的判定标准——什么程度的改动才配得上新一代这三个字。这个问题之所以值得认真讨论是因为它直接决定了你的项目节奏、团队分工和验证投入。如果你把一次小改当新一代来做会浪费大量验证资源如果你把一次结构性变革当小改来做最后会发现驱动、编译器、仿真环境全部要推倒重来。提示本文讨论的一代新微架构指的是相对上一代产品/版本在架构层面有可被外部观测到的、系统性的行为差异而不是单纯的PPA功耗、性能、面积微调。关键词里出现的GPU仿真、ISA、计算机体系结构其实正好对应了判定新一代的三个核心维度指令集是否变、仿真模型是否要重建、体系结构假设是否被打破。下面我会围绕这几个维度结合我在实际项目中的观察把怎样才算一代新微架构这件事拆开讲。2. ISA的变动幅度判断新一代的第一把尺子2.1 为什么ISA是架构代际的分水岭在计算机体系结构里ISA指令集架构是软硬件之间的契约。GPU和CPU在这点上有个重要区别CPU的ISA相对稳定几十年兼容而GPU的ISA往往和具体微架构强绑定每一代都可能调整。这就导致一个现象——GPU的新一代往往从ISA的变动开始。我见过不少团队把ISA的改动当成顺手加几条指令结果发现编译器后端、驱动、仿真器全都要跟着动。所以判断是不是新一代第一件事就是看ISA的变动属于哪个层级ISA变动类型典型表现是否构成新一代新增少量专用指令加几条矩阵乘、位操作指令通常不算属于增量指令编码格式调整位域重新划分、操作码扩展视情况可能算执行模型变化从SIMT到SIMT张量核协同算结构性变化编程模型暴露变化新增warp级原语、内存模型语义算且影响面大这张表是我自己总结的经验判断不是教科书标准。核心逻辑是如果ISA的变动会迫使上层软件编译器、驱动、库重新设计那它就有资格被称为新一代的起点。2.2 从SIMT到新执行模型的演进逻辑GPU微架构最核心的假设是SIMT单指令多线程。一代新架构往往意味着对这个假设的扩展或重构。比如引入张量核心之后执行单元不再是单纯的SIMT lanes而是SIMT lanes 矩阵运算单元的异构组合。这时候ISA必须新增矩阵指令调度器必须能区分两类任务的发射寄存器文件要重新规划带宽。我在仿真环境里验证这类改动时最深的体会是你不能只仿真新增的指令还要仿真新旧指令混跑时的资源竞争。很多bug不是出在单条指令上而是出在warp调度器在两类指令之间切换时的状态管理上。这一点在纯RTL仿真里很难覆盖必须靠架构级仿真比如基于SystemC或专用GPU仿真框架来跑长序列。2.3 ISA变动对仿真模型的连锁影响这里要重点说一个容易被低估的环节ISA一变仿真模型的可信度就要重新建立。我见过团队改完ISA之后直接拿旧的功能模型跑新指令结果功能对了、时序全错。原因是旧模型里的延迟假设、吞吐假设都是按老ISA设计的。正确的做法是ISA变动后先更新功能模型保证指令语义正确再更新时序模型保证延迟/吞吐假设匹配新微架构最后做两者的一致性校验。这个流程听起来简单但实际做的时候功能模型和时序模型的接口往往需要重新定义。我在一个项目里就吃过亏——功能模型按指令级建模时序模型按warp级建模ISA一改两者的粒度对不上调试花了两周。注意ISA变动后务必先冻结指令语义再动时序模型。语义没冻结就调时序等于在流沙上盖楼。3. 微架构层面的结构性变化哪些改动才算动骨架3.1 执行单元组织的重构如果说ISA是契约那微架构就是实现契约的骨架。一代新微架构通常在执行单元组织上有结构性变化。举几个我实际接触过的方向SM流多处理器内部划分变化比如从统一lane阵列变成分簇cluster结构每个簇有自己的调度器和寄存器文件。调度粒度变化从warp级调度细化到sub-warp级或者引入双发射。存储层次重构L1/shared memory的划分比例、bank结构、访问粒度变化。这些改动的共同点是它们改变了数据在芯片内部的流动方式。判断是否构成新一代我的经验标准是——如果数据流图dataflow需要重画那就是结构性变化。3.2 存储层次与带宽假设的打破GPU是带宽敏感型架构。一代新微架构往往伴随着对带宽假设的重新评估。比如上一代假设L2带宽足够覆盖所有SM的并发访问新一代发现这个假设不成立必须引入更细粒度的分区或压缩。上一代假设shared memory访问延迟固定新一代引入可配置的延迟/带宽权衡。我在做仿真时习惯先建一个带宽压力模型把最坏情况下的并发访问量算出来和各级存储的带宽上限对比。如果新一代架构的某个改动让这个比值发生了数量级变化那基本可以判定是新一代级别的改动。具体怎么算举个简化例子假设有N个SM每个SM每周期最多发起M次L1访问L1到L2的带宽是B字节/周期每次访问W字节。那么需要的L2带宽是 N×M×W如果这个值持续大于B就说明存储层次需要重构。这个计算不复杂但很多团队在架构评审时恰恰漏掉了这一步等到仿真跑出瓶颈才回头改。3.3 调度与并发模型的演进调度器是GPU微架构里最玄学的部分。一代新架构调度策略往往有本质变化。比如从贪心发射变成基于依赖图的发射或者引入硬件级的warp优先级管理。这里有个实操心得调度策略的改动最难的不是设计而是验证。因为调度是动态行为穷举测试不现实。我的做法是建一个调度压力测试集专门构造极端场景——比如所有warp同时就绪、所有warp同时阻塞、长短warp混合。这些场景在正常负载下很少出现但恰恰是暴露调度bug的关键。4. 仿真验证新一代架构的试金石4.1 为什么架构级仿真不可替代GPU仿真在这个话题里不是配角而是主角。原因很简单一代新微架构的很多假设只有通过架构级仿真才能验证。RTL仿真太慢跑不了真实负载纯性能模型又太粗抓不住微架构细节。我常用的仿真分层是这样的功能级仿真验证ISA语义速度最快精度最低。架构级仿真建模执行单元、存储层次、调度器精度和速度折中。RTL仿真最精确但只能跑短序列。判断是不是新一代我通常看架构级仿真是否需要重建。如果旧仿真框架的抽象层次、接口、假设全部要改那说明架构变动足够大。4.2 仿真精度与速度的取舍这是每个做GPU仿真的人都要面对的问题。我的经验是不要追求全能仿真器要针对问题选精度。比如验证ISA语义功能级就够验证带宽瓶颈架构级必须验证时序违例只能上RTL。具体取舍可以看这张表验证目标推荐仿真层级典型速度精度要求指令语义正确性功能级极快低性能趋势架构级中等中资源竞争架构级中等中高时序收敛RTL慢极高我在实际项目里的做法是先用功能级跑通所有新指令再用架构级跑典型负载看趋势最后用RTL验证关键路径。三层配合既保证覆盖又不至于被仿真速度拖死。4.3 用仿真结果反推架构代际一个很实用的技巧把仿真结果和上一代做对比看差异是否系统性。如果只是某些负载快了一点那是优化如果所有负载的性能曲线形状都变了那很可能是架构代际变化。我习惯画性能-负载特征散点图横轴是负载的某种特征比如访存密度纵轴是相对上一代的加速比。如果散点呈现明显的分区比如访存密集型普遍提升、计算密集型不变说明架构改动有针对性如果散点整体平移说明是全局性变化。这个方法帮我好几次在评审时快速判断改动的代际属性。5. 驱动与软件栈被忽视的代际判定维度5.1 驱动改动量反映架构变动深度很多人判断新一代只看硬件其实驱动和软件栈的改动量是更诚实的指标。如果驱动需要重写核心调度逻辑那基本就是新一代。因为驱动是硬件行为的翻译层硬件假设一变翻译层就得重写。我见过一个案例硬件团队觉得只是小改结果驱动团队发现内存管理单元的行为变了整个虚拟地址映射逻辑要重做。最后项目延期三个月。教训是架构评审必须拉上驱动和编译器团队否则代际判定会失真。5.2 编译器后端的适配成本编译器后端是另一个照妖镜。ISA一变指令选择、寄存器分配、调度都要动。如果新增的是正交指令不影响现有指令的调度成本可控如果新增指令和现有指令有资源冲突那后端要重新做资源建模。我的经验是评估编译器适配成本看指令调度表要不要重写。调度表重写说明微架构的延迟/吞吐假设变了这就是代际级别的改动。5.3 从软件视角看新一代的判定综合来看从软件视角判定新一代可以看三个信号驱动是否需要新的硬件抽象层。编译器是否需要新的调度模型。上层库如数学库、深度学习框架是否需要新的kernel实现。三个信号里有两个以上为是基本可以判定为新一代微架构。6. 实操中的判定流程与常见误判6.1 一套可复用的判定清单把前面的内容整理成可操作的清单我在实际评审时就是这么过的ISA层指令语义、编码、编程模型是否变化变化是否影响上层软件微架构层数据流图是否重画存储层次假设是否打破调度策略是否重构仿真层架构级仿真框架是否需要重建精度/速度权衡是否改变软件层驱动、编译器、库是否需要结构性适配四项里有两项以上为是我倾向于判定为新一代。6.2 把优化误判为新一代的代价最常见的误判是把优化当换代。比如把L2容量加大、把频率提高这些是优化不是换代。误判的代价是验证资源被过度投入项目节奏被打乱。我自己的教训是有一次把新增几条指令当成新一代来做结果验证团队按新架构标准建了一整套环境最后发现旧环境稍作扩展就能覆盖。浪费了大概六周。从那以后我坚持先用上面的清单过一遍再决定投入级别。6.3 把换代低估为优化的风险反向误判更危险。把结构性变化当小改会导致驱动、编译器、仿真全部滞后。我见过最惨的情况是硬件流片回来驱动还没适配完芯片只能跑在兼容模式性能只有设计值的三成。避免这种误判的方法就是前面说的——架构评审必须跨硬件、驱动、编译器、仿真四个团队。任何一方觉得改动很大都要重新评估代际属性。7. 我个人在GPU微架构迭代中的几点体会做了这些年有几个体会是文档里不会写的。第一新一代的判定不是技术问题是沟通问题。硬件团队容易低估软件适配成本软件团队容易高估硬件改动难度。判定标准要提前对齐不能等改完了再吵。第二仿真环境的建设要超前于架构设计。我现在的习惯是架构方案还没定先想这个方案要怎么仿真验证。如果仿真方案想不出来架构方案大概率有问题。第三ISA的稳定性比性能更重要。一代新架构如果ISA变动过大软件生态的迁移成本会吃掉性能收益。这也是为什么很多成功的GPU架构ISA变动都是增量式的。第四判定新一代的最终标准是看它是否改变了编程模型。如果程序员写代码的方式变了比如从手动管理shared memory到自动管理那就是真正的新一代。如果只是跑得更快那还是同一代。最后分享一个实用技巧在架构设计早期画一张假设依赖图——把架构依赖的所有关键假设带宽、延迟、并发度列出来标注每个假设的置信度。新一代架构的标志就是有若干高置信度假设被打破。这张图我每次做架构评审都会画比任何PPT都管用。