ROCm HIP：amd::Context 源码剖析，以及 device context 与 host context 的区别-北京尧图网络

本文基于 AMD ROCm 开源栈rocm-systems/projects/clr的源码剖析 ROCclr 运行时中核心对象amd::Context的设计与职责并结合 HIP 运行时hipamd说明两种典型上下文——per-deviceprimarycontext与host context——的差异。适合想深入理解 ROCm/HIP 内存管理与设备抽象的读者。目录1、背景ROCclr 在 ROCm 栈中的位置2、amd::Context是什么3、核心职责逐条拆解3.1 设备集合管理与引用计数3.2 主机内存分配 hostAlloc / hostFree3.3 SVM 分配 svmAlloc / svmFree3.4 互操作与属性4、device context vs host context4.1 device context单设备的 primary context4.2 host context跨全部设备的全局上下文4.3 对照表5、调用链6、总结1、背景ROCclr 在 ROCm 栈中的位置ROCm 的用户态运行时大致分层如下HIP API (hipamd) - 用户直接调用的 hipMalloc / hipLaunchKernel 等 | ROCclr (rocclr) - Common Language Runtime设备抽象、内存对象、命令队列 | ROCr / HSA runtime - 硬件抽象层直接和 KFD/驱动打交道 | amdgpu / KFD (内核态)amd::Context属于ROCclr 层是连接“上层 API 语义”和“下层设备资源”的关键枢纽对象。无论是 OpenCL 的cl_context还是 HIP 的设备上下文最终都落到这个类上。2、amd::Context是什么打开头文件rocclr/platform/context.hpp类定义的第一行就点明了它的身份classContext:publicRuntimeObject{std::vectorDevice*devices_;// ...};RuntimeObject继承自ReferenceCountedObject和ICDDispatchedObject这意味着Context是引用计数对象通过retain()/release()管理生命周期而非裸delete是可被 OpenCL ICD 分发的对象可以在cl_context和内部对象之间安全转换。一句话概括它的本质Context就是“一组Device*的聚合”同时是这组设备之上一切内存分配与资源生命周期的“归属域ownership domain”。值得强调的是Context类本身并不区分“host”还是“device”。所谓 host context / device context 的差异完全取决于构造它时传入了哪些设备。这是理解本文后半部分的关键。3、核心职责逐条拆解下面结合实现文件rocclr/platform/context.cpp逐条分析。3.1 设备集合管理与引用计数构造函数遍历传入的设备列表对每个设备retain()并在此过程中筛选出两类“特殊设备”Context::Context(conststd::vectorDevice*devices,constInfoinfo):devices_(devices),info_(info),properties_(NULL),glenv_(NULL),customHostAllocDevice_(NULL){for(constautodevice:devices){device-retain();// 1) 第一个具备“自定义 host 分配器”的设备if(customHostAllocDevice_NULLdevice-customHostAllocator()){customHostAllocDevice_device;}// 2) 所有支持 SVM 的设备if(device-svmSupport()){svmAllocDevice_.push_back(device);}}// 多设备场景下把“细粒度系统不支持”的设备排到最前优先在它上面分配if(svmAllocDevice_.size()1){uint isFirstDeviceFGSEnabledsvmAllocDevice_.front()-isFineGrainedSystem(true);for(autodev:svmAllocDevice_){if(isFirstDeviceFGSEnabled!dev-isFineGrainedSystem(true)){std::swap(svmAllocDevice_.front(),dev);break;}}}}析构函数则做对称的清理解绑 D3D/GL interop、通知设备ContextDestroy()、逐个release()设备。Context因此成为设备生命周期的持有者。3.2 主机内存分配 hostAlloc / hostFreeContext提供统一的主机内存分配入口。它优先使用设备提供的“自定义 host 分配器”通常是 pinned / page-locked 内存DMA 更快否则退回普通对齐分配void*Context::hostAlloc(size_t size,size_t alignment,boolatomics)const{if(customHostAllocDevice_!NULL){returncustomHostAllocDevice_-hostAlloc(size,alignment,atomics?Device::MemorySegment::kAtomics:Device::MemorySegment::kNoAtomics);}returnAlignedMemory::allocate(size,alignment);}voidContext::hostFree(void*ptr)const{if(customHostAllocDevice_!NULL){customHostAllocDevice_-hostFree(ptr);return;}AlignedMemory::deallocate(ptr);}3.3 SVM 分配 svmAlloc / svmFreeSVMShared Virtual Memory共享虚拟内存是让 CPU 和多个 GPU 使用同一虚拟地址访问同一块内存的机制。Context的svmAlloc会在所有支持 SVM 的设备上把同一地址映射一遍void*Context::svmAlloc(size_t size,size_t alignment,cl_svm_mem_flags flags,constamd::Device*curDev,void*svmPtr){unsignedintnumSVMDevsvmAllocDevice_.size();if(numSVMDev1){returnnullptr;}void*svmPtrAllocedsvmPtr;amd::ScopedLocklock(ctxLock_);// 优先在“当前设备”上分配if(curDev!nullptr){if(!(flagsCL_MEM_SVM_ATOMICS)||(curDev-info().svmCapabilities_CL_DEVICE_SVM_ATOMICS)){svmPtrAllocedcurDev-svmAlloc(*this,size,alignment,flags,svmPtrAlloced);if(svmPtrAllocednullptr)returnnullptr;}}// 再在其余支持 SVM 的设备上映射同一地址for(constautodev:svmAllocDevice_){if(devcurDev)continue;if((flagsCL_MEM_SVM_ATOMICS)!(dev-info().svmCapabilities_CL_DEVICE_SVM_ATOMICS)){continue;// 该设备不支持平台原子跳过}svmPtrAlloceddev-svmAlloc(*this,size,alignment,flags,svmPtrAlloced);if(svmPtrAllocednullptr)returnnullptr;}returnsvmPtrAlloced;}svmFree中还有一处值得注意的多 GPU 竞态防护先原子地从全局映射表移除该内存对象再逐设备释放 GPU 虚拟地址最后才真正release()避免并发分配复用同一 VA 时被错误释放voidContext::svmFree(void*ptr)const{amd::ScopedLocklock(ctxLock_);amd::Memory*svmMemamd::MemObjMap::FindAndRemoveMemObj(ptr);if(svmMem!nullptr!svmAllocDevice_.empty()){svmAllocDevice_.front()-SetSvmAttributes(ptr,svmMem-getSize(),amd::MemoryAdvice::ResetAttributes);}for(constautodev:svmAllocDevice_){dev-svmFree(ptr);}if(svmMem!nullptr){svmMem-release();}}3.4 互操作与属性除了内存分配Context还保存了Info info_D3D10/D3D11/GL 等 interop 标志与句柄cl_context_properties* properties_原始属性GLFunctions* glenv_OpenGL 上下文Monitor ctxLock_对上下文串行化访问的锁Windows 平台上的 D3D10/D3D11 扩展缓存。4、device context vs host context明确了Context的本质后来看代码库里两种典型的实例。它们复用同一个amd::Context类差别仅在于构造时传入的设备列表。4.1 device context单设备的 primary context在每个 ROCm 设备初始化时rocclr/device/rocm/rocdevice.cpp会为该设备单独创建一个 Context源码注释直接写着 “dummy context”amd::Context::Info info{0};std::vectoramd::Device*devices{this};// 注意只有 this 一个设备// Create a dummy contextcontext_newamd::Context(devices,info);这个 Context 存放在amd::Device::context_中通过amd::Device::context()暴露。到了 HIP 层hip::Device直接复用它而不是新建// hipamd/src/hip_context.cpp init()for(size_t i0;idevice_count;i){amd::Device*constamd_devicedevices[i];amd_device-SetActiveWait(true);// 复用 amd::Device 里已有的“永生”上下文auto*devicenewDevice(amd_device-context(),static_castunsignedint(i));// ...}hip::Device通过asContext()返回这个单设备上下文它就相当于 CUDA 里每个设备的primary context// hipamd/src/hip_internal.hppclassDevice:publicamd::ReferenceCountedObject{amd::Context*asContext()const{returncontext_;}// ...amd::Context*context_;//! ROCclr context单设备};由于它的devices_里只有 1 个设备所有基于它的 buffer、内核、命令队列、内存分配都绑定到这一个 GPU。4.2 host context跨全部设备的全局上下文在 HIP 初始化的末尾hip_context.cpp又创建了一个覆盖全部 GPU的全局上下文host_context// hipamd/src/hip_context.cppamd::Context*host_contextnullptr;// 全局变量voidinit(bool*status){// ... 枚举全部 GPU 到 devices ...// Create and initialize host contexthost_contextnewamd::Context(devices,amd::Context::Info());// 传入全部设备if(!host_context||CL_SUCCESS!host_context-create(nullptr)){// ...}amd::RuntimeTearDown::RegisterObject(host_context);}它的用途是处理不绑定到具体设备的分配最典型的是纯 SVM / 系统内存可访问的分配。getNullStream()对此有专门判断——当传入的 ctx 是host_context时选哪个设备的 null stream 都无所谓hip::Stream*getNullStream(amd::Contextctx,boolwait){for(constautoit:g_devices){if(it-asContext()ctx){// 命中某个 device contextreturnit-NullStream(wait);}}// 纯 SVM / 系统内存访问用哪个设备默认流都行if(hip::host_contextctx){returngetNullStream(wait);// 回退到当前设备}returnnullptr;}因为它的devices_含全部 GPUsvmAlloc()会在每个设备上都映射同一地址从而实现跨设备统一寻址。补充ROCclr 内部还有一个类似性质的glb_ctx_见rocdevice.cpp同样覆盖全部设备专供 P2P staging 等驱动内部分配使用属于更底层的“全设备上下文”。4.3 对照表维度device contextprimaryhost context创建位置rocclr/device/rocm/rocdevice.cppcontext_ new amd::Context(...)hipamd/src/hip_context.cpphost_context new amd::Context(...)devices_内容单个设备this全部 GPU归属层ROCclramd::Device拥有HIP 全局单例典型用途该设备上的 buffer / 内核 / 队列per-device 分配跨设备 SVM / 系统内存、与设备无关的分配SVM 行为只在 1 个设备上映射在所有设备上映射同一 VAHIP 暴露方式hip::Device::asContext()全局hip::host_context语义类比CUDA 的 device primary context一个“与具体设备无关”的兜底上下文5、调用链HIP 层 (hipamd)ROCclr 层拥有asContext 复用devices_ 1 个 GPUdevices_ 全部 GPUamd::Devicedevice contextamd::Context(devices{this})单设备glb_ctx_amd::Context(全部设备)驱动内部 P2Phip::Devicehost_contextamd::Context(全部设备)全局单例per-device 分配绑定单个 GPUSVM / 系统内存跨设备统一寻址6、总结amd::Context是 ROCclr 中引用计数的“设备集合分配归属域”统一承载 host 内存分配、SVM 分配、interop 属性与资源生命周期。它本身不区分host / device差异完全来自构造时传入的设备列表范围。device context只含单个 GPU是每个设备的 primary contextHIP 通过hip::Device::asContext()复用per-device 的 buffer、内核、分配都落在这一个设备上。host context覆盖全部 GPU是 HIP 的全局单例专门服务跨设备 SVM / 与具体设备无关的主机侧分配。二者共用同一套svmAlloc逻辑但因设备列表不同一个只映射单卡地址一个在所有卡上映射同一 VA从而支撑起 ROCm 的统一虚拟内存模型。理解这两类 Context 的分工是读懂 HIP 内存管理hipMalloc/hipMallocManaged/ SVM与多 GPU 寻址的基础。

ROCm HIP：amd::Context 源码剖析，以及 device context 与 host context 的区别

相关推荐

MSP430BT5190外设深度解析：从寄存器到低功耗系统设计实战

编程Agent架构设计与工程实践指南

蔡司三维扫描仪在电子精密零件制造中的质量控制应用

更多资讯

河南电工证的考试千万别踩坑电工证过期了别慌有办法

新青区电工证怎么考通过率揭秘：别再被中介坑了

营口电工证哪里有考前押题全攻略，实操考试心里没底怕挂科怎么办

电工证多少钱包过？真实经历告诉你驻马店施工企业怎么避坑

临高低压电工证查询怎么搞？全国通用怕考不过？

工地太忙根本没时间复习考试？辽阳低压电工证真证+考前押题帮你上岸

今日更新

西昌市电工作业查询怎么查？郑州报考避坑指南帮你少走弯路

西昌市电工作业查询通过率揭秘：怕考不过白交培训费？这几点要记牢

临夏电工证在哪里审官方报名入口怎么找

本周精选

安监局电工证分数查询怎么查才能知道含金量高不高

新疆电工作业干活累吗良心建议助你避开考不过的坑

中牟县电工证怎么报名外省证能转吗

本月热门

面向复杂光照与角度的宠物面部识别鲁棒性增强策略

基于DRV8818与STM32的双极步进电机驱动方案实战解析

DRV8818PWPR+PIC18F45K80双极步进电机控制方案实战

读完文章，想聊聊您的网站？