英伟达分享对RISC-V的看法，事关CUDA

公众号记得加星标⭐️，第一时间看推送不会错过。

CUDA 是 GPU 计算领域的巨头，尤其适用于机器学习应用。目前，CUDA 支持 x86-64 和 aarch64 CPU。现在，Nvidia 正在考虑将 CUDA 支持扩展到 RISC-V 架构。此举将使 RISC-V CPU 能够为 GPU 提供计算资源。Nvidia 的演讲重点阐述了 RISC-V CPU 必须满足哪些要求才能与 CUDA 协同工作。简而言之，他们需要的是服务器级别的 CPU 和平台。

Nvidia 首先要求采用 RVA23 CPU，并符合 RISC-V服务器 SoC和服务器平台规范。这些规范包括 RAS（可靠性、可用性和可维护性）特性、专用安全处理器以及其他基本特性。Nvidia 的大部分服务器级需求都可以通过这些规范得到满足。

除了上述 RISC-V 规范或平台规格之外，Nvidia 还有一些额外的要求，因为他们发现如果没有这些特性，CUDA 软件很难高效运行。他们不希望出现“最低公分母”问题，即由于无法保证硬件支持某些性能增强扩展，而无法使用这些扩展。在 Nvidia 看来，这将迫使他们发布低效的代码。Nvidia 以向量扩展为例，指出其谓词支持可以避免使用分支代码。

ACPI 的要求更为严格。ACPI 允许软件发现硬件的功能，并可用于电源、性能和散热管理。Nvidia 的软件团队在开始移植 CUDA 时，由于 RISC-V 硬件不支持 ACPI 而感到不满，但这个问题已经得到解决。UEFI 论坛于 2025 年添加了对 RISC-V ACPI 的支持。RISC-V BRS（启动和运行时服务）规范已于去年获得批准，其中就包含了 ACPI。

然后，Nvidia 要求 PCIe 数据一致性。Nvidia 提出了一个内存顺序问题：CPU 已写入数据，但这些数据仍存储在缓存中。如果 CUDA 发起 DMA 请求将这些数据复制到 GPU，DMA 引擎可能会从 DRAM 读取数据，从而错过存储在 CPU 端缓存中的已修改数据。当从 GPU 复制结果时，在 DMA 引擎将数据写入 DRAM 之后，CPU 可能会从其缓存中读取到过时的数据。如果系统不具备 PCIe 数据一致性，软件必须显式地使缓存失效才能避免这种情况。将缓存失效机制集成到 CUDA 协议栈中非常困难，而且 Nvidia 认为 PCIe 数据一致性是服务器 CPU 的标准特性。RISC-V 服务器 SoC 规范建议硬件实现缓存一致性，但 Nvidia 要求得到保证。

英伟达还希望硬件能够支持点对点 PCIe 通信。如果没有这项功能，两个设备之间复制的缓冲区数据就必须经过 CPU 内存，这会降低性能并增加复杂性，因为它需要额外的同步信号。

遗憾的是，英伟达并没有详细说明所有要求。他们提到，他们的目标性能水平是某个特定值，并且所有要求加起来不超过两页。至于这两页指的是两页双倍行距、大字体的纸，还是指允许学生在开卷考试中携带的两页笔记（学生会尽可能多地记录信息），目前还不得而知。

NVLink Fusion 要求

除了在 RISC-V CPU 上运行 CUDA 之外，Nvidia 还简要介绍了 NVLink Fusion 的要求。NVLink Fusion 允许其他公司在其芯片上实现 Nvidia 的 NVLink IP，从而使他们能够将 Nvidia 的 NVLink C2C 链路与他们选择的定制 CPU 连接起来。一个假想的产品将类似于 Nvidia 的 GB10，后者使用 NVLink C2C 将联发科的 CPU 芯片与 Nvidia 的 GPU 连接起来。Nvidia 当然也希望客户使用 Nvidia 的 CPU。但如果客户想要连接定制 CPU 或其他加速器，Nvidia 仍然希望他们使用 NVLink IP。定制 CPU 可以是 RISC-V CPU。

NVLink Fusion 的要求包括 CUDA 的所有要求，以及支持 DOCA 和 NCCL 等软件框架所需的一切。此外，它还要求与英伟达建立紧密的合作伙伴关系，这似乎是理所当然的。集成 IP 可能是一项复杂的工作，很可能需要像联发科与英伟达在 GB10 上的合作那样密切合作。

RISC-V 的软件生态系统在赶上 x86-64 和 aarch64 之前还有很长的路要走。Nvidia 致力于将 CUDA 引入 RISC-V 世界，这是一个很有前景的进展。然而，这些努力并不意味着你可以直接将 Nvidia GPU 连接到 RISC-V 系统并立即使用 CUDA。绝大多数现有的 RISC-V 硬件都无法满足 Nvidia 的要求。事实上，我甚至怀疑在不久的将来，市面上是否有任何 RISC-V 消费级硬件能够满足这些要求。ACPI 显然是一个难点，而且似乎很难被厂商接受。在 aarch64 世界，尽管 ACPI 已经纳入标准多年，但其支持情况充其量也只是零星的。一个在 2025 年获得批准的 RISC-V 标准，可能需要数年甚至更长时间才能获得广泛的支持。

如果RISC-V系统开始支持CUDA，它们很可能是服务器系统，而不是发烧友能够负担得起的单板计算机。Nvidia表示他们正在与SiFive合作，SiFive计划在Hot Chips大会上演示一个运行CUDA的系统。Nvidia暗示他们幻灯片上的示例CPU规格与该系统相符，而这些规格表明它是一款高核心数的服务器芯片。我很期待看到这个演示，但我也希望Nvidia不要阻止CUDA在不支持的系统上运行。我非常希望看到发烧友们尝试用RISC-V系统为Nvidia GPU供电。

展望未来，我希望英伟达能够放宽要求，让现有的 RISC-V 系统更容易满足要求。缺少矢量扩展或 PCIe 一致性并不一定会导致无法解决的性能问题。如果分支是可预测的（而通常情况下确实如此），那么使用分支而不是预测是可行的。为了解决 PCIe 一致性不足的问题而进行的缓存失效会带来一定的性能损失。然而，对于计算量远大于数据传输量的工作负载而言，这种性能损失或许是可以接受的。PCIe 点对点传输也是如此。速度固然重要，但对于不常发生的情况，如果谨慎处理，也可以采取较为缓慢的方式。希望英伟达目前的要求是出于权宜之计，旨在实现快速、低风险的 RISC-V 移植。也希望 CUDA 的发展方向能够使其适用于各种 RISC-V 系统，而不仅仅是特定的企业级设计。

（来源：编译自chipsandcheese ）

*免责声明：本文由作者原创。文章内容系作者个人观点，半导体行业观察转载仅为了传达一种不同的观点，不代表半导体行业观察对该观点赞同或支持，如果有任何异议，欢迎联系半导体行业观察。

今天是《半导体行业观察》为您分享的第4509内容，欢迎关注。

加星标⭐️第一时间看推送

求推荐