连编辑器都没开！AMD高管用Claude写出纯Python显卡驱动，直接绕过ROCm

还记得我们讨论过的 AI 编程能走多深吗？这不，AMD 自己现身说法了，而且切入的角度相当硬核——直接去撕裂位于底层的 GPU 用户态（User-Space）驱动。

就在这几天，AMD 人工智能软件副总裁 Anush Elangovan 在社交平台上公开了一个让人直呼头皮发麻的项目：他完全没有打开任何代码编辑器，仅仅通过与 Claude Code 的交互，就“手搓”出了一个纯 Python 版本的 AMD GPU 用户态驱动。

正如他在推文中感慨的那样：“AI 代理真的是软件开发领域最伟大的平权工具。而开发速度，就是护城河。”

绕过 ROCm 栈的直接“对话”

对于熟悉 AMD 软件生态的朋友来说，ROCm 和 HIP 栈虽然功能强大，但其庞大复杂的架构有时候也让人深感笨重，尤其对于那些只需聚焦内核调试或者特定通信逻辑的排查场景显得有些啰嗦。

其实，这个 Python 驱动项目的初衷并非要取代现有的驱动体系（毕竟性能依然是 C/C++ 的主场），它的核心目标是绕开整个繁乱的 ROCm/HIP 用户态栈，直接与系统硬件设备节点“面对面”。简单来说，就是用 Python 配合 ctypes，疯狂调用底层 ioctl，直接和系统的 /dev/kfd 还有 /dev/dri/renderD* 通信。

Anush 坦言，这套架构受到了知名精简机器学习框架 Tinygrad 的启发。通过这个独立纯粹的测试环境，工程师能快速对 SDMA（System DMA）进行压力测试，并且针对计算和通信重叠的极端调度场景进行更细粒度的 Bug 定位。

不是玩具：一整套“硬核”特性就绪

你千万不要以为这只是个几百行的“Hello World”脚本。翻看这套 Python 驱动的 Initial Commit，它已经在这个草创阶段搭建起了惊人的功能框架：

• • 深度捆绑 KFD ioctl： 完整实现了队列管理、显存映射与事件机制。
• • 全系拓扑与家族支持： 从 /sys/devices/virtual/kfd/kfd 中解析拓扑结构，直接支持 RDNA 2/3/4 以及基于 CDNA 2/3 架构的计算卡。
• • 底层调度手捏数据包： 支持 SDMA Linear Copy 以及 Fence 数据包；而且还手搓了一个 PM4 Compute Packet Builder，能够构建底层的分发和显存释放指令。
• • GPU-CPU 粗粒度同步： 通过 Timeline Semaphore 实现计算流之间的同步协同。
• • 精准的内核加载： 拥有原生的 ELF Code Object 解析器。

最关键的是，在这一波初始化提交中，在基于 MI300X/gfx942 的环境里，已经有 130 个单元与集成测试顺利亮起绿灯。

并且值得玩味的是，在这份提交记录里，Anush 将 Claude（具体版本为 claude-opus-4-6）郑重其事地列为了 Co-Author（联合开发者）。

持续进化中

这就过去了两天，这个项目并没有停下脚步。根据后续的分支代码动态，它已经扩展出了多 GPU 支持，并成功跑通了计算密集型（Compute-Bound）的 Kernel，甚至未来还预留了一个脱离 KFD，直接基于 Bare-Metal PCI 的后端架构。

这确实让人不禁遐想：当极其底层的硬件驱动开发因为 AI 代理的加入而极大降低了门槛，未来我们的硬件调试和生态适配速度，会不会迎来一波质的飞跃？

至少现在看来，Anush 这一次不仅秀了一把自家 GPU 底层的可控性，更结结实实地给我们上了一堂“如何用 AI 降维打击老代码”的实操课。