ROCm项目下eGPU在WSL环境中的PCIe原子操作问题分析

问题背景

在AMD ROCm生态系统中，用户尝试通过USB4接口连接Radeon RX 7900 GRE显卡(eGPU)到搭载Ryzen AI 9 365处理器的Asus Zenbook S16笔记本上，在WSL2环境中运行HIP应用时遇到了特殊的技术问题。该问题表现为常规HIP内核无法执行，但通过HIP运行时编译(RTC)的代码却能正常工作。

现象描述

当用户在WSL2(Ubuntu 24.04)环境下运行标准HIP示例程序(如hip_saxpy)时，系统日志显示以下关键错误信息：

Pcie atomics not enabled, hostcall not supported
AQL dispatch failed!

然而有趣的是，使用HIP运行时编译的代码(如hip_runtime_compilation示例)却能够正常执行。

技术分析

PCIe原子操作的重要性

PCIe原子操作是现代GPU计算中实现高效设备间通信的关键机制。在ROCm架构中，它主要用于：

1. 确保主机与设备间的内存操作原子性
2. 支持高效的同步原语
3. 实现主机调用(hostcall)功能

问题根源

通过深入排查，发现问题源于USB4接口使用的ASMedia ASM2464PDX控制器芯片的PCIe原子操作支持不完整：

1. 终端设备(RX 7900 GRE)本身支持32位和64位原子操作
2. 但PCIe桥接芯片的原子操作路由功能被禁用：

   AtomicOpsCap: Routing-
   AtomicOpsCtl: EgressBlck-
   

为什么RTC代码能工作

HIP运行时编译的代码之所以能够运行，是因为：

1. RTC生成的代码可能使用了不同的内存访问模式
2. 避免了依赖PCIe原子操作的特定功能
3. 使用了替代的同步机制

解决方案与建议

临时解决方案

1. 在Windows原生环境下开发(需禁用iGPU)
2. 使用HIP运行时编译作为替代方案
3. 考虑使用不依赖PCIe原子操作的算法实现

长期展望

AMD ROCm团队正在开发不依赖PCIe原子操作的替代方案，这将有望在未来版本中解决此类兼容性问题。

技术启示

这一案例揭示了外置GPU解决方案中的潜在兼容性挑战，特别是：

1. 不同接口协议(如USB4/Thunderbolt)对PCIe特性的支持差异
2. 中间桥接芯片在功能支持上的限制
3. 异构计算环境中原子操作的重要性

对于开发者而言，在设计和实现跨平台GPU应用时，应当考虑这些底层硬件特性可能带来的影响，并准备相应的回退方案。

结论

虽然当前存在技术限制，但通过理解底层机制和采用适当的工作方式，开发者仍能在eGPU配置上实现大部分计算功能。随着ROCm生态的持续完善，这类边缘案例的兼容性将得到进一步改善。