NVIDIA 开始提供 GPL 许可内核模块的最大原因是其驱动程序架构已演进到这样的程度：Linux 集成、分发和维护可以大大简化，同时将 GPU 的关键知识产权保留在固件和用户空间组件中。

确切地说，NVIDIA 并没有将整个驱动程序栈开源。开源的主要是以下 Linux 内核模块：

  • nvidia.ko
  • nvidia-drm.ko
  • nvidia-uvm.ko
  • nvidia-modeset.ko

用户空间组件（如 CUDA、OpenGL、Vulkan）和 GSP 固件仍为专有。（NVIDIA Developer）

1. 为了让 Linux 发行版更容易集成

以前，NVIDIA 的专有内核模块必须与 Linux 内核分开构建、签名和分发。基于 DKMS 的工作流（每次内核更新后重新构建模块）通常会导致以下问题：

  • 内核更新后模块构建失败
  • 未签名的模块被 Secure Boot 阻止
  • Linux 发行版难以将驱动程序维护为官方包
  • 与自定义内核或云环境集成时复杂度增加

通过发布源代码，Ubuntu、Red Hat 和 SUSE 等发行版可以更轻松地将 NVIDIA 的内核模块集成到自己的打包、签名和更新基础设施中。NVIDIA 自己也将更紧密的操作系统集成以及更简单的签名和分发列为关键动机。（NVIDIA Developer）

2. 为了改进调试和安全审查

内核模块与操作系统的深层部分交互，包括内存管理、中断、进程间同步、PCI Express 和显示子系统。

源代码公开后，Linux 发行版开发人员和企业用户可以：

  • 追踪内核中执行停止的位置
  • 分析 GPU 事件与工作负载之间的交互
  • 修复与自定义内核的不兼容性
  • 审查安全相关问题
  • 向 NVIDIA 提交补丁

NVIDIA 表示，社区和合作伙伴的审查可以提高驱动程序质量和安全性。（NVIDIA Developer）

3. 因为功能已移入 GSP

关键的技术转折点是 GSP（GPU System Processor）。

以前，GPU 控制逻辑的很大一部分在主机 CPU 的内核驱动程序中运行。但在较新的 GPU 上，内部 GSP 固件执行硬件初始化和管理等关键任务。

从概念上看，架构变化如下：

Previous:

Linux kernel module
        ↓ Direct low-level hardware control
GPU

Current:

Linux kernel module
        ↓ Commands / RPC
GSP firmware
        ↓
GPU hardware

Enter fullscreen mode Exit fullscreen mode

这使得硬件特定的复杂性和敏感实现细节可以保留在已签名的固件中，同时仅公开面向 Linux 的内核接口。NVIDIA 明确指出，GSP 驱动程序架构的逐步采用是最初开源内核模块得以实现的技术基础。（NVIDIA Developer）

换句话说，NVIDIA 不仅仅是改变了公司政策——它提前重新设计了驱动程序架构，以便面向内核的部分可以作为开源发布。

4. 为了简化 AI、云和数据中心部署

如今，NVIDIA GPU 不仅用于桌面系统，还用于：

  • Kubernetes 集群
  • AI 训练服务器
  • 云虚拟机
  • Grace Hopper 系统
  • Confidential Computing 环境
  • 统一内存架构

在这些环境中，必须将 GPU 驱动程序自动且安全地集成到操作系统镜像和容器平台中。

开源内核模块还引入了对 HMM、Confidential Computing 以及 Grace 平台上相干内存等技术的支持。在包括 Grace Hopper 和 Blackwell 在内的一些较新平台上，开源内核模块是强制性的。（NVIDIA Developer）

这为 NVIDIA 带来了明显的商业优势，降低了在 Linux 上部署 AI 和云基础设施的运营成本。

5. 更好地与包括 Nouveau 在内的 Linux 生态系统协作

源代码的发布加上 GSP 固件的引入，也使得改进 Linux 生态系统中的开源 NVIDIA 驱动程序 Nouveau 变得更容易，特别是在电源管理和时钟管理等功能方面。

NVIDIA 表示，Nouveau 开发人员可以使用已发布的代码作为参考，也可以利用相同的 GSP 固件。（NVIDIA Developer）

但是，NVIDIA 的开源内核模块尚未完全合并到上游 Linux 内核中。NVIDIA 表示，其驱动程序代码库跨多个操作系统共享，目前不符合 Linux 内核上游编码约定，因此无法直接包含。（NVIDIA Developer）

为什么采用“MIT/GPL”双重许可？

MIT/GPL 表示该代码采用双重许可，允许在 GPLv2 或 MIT 许可下使用。（NVIDIA Docs）

总体而言，目的是：

  • GPLv2：确保与 Linux 内核许可模型的兼容性。
  • MIT：允许更宽松的重用、移植和再分发。

由于 NVIDIA 在 Linux、其他操作系统、多个 GPU 系列和 Jetson 平台之间共享部分代码库，因此除了 GPL 之外提供 MIT 选项是一种实际选择。但是，NVIDIA 并未正式表示这是唯一动机；这一结论是从已发布的代码结构和许可模型推断得出的。（NVIDIA Developer）

总结

与其说是突然采用全公司范围的开源政策，不如说 NVIDIA 的实际做法可以更好地概括为：

通过将硬件控制移入 GSP 固件并开源 Linux 内核接口，NVIDIA 在保持核心 GPU 知识产权专有的同时，简化了分发、签名、维护和云部署。

关于之前的问题，NVIDIA 当前的官方政策是：对于支持的 Turing 及更新一代 GPU，开源 GPU 内核模块是默认且推荐的选项。这一变化从 R560 驱动程序系列开始成为默认选项。Maxwell、Pascal 和 Volta GPU 仍需要专有驱动程序。（NVIDIA Developer）