# Chiplet GPU 的 CP 建模：gem5 AMDGPU 分析、MI250X 驱动详解与建模路径

代码证据来源gem5本机/home/hipper/ex_gem5_/gem5Linux amdgpu 驱动本机/usr/src/amdgpu-6.3.6-1718217.22.04AMD DKMS 版 KMD 6.3.6对应 ROCm 6.3上游内核路径为drivers/gpu/drm/amd/...1. gem5 AMDGPU 的 CP 建模现状有骨架无微架构1.1 已有的部分组件位置说明PM4 包处理器src/dev/amdgpu/pm4_packet_processor.cc约 1250 行解析 PM4 包但pm4_defines.hh只定义13 种 opcodeIT_NOP0x10、IT_WRITE_DATA0x37、IT_WAIT_REG_MEM0x3C、IT_INDIRECT_BUFFER0x3F、IT_RELEASE_MEM0x49、IT_SET_UCONFIG_REG0x79、IT_SWITCH_BUFFER0x8B、IT_INVALIDATE_TLBS0x98、IT_MAP_PROCESS0xA1、IT_MAP_QUEUES0xA2、IT_UNMAP_QUEUES0xA3、IT_QUERY_STATUS0xA4、IT_RUN_LIST0xA5是跑通 ROCm/KFD compute 路径的最小子集真实硬件 PM4 有 60 种队列描述符src/dev/amdgpu/pm4_queues.hhHQDhardware queue descriptor结构体直接取自 Linux 内核drivers/gpu/drm/amd/include/v9_structs.hMMIO 寄存器src/dev/amdgpu/pm4_mmio.hh仅 70 行doorbell、队列基址等寥寥几个HSA 层调度src/gpu-compute/gpu_command_processor.ccsrc/dev/hsa/hw_scheduler.cc在 HSA/AQL 层面做队列唤醒wakeup event与 kernel dispatch交给GPUDispatcher创建/分发 WGSDMAsrc/dev/amdgpu/sdma_engine.cc有独立的 SDMA 引擎模型1.2 缺失的部分没有 CP 微架构本体。真实 CP 是运行闭源固件RLC/CP ucode/MES的微控制器有取指/译码/执行的 ring buffer 处理流水线——gem5 完全没有建模。PM4 包是 DMA 读入后功能级立即处理无 CP 侧 cycle 时序。没有 MESMicrocode Engine Scheduler与多 compute ring 的硬件调度。寄存器空间只有零头。真实 AMD GPU 有数万个 MMIO 寄存器gem5 只实现了仿真 ROCm 所需的最小集合。图形流水线完全没有不支持 draw 类包。1.3 小结gem5 这么做的原因目标是跑通 ROCm 应用瓶颈在 CU 执行CP 只负责启动/收尾且 CP 固件闭源无法精确建模。想做较为精细的 CP 建模gem5 给不了现成的但它是各选项中最适合自研扩展的底座——前提是把建模粒度定在队列/包处理时序而非CP 固件执行后者因闭源在任何平台都做不到。2. 精细建模 CP 的三条路径关注点推荐路径工作量chiplet 间 WG 分配/负载均衡/调度开销多数 chiplet GPU 研究的实际切入点扩展 gem5HWSchedulerGPUDispatcher加 chiplet 感知队列调度与非对称 dispatch 延迟Ruby/Garnet 可定制 xGMI/IF 拓扑中CP 命令处理本身的时序doorbell→ring→dispatch 延迟链无现成开源模拟器。以 Linuxdrivers/gpu/drm/amd/amdgpu/为权威行为参考gfx_v9_4_2.cring 管理、amdgpu_mes.c、寄存器头文件自建时序层大嫌 gem5 太重MGPUSimAkita 框架GoGCN3原生多 GPU模块化好或 rocprofiler trace 自写事件驱动仿真器中/小注意gem5、MGPUSim、GPGPU-Sim 的 CP全部是功能级抽象CP 精细建模目前是所有开源模拟器的空白——既是坑也是发论文的机会。3. 参考资料Chiplet / 多计算 die GPU 体系结构3.1 学术奠基论文工作出处内容MCM-GPUArunkumar, Bolotin, Milic, Ebrahimi, Villa, Jaleel, Wu, NellansNVIDIA ResearchISCA 2017领域开山之作。基于 GPGPU-Sim 3.x系统论述 MCM-GPU 的 CTA 跨 die 调度、内存侧 L2 划分、页放置、die 间互连带宽敏感性。设计空间论述最完整的单篇必读。注意其扩展代码据查未官方开源后续研究者多自行重写Beyond the Socket: NUMA-aware GPUsMilic et al.MICRO 2017多 GPU/分区的 NUMA 效应MCM-GPU 的姊妹篇SimbaShao et al.NVIDIAMICRO 201936-chiplet DL 推理芯片实际流片。chiplet 粒度选择、NoPnetwork-on-package、全局同步的论述最好。虽非 GPU但多计算 die 组织成一个大设备的方法论通用Summarizing CPU and GPU Design Trends with Product DataYifan Sun et al.arXiv 2019用产品数据含 AMD/NVIDIA 多 die 演进总结 GPU 趋势背景调研好用3.2 模拟器/开源项目项目说明状态GPGPU-Sim 3.x / Accel-SimNVIDIA 执行模型MCM-GPU 的母体活跃MGPUSim Akitagitlab.com/akita/mgpusimGo、GCN3 ISA、原生多 GPU做多 die 扩展最顺手MGPUSim 已归档只读可用/ Akita 维护中gem5多 GPU 支持 Ruby 可定制一致性活跃BookSim / Garnet只建 die 间互连网络时配合用活跃3.3 商业架构参考“真实 chiplet GPU 怎么做”AMD MI250X (GFX90a)2 个 GCDFrontier 超算Hot Chips 34 (2022)。Linuxamdgpu驱动是研究其双 die 行为的最佳公开代码见 §4。AMD MI300A/XXCD CCD IOD、3D 混合键合Hot Chips 2023。chiplet 分工最激进。Intel Ponte Vecchio47 tiles、Foveros/EMIB、Xe LinkHot Chips 33 (2021) IEEE Micro 文章。NVIDIA Blackwell B200双 reticle die NV-HBI10 TB/s die-to-dieHot Chips 2024。强调两个 die 表现为单一统一 GPU——与 CP/调度如何对上层隐藏多 die 直接相关。NVIDIA GRSGround-Referenced SignalingSimba/Blackwell 背后的 die 间短距信号技术JSSC/ISSCC 论文互连功耗/带宽建模的依据。3.4 与 CP 主题的交叉点真正跨计算 die 的 kernel/CTA 调度研究源头是MCM-GPU 的 CTA scheduler后续多延续GigaThread 引擎 die 感知化路线。没有任何公开工作精细建模AMD CP 固件在 chiplet 间的行为——空白地带。检索关键词MCM-GPU、multi-chip-module GPU、chiplet GPU scheduling、die-to-die interconnect GPU、NUMA-aware GPU。4. 案例详解AMD MI250X 的 Linux amdgpu 驱动与双 die 行为MI250X代号AldebaranGFX90aCDNA2是一个封装内 2 个 GCD 的 chiplet GPU。内核驱动是理解双 die 在系统软件眼中到底是什么的最权威材料。以下全部基于本机 DKMS 源码KMD 6.3.6。4.1 硬件组织一个封装两个独立 PCI 设备关键事实MI250X 的两个 die 不作为统一设备暴露而是两个独立的 PCI 设备各自有独立 BDF、BAR、amdgpu_device实例。驱动 PCI ID 表amd/amdgpu/amdgpu_drv.c:2029-2032{0x1002,0x7408,PCI_ANY_ID,PCI_ANY_ID,0,0,CHIP_ALDEBARAN},{0x1002,0x740C,PCI_ANY_ID,PCI_ANY_ID,0,0,CHIP_ALDEBARAN},{0x1002,0x740F,PCI_ANY_ID,PCI_ANY_ID,0,0,CHIP_ALDEBARAN},{0x1002,0x7410,PCI_ANY_ID,PCI_ANY_ID,0,0,CHIP_ALDEBARAN},4 个 DID 对应 MI210/MI250/MI250X 等 SKU。每个 die probe 出一个完整的amdgpu_device有独立的 CP、ring、KFD 队列、HBM 段。双 die 之间的纽带不是一个设备内部而是内核的 xGMI hive 抽象——从驱动结构看chiplet GPUMI250X 风格在调度语义上等价于多 GPU。4.2 xGMI Hive内核中的多 die 抽象struct amdgpu_xgmiamd/amdgpu/amdgpu_gmc.h:168structamdgpu_xgmi{/* from psp */u64 node_id;u64 hive_id;/* fixed per family */u64 node_segment_size;/* physical node (0-3) */unsignedphysical_node_id;/* number of nodes (0-4) */unsignednum_physical_nodes;/* gpu list in the same hive */structlist_headhead;bool supported;structras_common_if*ras_if;bool connected_to_cpu;/* Frontier 形态经一致性 xGMI 连 CPU */bool pending_reset;structamdgpu_xgmi_ras*ras;};Hive 组建流程amdgpu_xgmi.c: amdgpu_xgmi_add_device()驱动通过PSP 固件Platform Security Processor完成链路层工作psp_xgmi_initialize()→psp_xgmi_get_hive_id()→psp_xgmi_get_node_id()。xGMI 链路训练/拓扑发现不在内核而在固件内核只是查询。同 hive_id 的设备挂入共享的amdgpu_hive_info含device_list、hive_lock、任务 barrier。每加入一个 die调用amdgpu_xgmi_update_topology()并用psp_xgmi_get_topology_info()向所有成员同步最新拓扑全互联视图表。die 间距离以跳数表示amdgpu_xgmi_get_hops_count()从 PSP 拓扑表读num_hopsamdgpu_xgmi.c:737起。用户态可见/sys/.../xgmi_node_id、xgmi_physical_node_idamdgpu_xgmi.c:377/388。4.3 统一物理地址空间node segment 分段双 die 间 P2P 内存访问的实现核心在 GMC 初始化amd/amdgpu/amdgpu_gmc.c:248-250u64 hive_vram_endmc-xgmi.node_segment_size*mc-xgmi.num_physical_nodes-1;mc-vram_startmc-xgmi.node_segment_size*mc-xgmi.physical_node_id;mc-vram_endmc-vram_startmc-xgmi.node_segment_size-1;整个 hive 是一个统一物理地址空间node_segment_size × num_physical_nodes每个 die 占其中一段段基址 physical_node_id × node_segment_size。跨 die 访问 页表项直接编码全局地址由 XGMI fabric 按地址段路由到目标 die“far memory”。amdgpu_xgmi_get_relative_phy_addr()amdgpu_xgmi.c:973即addr physical_node_id * node_segment_size。physical_node_id与seg_size由 firmware 预配置在MC_VM_XGMI_LFB_CNTL寄存器PF_LFB_REGION字段等驱动在gfxhub_v1_2.c:600-615读取——硬件告诉软件我是 hive 里的第几个 die、每段多大。MI250X 每 die 64GB HBM2e4 stackhive 全局 VRAM 视图 128GB。建模要点这套地址段 fabric 路由机制与 gem5 的多 GPU 地址映射/ Ruby 目录完全可以对应是实现 MI250X 风格双 die 的最小机制。4.4 KFD 拓扑双 die 如何暴露给用户态每个 die 是一个独立KFD node/sys/class/kfd/kfd/topology/nodes/nkfd_device.c:760kfd-hive_id kfd-adev-gmc.xgmi.hive_id。die 间链路写进CRAT表kfd_fill_gpu_xgmi_link_to_gpu()kfd_crat.c:1994类型CRAT_IOLINK_TYPE_XGMI链路权重用iolink-weight_xgmikfd_crat.c:1167-1168跳数来自 §4.2 的 PSP 拓扑。用户态ROCr/HIP据此做 NUMA 式放置选择 agentdie→ 在该 die 上建队列 → 分配内存时按链路 weight/hops 决定本地或远端。SVM统一虚拟内存中跨 die 共享以amdgpu_xgmi_same_hive()判断可行性kfd_svm.c:1204。4.5 CP/队列每 die 独立无跨 die 硬件调度这是对 chiplet CP 建模最重要的一节每个 die 有完整的独立 CP 复合体GFX ring compute ringsMEC/HWS 每 die 一套。gfx_v9_4_2.cGC 9.4.2 Aldebaran 专有初始化中可见驱动直接用adev-gfx.compute_ring[0]、[1]提交 golden SGPR/VGPR 初始化 compute shadergfx_v9_4_2_do_sgprs_init()等ring 全部是 per-device per-die资源。不存在硬件级跨 die workgroup 分发一个队列固定属于一个 die 的 HQD跨 die 的负载划分完全由软件完成——应用用 HIP multi-device 显式在两个 device 上各建 stream/queue或靠运行时按拓扑拆分。die 间数据共享靠 §4.3 的统一地址 P2P一致性由 fabric 硬件维护对 CP 透明。结论MI250X 的chiplet性体现在内存/一致性/拓扑层而不在 CP/调度层。用模拟器复现 MI250X 行为不需要任何 CP 微架构创新——两个独立 GPU 节点 xGMI 段式地址空间 hive 拓扑即可。真正需要 CP/dispatcher 创新的是 MI300 那种统一设备形态§4.7。4.6 GPU Reset 的 hive 协同aldebaran.c427 行基本全部围绕一件事XGMI hive 中多节点的 mode2 reset 协同aldebaran_mode2_perform_reset()hive 内所有节点并行发 resetFor XGMI run all resets in parallel to speed up the process再统一等待完成amdgpu_xgmi的 task barrier 同步。恢复后amdgpu_xgmi_update_topology()重建 hive 拓扑。connected_to_cpuFrontier 形态MI250X 经一致性 xGMI 连 Trento EPYC决定默认 reset 方式aldebaran_is_mode2_default()。说明 chiplet GPU 的 RAS/reset 也是 hive 级问题建模时若关注可靠性场景需考虑。4.7 MI250X vs MI300软件显式 vs 硬件统一驱动里能直接看到两种 chiplet GPU 哲学的差异MI250XGFX90a / GC 9.4.2MI300GFX942 / GC 9.4.3设备形态每 die 一个 PCI 设备、一个amdgpu_device单 PCI 设备内部多 XCCAccelerated Compute Core即 XCD 复合体多 die 寻址多设备 xGMI hive 段式地址单设备内xcc_id实例选择RREG32_XCC(reg, inst)/WREG32_XCC(...)amdgpu.h:1265-1266aid_maskamdgpu.h:1140枚举实例跨 die 调度无硬件支持软件显式HIP multi-device硬件/固件将多 XCD 呈现为统一计算设备dispatcher 层做 die 间 WG 分配建模含义多 GPU 模型 互连即可必须建 chiplet 感知的 CP/dispatcher队列如何拆分、WG 如何落到不同 XCD、die 间缓存一致性对 dispatch 延迟的影响4.8 对 chiplet GPU 建模的启示先选定要建哪种 chiplet GPUMI250X 式软件显式多设备还是 MI300 式硬件统一设备。前者用现成模拟器拼多 GPU 定制互连即可后者才是需要扩展 CP/调度建模的场景。驱动是行为规范的金标准hive 组建、段式地址、CRAT 拓扑、reset 协同在amdgpu源码中全部可读且比任何论文都精确。建模 MI250X 风格时§4.2–4.6 的机制清单可直接当作要实现的最小功能集。CP 精细建模的合理落点对统一设备形态落点在dispatcher 的 die 感知 非对称 dispatch 时延 die 间一致性流量而不是 CP 固件执行闭源无据可依。5. 总结gem5 AMDGPU 的 CP 只有功能级骨架13 种 PM4 opcode、70 行 MMIO无 CP 微架构——直接用于精细 CP 建模不可行但作为扩展底座可行。若目标是 MI250X 式 chiplet GPU驱动分析表明其双 die 在调度语义上就是多 GPU无需 CP 创新重点建 xGMI 段式地址 hive 拓扑 die 间 NUMA。若目标是 MI300 式统一设备需要自研 chiplet 感知 dispatchergem5HWScheduler/GPUDispatcher扩展或 MGPUSim/Akita以 Linuxamdgpu源码为行为参照。领域空白AMD CP 固件级建模无人可做闭源队列/包处理时序 die 感知调度的中间粒度是可行且有发表空间的位置。