编辑 | 言征

出品 | 51CTO技术栈（微信号：blog51cto）

为了缓解“英伟达”焦虑，市场上浮现出了不可思议的事情。

就在今天，一个“可以让AMD GPUs上跑CUDA的编程工具包”不胫而走，引起业界的注意。

图片

1.AMD GPU 可以本地跑英伟达的CUDA？

不需要修改 CUDA 程序，也不需要构建系统，通过一个编程工具包，就可以把CUDA应用程序进行AMD GPU的本地编译。这个工具包就是Spectral Compute推出的SCALE。

关键是，SCALE的制作方还是个“AI芯片大一统的野心家”，表示：“当然，AMD 只是开始，对更多 GPU 供应商和 CUDA API 的支持正在开发中。”

据介绍，SACALE有以下几个部分组成：一个nvcc兼容编译器，能够为 AMD GPU 编译 nvcc-dialect CUDA，包括 PTX asm；针对 AMD GPU 的 CUDA 运行时和驱动程序 API 的实现；开源包装器库通过委托给相应的 ROCm 库来提供“CUDA-X”API。这就是和等库的cuBLAS处理cuSOLVER方式。

测试了哪些项目？

SCALE 团队通过编译开源 CUDA 项目并运行其测试来验证 SCALE。并且完全通过的开原项目包括：NVIDIA Thrust、Blender Cycles、AMGX、llama-cpp、stdgpu等。

图片

目前支持哪些 GPU？据介绍，AMD gfx1030（Navi 21、RDNA 2.0）、AMD gfx1100（Navi 31、RDNA 3.0）已经通过测试，AMDgfx1010、AMDgfx1101临时测试后似乎有效。

2.那么SCALE是如何做到的？

市面上有不少跨平台的GPGPU解决方案，比如受到英伟达官方支持的HIP方案，可以避免使用CUDA的模糊功能（如内联PTX）的代码，而AMD自己，本身就有一种转换工具：hipfy，可以将CUDA代码转换为hip。

那么与其他跨平台 GPGPU 解决方案相比，SCALE 有几个关键创新：

SCALE 接受原样的 CUDA 程序。无需将它们移植到其他语言。即使您的程序使用内联 PTX 也是如此asm。SCALE 编译器接受与 相同的命令行选项和 CUDA 方言nvcc，可作为替代品。“模拟” NVIDIA CUDA 工具包的安装，因此现有的构建工具和脚本就可以cmake正常工作。

当然在某些领域，SCALE对NVIDIA CUDA中某些功能的实现也有不同的行为。比如，SCALE尚不支持每个线程的默认流行为，虽然这不会破坏程序，但可能会降低性能。而在NVIDIA GPU上运行时，则有一种也会略微提高程序性能的解决方法：即显式使用非阻塞CUDA流，而不是依赖于隐式CUDA流。

整体上看，与其他方案有这些不同：

（1）SCALE并不提供编写 GPGPU 软件的新方法，而是允许使用广受欢迎的 CUDA 语言编写的程序直接为 AMD GPU 进行编译。

（2）SCALE 旨在与 NVIDIA CUDA 完全兼容。我们认为用户不必维护多个代码库或牺牲性能来支持多个 GPU 供应商。

（3）SCALE 的语言是NVIDIA CUDA 的超集，它提供了一些可选的 语言扩展 ，可以让那些希望摆脱的用户更轻松、更高效地编写 GPU 代码nvcc。

当然，SCALE 尚在开发中。可能会缺少部分 API 而导致无法使用 ，不过团队会根据用户提的需求加速开发。

教程文档很详细：https://docs.scale-lang.com/

3.神奇的极客团队

Specrtral Compute 是一个致力于加速GPGPU和HPC工作负载的全球团队，这个团队很神奇。小编翻了一下他们官网，可谓是一群AI极客的玩法。

官网显示，他们推出了一种1秒内向全球传送视频的直播解决方案，还针对高吞吐量的GPU加速应用程序后台和低延迟CPU执行进行优化，推出了最快的正则表达式引擎，而且性能不受影响；此外，这个团队队员还擅长优化你在用AI软件，使其要么跑得更快，要么服务免费。

4.万能的网友

为什么不是AMD？但代替不了英伟达

首先，一部分人争议的焦点是“怒AMD不争”——“如果AMD采取任何行动就好了，支持这个，任何一项都会话费几百万美元，但对AMD股东来说却价值一万亿美元。”

然而也有人认为AMD正在努力，正如上文提到的HIP解决方案。

然而，也有部分网友认为如果AMD支持这样的编程工具或者转换层，会是一个坏主意。

据悉，CUDA 的设计并不与供应商无关，而 Nvidia 可以在技术和法律上任意制造困难。“我认为在此上运行 cuDNN 或 cuBLAS 违反了许可协议。因此，这些和其他 Nvidia 库将成为 AMD 需要重新实现和支持的 API 边界的一部分。”

“追求 bug-for-bug 兼容性是愚蠢的行为。CUDA 的重要用户是开源。AMD 可以直接在上游项目（如 pytorch 或 llama.cpp）中实现支持。一旦获得支持，社区就可以对其进行维护。”

5.指责 AMD 而不是 Nvidia，这很奇怪吗？

事实并非如此。

一位网友已经被CUDA征服了，“即便AMD有一些努力，我也不相信 HIP 或 RocM 是 Cuda 的可行替代品。”

George Hotz 做了很多工作，试图将各种 ML 架构移植到 AMD，并遇到了无数的驱动程序错误。问题不在于英伟达不会构建开放平台——问题在于 AMD 不会投资竞争平台。

即使 CUDA 是开放的， 你是否希望 nvidia 也为 AMD 编写驱动程序？我不相信第三方会编写“兼容层”，因为 AMD 自己的 GPU 并未针对类似 CUDA 的工作负载进行优化或测试。

99%的ML工程师不会写CUDA

99% 的 ML 工程师不会编写 CUDA。一位业内人士表示，对于绝大多数工作负载，Meta 可能有 20 名工程师为 Pytorch 编写 Cuda 后端，其他每个工程师都会使用。Meta 可以再雇佣 20 名工程师来支持 AMD 拥有的一切（他们确实这样做了，但它不如 CUDA 那么强大）。

真正擅长CUDA的工程师是金子一样的贵，所以他们能做的项目远远超出了自己的精力和时间。甚至又网友爆料称：自己认识一位CUDA工程师配有一个滑雪屋，价值超过180镑黄金（约532万美元）。

也有人延伸出了对现有芯片编程的建议，希望赶紧加入互操作性，开发人员太需要互操作性技术了。互操作性技术可以帮助目前仅支持NVIDIA GPU的软件在未来快速添加对Intel和AMD GPU的支持。

写在最后：英伟达的CUDA已经成为事实上的标准

作为 NVIDIA 发明的一种并行计算平台和编程模型，CUDA已经凭借大模型时代成功完成了蝶变，目前基于 CUDA 的 GPU 销量已经达到无法完全统计，软件开发商、科学家以及研究人员正在各个领域中运用 CUDA。

Nvidia 付出了巨大的努力，也获得了丰厚的回报。他们与实际使用其产品的人密切合作，资助开发并为研究人员、教师等提供大量支持，迄今已有十年之久。

正如网友评论的：“ 即使 AMD 推出了各方面都更好的 CUDA 版本，它仍然不会被采用，因为 CUDA 已经成为标准。”

“AMD 开始真正尝试的最佳时机是 10 年前；第二佳时机是今天。”

来源： 51CTO技术栈