CUDA for AMD on Windows
173 points
• 1 day ago
• Article
Link
本项目提供了一个可复现的框架，便于在 Windows 环境下的 AMD GPU 上运行面向 CUDA 的计算应用。通过结合 ZLUDA 与 AMD HIP/ROCm 生态，用户可以把基于 CUDA 的软件与 AMD 硬件衔接起来。该方案面向通用的 CUDA 任务设计，并已专门验证过使用 CUDA-enabled LibTorch 的工作负载，能够成功完成例如 PPO 学习与优化器操作等任务。
当前的参考配置基于官方上游组件，包括 ZLUDA v6-preview.69 与 AMD HIP SDK 6.4 。实现过程相当简单：用户安装所需的 AMD 驱动与 SDK，克隆代码仓库，然后运行随附的 PowerShell 脚本。该脚本会自动完成关键步骤，例如检测 AMD GPU 的具体架构、校验依赖、下载 LibTorch 以及配置运行时。对于希望手动操作的用户，仓库还提供了将 ZLUDA 兼容 DLL 直接放入目标应用目录的工具。
硬件兼容性是重点工作之一，AMD Radeon RX 9060 XT (gfx1200) 为当前已验证的参考设备。其他 AMD GPU 也可能兼容，仓库中包含诸如 GPU scanner 的诊断工具，帮助用户识别硬件架构并上报兼容性结果。项目鼓励用户提交不同显卡的兼容性报告，以便汇集更广泛的配置在该兼容层下的表现数据。
关于性能与局限性，测试表明标准的上游运行时表现良好，在基准的 PPO 工作负载中甚至略优于内部的实验性覆盖层。用户需注意 ZLUDA 并非完整的 CUDA 实现：主要限制包括当前稳定的 Windows HIP SDK 中缺乏对 cuDNN 的支持，以及在 NCCL 、 TensorRT 或某些自定义 CUDA 扩展等高级功能上可能存在兼容性问题。尽管如此，本项目仍为开发者在 Windows 上利用 AMD 硬件处理以 CUDA 为中心的计算任务，提供了一条稳健的开源路径。
This project provides a reproducible framework for running CUDA-targeted compute applications on AMD GPUs within a Windows environment. By leveraging a combination of ZLUDA and the AMD HIP/ROCm ecosystem, users can bridge the gap between CUDA-based software and AMD hardware. While the setup is designed for general CUDA-facing tasks, it has been specifically validated for workloads using CUDA-enabled LibTorch, successfully completing tasks such as PPO learning and optimizer operations.
The current validated reference configuration relies on official upstream components, including ZLUDA v6-preview.69 and the AMD HIP SDK 6.4. The process for implementation is straightforward: users install the necessary AMD drivers and SDK, clone the repository, and execute an included PowerShell script. This script automates essential steps, such as detecting the specific AMD GPU architecture, verifying dependencies, downloading LibTorch, and configuring the runtime. For users who prefer manual control, the repository also provides tools for staging the ZLUDA compatibility DLLs directly into a target application's directory.
Hardware compatibility is a significant focus, with the AMD Radeon RX 9060 XT (gfx1200) serving as the currently validated reference device. Other AMD GPUs are considered potential candidates, and the repository includes diagnostic tools, such as a GPU scanner, to help users identify their hardware architecture and report compatibility results. By encouraging users to submit compatibility reports for various cards, the project aims to gather broader data on how different configurations perform under this compatibility layer.
Regarding performance and limitations, testing indicates that the standard upstream runtime is effective, even slightly outperforming internal experimental overlays in benchmarked PPO workloads. Users should be aware that ZLUDA is not a comprehensive CUDA implementation. Key limitations include the current lack of cuDNN support within the stable Windows HIP SDK, and potential compatibility issues with advanced features like NCCL, TensorRT, or certain custom CUDA extensions. Despite these constraints, the project offers a robust, open-source path for developers to utilize AMD hardware for CUDA-centric compute tasks on Windows.
102 comments • Comments Link
• 对 HIP 、 SYCL 和 OpenCL 等开放标准的热情，来自于希望摆脱 NVIDIA 封闭硬件、驱动和 SDK 带来的限制与专有性的愿望。
• LLM 辅助开发正成为创建自定义 kernel 的可行方式。通过使用顶级模型和自动化基准测试，开发者能够生成高性能、针对特定硬件的代码，有时甚至能超越厂商提供的实现。
• 可用性仍然是开放标准面临的最大障碍。尽管有 OpenCL 等标准，但糟糕的开发者体验和缺乏行业范围内的采纳，使其难以与成熟、打磨精良的 NVIDIA 生态堆栈竞争。
• NVIDIA 的"护城河"不仅是 CUDA 这门编程语言，而是一个完整的生态系统，涵盖高层库、复杂的性能分析工具、调试支持及长期的硬件层面协作。
• 试图把 CUDA 代码转为 Vulkan 或 ROCm 等后端，常常会导致性能碎片化。由于硬件架构差异巨大，通用的可移植代码很难达到针对特定 GPU 微架构手工调优的 kernel 那样的效率。
• 像 ZLUDA 或自定义转译桥这样的尝试旨在提供兼容性，但通常缺乏生产环境所需的商业信任和稳定性。
• 行业内缺乏统一的"hardware consortium"来定义通用的 GPGPU 基准。硬件厂商各自优先支持不同特性，导致难以就类似 NVIDIA "Compute Capability" 的版本控制达成一致。
• 缺乏厂商合作进一步加剧了碎片化。 NVIDIA 有动力维持其封闭生态，而其他厂商历史上也未能持续投入必要的软件堆栈以展开有力竞争。
• 实践性的 GPU 计算专业知识难以复制。成功的实现需要对硬件内存布局、同步机制和内核调试有深刻理解，这些知识很少能被基础的转译工具捕捉到。
• 市场仍受既有堆栈惯性支配，形成了"没人会因为购买 IBM 而被解雇"的效应，使开发者因其可靠性和广泛支持继续偏向 NVIDIA 。
这场讨论反映出对 NVIDIA 在 GPU 计算市场中主导地位的深刻沮丧，凸显了开放标准的理论优越性与专有生态在商业现实中的张力。尽管许多参与者强烈希望看到 SYCL 或 OpenCL 等替代方案，但他们也承认这种"护城河"是建立在多年可靠的工具链、高层库和大量硬件专用优化之上的，而其他厂商难以匹敌。尽管 AI 辅助代码生成的进步正使跨平台 kernel 开发变得更容易，但共识仍然是：除非竞争厂商能提供统一、高性能且有专业支持的堆栈，否则 NVIDIA 的地位不太可能受到根本挑战。 • The preference for open standards like HIP, SYCL, and OpenCL is driven by a desire to escape the restrictive, proprietary nature of NVIDIA's closed hardware, drivers, and SDKs.
• LLM-assisted development is emerging as a viable way to create custom kernels. By using top-tier models and automated benchmarking, developers can generate performant, hardware-specific code that occasionally outperforms vendor-provided implementations.
• Usability remains the greatest barrier to open standards. While standards like OpenCL exist, their poor developer experience and lack of industry-wide adoption have limited their impact compared to the cohesive, polished NVIDIA stack.
• NVIDIA's "moat" is not merely the CUDA programming language but a comprehensive ecosystem that includes high-level libraries, sophisticated profiling tools, debugging support, and long-term hardware-level cooperation.
• Attempts to translate CUDA code to other backends like Vulkan or ROCm often suffer from performance fragmentation. Because hardware architectures vary significantly, generic portable code rarely achieves the efficiency of kernels hand-tuned for specific GPU microarchitectures.
• Efforts like ZLUDA or custom transpilation bridges seek to provide compatibility, though they often lack the commercial trust and stability required for production environments.
• The industry lacks a unified "hardware consortium" to define a common GPGPU baseline. Hardware vendors prioritize distinct features, making it difficult to agree on an equivalent to NVIDIA's "Compute Capability" versioning.
• Fragmentation is exacerbated by a lack of vendor cooperation; NVIDIA is incentivized to maintain its closed ecosystem, while other vendors have historically failed to invest consistently in the necessary software stack to compete.
• Practical GPU compute expertise is difficult to replicate. Successful implementations require deep knowledge of hardware memory layouts, synchronization, and kernel debugging, which are rarely captured by basic transpilation tools.
• The market remains dominated by the inertia of established stacks, leading to a "nobody gets fired for buying IBM" effect where developers continue to favor NVIDIA for its reliability and breadth of support.
The discussion reflects a deep-seated frustration with NVIDIA's dominance in the GPU compute market, highlighting the tension between the theoretical superiority of open standards and the practical, commercial reality of proprietary ecosystems. While many participants express a strong desire for alternatives like SYCL or OpenCL, they acknowledge that the "moat" is built on years of reliable tooling, high-level libraries, and extensive hardware-specific optimization that other vendors have struggled to match. While advancements in AI-assisted code generation are beginning to make cross-platform kernel development more accessible, the consensus remains that until competing hardware vendors offer a unified, high-performance, and professionally supported stack, NVIDIA's position is unlikely to be seriously challenged.