开源CUDA项目起死回生，支持非英伟达芯片，濒临倒闭时神秘机构出手援助

Back to Wonderfulf骚靈男孩

内购合集【野兽派、Theory、AIGLE、OVV、之禾、舒客、本周、丽婴房】

夏训闭眼囤！4件中高强运动内衣

#不用N卡跑CUDA##开源CUDA项目ZLUDA起死回生# 能让非NVIDIA芯片跑CUDA的开源项目ZLUDA，起死回生了。 最新版增加了对大模型工作负载的支持，一举登上GitHub热榜！【图1】 该项目一度因AMD停止资助濒临破产，最终被一家神秘机构出手相救。 现在，创始人vosen带来好消息，表示ZLUDA团队新添一员猛将并稳定进行项目恢复中。 开发者@vosen本名Andrzej Janik，曾经在Intel工作。 在2020年，Andrzej Janik想要尝试一下技术突破，让CUDA程序在非NVIDIA平台运行，一尝试，便有了可行性。 之后，ZLUDA被Intel接手，作为一个内部试验项目发展。 Intel分配资源给了ZLUDA，目的很明显了，让其在Intel GPU上跑CUDA程序，作为Intel oneAPI生态的一种补充方式。 无疑，这触碰到了NVIDIA的商业生态链。 没过多久，这个项目就被终止了。 2022年，ZLUDA得到了AMD的支持而重启，并支持AMD硬件。 好景不长，这次也仅仅维持2年，2024年2月宣布终止。 一个月后，英伟达就发布CUDA 11.6版本，并明确规定，不允许在非NVIDIA平台上逆向工程、反编译或反汇编CUDA SDK生成的任何结果。 这之后，ZLUDA就陷入“停摆”状态。 直到24年10月份，Andrzej Janik在社区发布消息，说已经获得“神秘机构”的支持，项目能够继续进行。 Andrzej Janik顺便介绍了项目恢复重点和进展：专注机器学习，ZLUDA目标是llm.c、llama.cpp、PyTorch、TensorFlow等；新的ZLUDA将支持多种GPU架构，主线开发基于AMD GPU；降级Windows支持以及代码改进等。【图2】 除此之外，Andrzej Janik信誓旦旦，说最终目标是在一年内（2025年第三季度）将“新” ZLUDA的状态恢复到以前。 现在，2025年第三季度已经开始，一起看看ZLUDA具体进展： ZLUDA第二位全职开发人员Violet加入不到一个月，已经做出了重要改进，特别是通过llm.c项目推进了对大型语言模型 (LLM) 工作负载的支持。 两位“极客”正努力恢复ZLUDA的状态。 - 支持32位PhysX 一位名为@Groowy 的社区贡献者通过收集详细的CUDA日志，开始了在ZLUDA中启用32位PhysX支持的初步工作，并很快发现一些错误。 由于其中一些问题也可能影响64位CUDA功能，因此已将修复这些问题添加到官方路线图中。然而，完成完整的32位PhysX支持仍需开源贡献者的进一步帮助。 - 与LLM.c兼容 ZLUDA的开发人员正在开发一个名为llm.c的测试项目，这是一个小型示例程序，尝试使用CUDA运行GPT-2模型。 虽然这次测试规模不大，但意义重大。 这是ZLUDA首次尝试同时处理常规CUDA函数和cuBLAS（快速数学运算）等特殊库。 如果成功，将有助于ZLUDA未来支持像PyTorch这样的大型软件。 该测试程序对CUDA函数进行了8,186次独立调用，分布在44个不同的API上。 最初，ZLUDA会在第一次调用时立即崩溃。 现在，团队已经完成了对44个所需函数中16个函数的支持，距离成功运行整个测试不远了。 - 提高ZLUDA的准确性 ZLUDA的核心目标是在非NVIDIA GPU上运行标准CUDA程序，同时尽可能精确地匹配NVIDIA硬件。 ZLUDA的早期版本经常会跳过一些指令修饰符影响了准确性和精度。 这个问题目前有了实质性进展。 为了确保准确性，它运行PTX“扫描”测试——使用NVIDIA的中间GPU语言进行系统性检查——以确认每条指令和修饰符组合在所有输入上都能产生正确的结果。 之前从未这么做过。现在做了，很多缺陷解决了。 不过还存在问题，并非百分百精确。再但是，cvt指令，现在确定是精确的。 - Improving logging改进日志记录 要让任何基于CUDA的软件在ZLUDA上运行——无论是游戏、3D应用程序还是机器学习框架——其基础是记录程序与CUDA的通信方式。 这包括跟踪直接API调用、CUDA运行时（或驱动程序）的未公开部分以及任何对专用性能库的使用。 在最近的更新中，ZLUDA的日志系统得到了显著升级。 目前实现了以前不可见的、更广阔的活动范围以及内部行为的详细跟踪，例如cuBLAS如何依赖cuBLASLt，或cuDNN如何与底层驱动程序API交互。 - 运行时编译器兼容性 现代GPU框架如CUDA、ROCm/HIP、ZLUDA和OpenCL都需要在应用程序运行时动态编译设备代码，以确保较旧的GPU程序可以在更新的硬件上正确构建和执行，而无需修改原始代码。 在AMD的ROCm/HIP生态系统中，这种动态编译依赖于comgr库（全称ROCm-CompilerSupport），这是一个功能强大的紧凑型库，能够处理编译、链接和反汇编代码等任务，并且支持Linux和Windows平台。 在ROCm/HIP版本6.4中，一个重要的应用程序二进制接口（ABI）发生变更：代表操作的数值代码在新v3 ABI中重新排列。 这导致ZLUDA意外地调用了错误的操作——例如，尝试链接而不是编译，从而引发了错误。 这个库在Windows上情况更糟，声称是2.9版本，但内部使用了v3 ABI，导致行为混合。 好消息是，ZLUDA团队解决了这些问题。