Red Hat 将用 Rust 为 Nvidia GPU 编写新的 Linux 驱动

对 Red Hat 的 Rust Nvidia 驱动的总体反应

• 许多人欢迎这一举措，认为这对 Linux 用户，尤其是较新的 Nvidia GPU 用户，是个好消息。
• 一些人认为这是 Rust 和更安全驱动程序“潮流转向”的一部分。
• 也有人对“又一次重写”持谨慎态度，担心回归问题和功能不完整。

Nouveau vs 新驱动

• 有人担心，一个范围有限的新驱动可能会加速 Nouveau 的衰退；Nouveau 支持非常老的 Nvidia 硬件。
• 一些人认为，在新驱动中支持 1990 年代/2000 年代初的 GPU 没有必要；这些设备可以继续由 Nouveau 支持。
• 法律/固件问题（签名固件、重新调频）使得通过 Nouveau 为许多老 Nvidia 显卡提供高性能支持实际上不可能。

Nvidia 固件、开源模块与架构

• 讨论提到 Nvidia 的开源 GPU 内核模块和更新的固件（GSP），它们可以重新分发并抽象更多功能。
• 若干评论认为，Red Hat 的兴趣很可能在于：
  • 获得一个位于内核树中、可维护、符合上游风格的驱动。
  • 避免与 Nvidia 的专有栈和固件版本过度耦合。
  • 可能绕开遥测和许可限制，尤其是在数据中心/LLM 场景下。
• 有人觉得既然 Nvidia 已经提供开源内核组件，再搞一个第三方驱动很奇怪；也有人说 Nvidia 的代码并不符合内核规范或部署需求。

与 NVK 和 Mesa 的关系

• 有人澄清：
  • 这个新的 Rust 驱动是一个内核/显示/内存驱动，实际上相当于 Nouveau 的替代品。
  • NVK 是 Mesa 中的 Vulkan 用户态驱动，它生成 GPU 命令，并在底层使用内核驱动。
• 要形成完整的开源 Nvidia 技术栈，这两层都需要。

Rust vs C 与内核开发

• 争论 Rust 是否真的能提升 GPU 驱动的安全性和可维护性：
  • 支持 Rust 的一方：内存安全、更好的类型系统、能捕获逻辑错误、吸引更新一代开发者，并符合内核长期需要贡献者的现实。
  • 持怀疑态度的一方：内核复杂性来自硬件/架构，而不是语言；Rust 也很复杂，no_std 还是一种专门化模式；C 仍被广泛教授和使用。
• 有人认为“把一切都重写成 Rust”被过度炒作；也有人认为 Rust 进入内核在战略上很重要。

遥测与隐私担忧

• 一些评论者怀疑，一个独立于 Nvidia 的驱动可能会：
  • 消除或减少强制遥测和许可检查，尤其是在企业和云端 GPU 使用中。
• 反方观点：有顾虑的企业本来就能缓解遥测问题，而且更可能的主因是架构/部署问题。
• 还展开了更广泛的旁支讨论：
  • 为什么开源软件用户不信任遥测（用于营销、交叉关联、去匿名化）。
  • 一些案例中，有限且透明的遥测（例如某些发行版/浏览器）被认为可以接受。

Linux 桌面与 Nvidia 用户体验

• 关于专有驱动质量的反馈不一：
  • 有人说它在 X11 和 AI 工作负载下“用起来没问题”。
  • 也有人报告 Wayland 上存在严重问题：Vulkan/OpenGL 应用损坏、多显示器问题，以及与其他 GPU（如 IPMI/Aspeed）的模式设置冲突。
• Nvidia 历史上对 Wayland 的支持薄弱（GBM vs EGLStreams）受到严厉批评；AMD 则被描述为在 Wayland 下“装上就能用”。
• 有人认为 Linux 桌面支持差，直接源于 Nvidia 的商业模式，以及其把重点放在没有显示输出的 AI/数据中心 GPU 上。

编译时间与硬件

• 关于 Rust 在内核构建中的编译时间成本，有一小段讨论：
  • 有人说现代 CPU 上的内核编译时间远远超过 Rust 带来的任何额外开销，而且大多数用户使用的是预编译内核。
  • 也有人指出，仍然有很多人会在较旧硬件上编译内核（例如工作需要、实验、Gentoo），他们会感受到影响。
• 提出的缓解办法包括：交叉编译以及持续推动 Rust 编译器提速。

更广泛的商业与生态背景

• Nvidia 在 AI/LLM 领域的主导地位被认为让 Linux 支持变得至关重要，但主要是对服务器而言，而不是桌面。
• Nvidia 被认为把其驱动栈和 SDK 视为关键竞争壁垒；对软件和许可的严格控制被描述为其模式的核心。
• 一些评论者得出的结论是：如果你非常在意 Linux 桌面和开源驱动，那么避开 Nvidia 硬件仍然是最稳妥的选择。