OpenCL context物理存储位置及同平台多GPU内存访问原理问询

首先要明确：OpenCL Context本身不是一块固定位置的实体内存块，它是OpenCL runtime维护的资源管理抽象容器，没有单一的物理存储位置，其包含的不同组成部分分散在不同存储介质中：

• Context的核心元数据：包括关联的设备列表、内存对象映射表、命令队列绑定关系、支持的扩展清单等，全部存储在主机端RAM中，由安装在系统上的厂商OpenCL驱动维护，GPU硬件本身不会存储完整的Context元信息。
• Context管辖的各类资源（缓冲区、程序对象、内核对象等）：存储位置完全由驱动根据资源创建标记、硬件拓扑动态决定，没有统一位置：
  • 创建时带CL_MEM_DEVICE_ONLY标记的缓冲区：默认优先驻留在目标设备的本地显存（例如独立显卡的GDDR/HBM显存）；如果Context关联了多个设备，驱动会为需要访问该缓冲区的设备按需维护数据副本
  • 创建时带CL_MEM_USE_HOST_PTR/CL_MEM_ALLOC_HOST_PTR标记的缓冲区：核心存储在主机RAM中，设备访问时驱动会临时将数据映射或拷贝到设备显存
  • 支持硬件互连带宽的平台上，部分缓冲区可能常驻在某一块GPU的显存中，供其他关联设备通过直连接口访问

这里首先要纠正一个常见误解：不存在“完全没有数据传输”的情况，只是所有数据迁移、访问的逻辑都被OpenCL驱动封装在底层实现了，上层开发者不需要手动调用显式数据传输接口而已，常见实现逻辑分三类：

• 驱动自动副本同步：当你向某个GPU的命令队列提交内核，内核需要访问某块缓冲区时，驱动会先检查该缓冲区的最新副本所在位置，如果最新数据不在当前GPU的本地显存，就会自动在后台通过PCIe、NVLink、Infinity Fabric等互联链路把数据拷贝到当前GPU，整个流程对上层代码完全透明，不需要开发者手动编写clEnqueueCopyBuffer类的传输命令。
• 硬件全局地址空间访存：如果同Context下的多GPU来自同一厂商且支持P2P直连（例如支持NVLink的多张NVIDIA显卡、通过Infinity Fabric互联的AMD显卡），驱动会把所有关联GPU的显存、可映射的主机RAM统一编入同一个虚拟地址空间，Context维护这个全局地址的映射表。GPU访问不在本地显存的地址时，硬件会自动通过互联链路跨卡读取数据，不需要提前做完整数据拷贝。
• 统一主机内存映射：如果缓冲区本身分配在主机RAM，且平台支持设备直接寻址主机内存（例如核显平台的共享内存架构、开启Resizable BAR的独显平台），所有关联GPU都可以直接通过PCIe访问主机RAM中的同一份数据，不需要额外生成本地副本，自然也不需要显式传输。

注意：这种透明访问不是零开销的。如果驱动频繁在后台做跨卡数据拷贝，性能损耗和手动编写传输逻辑没有区别，甚至因为调度逻辑不透明更难做性能调优，对性能敏感的多GPU场景，还是建议手动控制缓冲区的驻留位置和传输时机。

内容的提问来源于stack exchange，提问作者Redshoe