LWN：NVIDIA 与 nouveau！

关注了就能看到更多这么棒的文章哦～

NVIDIA and nouveau

By Jake Edge
October 5, 2022
LPC
DeepL assisted translation
https://lwn.net/Articles/910343/

英伟达图形加速硬件的源代码发不了，对人们来说这也许是一个惊喜；至少快速浏览下来，这部分代码最终可能可以合入 mainline，称为一个官方支持的驱动程序。多年来，nouveau 项目一直在为 NVIDIA 硬件开发 upstream 的驱动程序，因此引出了一个明显的问题，在 NVIDIA 的这个宣告之后，nouveau 该怎么办。内核图形维护者 Dave Airlie 在 2022 年的 Linux Plumbers 大会（LPC）上发表了演讲，来帮助阐明有关这个问题的一些情况。

NVIDIA

他首先介绍了 NVIDIA 硬件的简要历史，在他的幻灯片中可以看到一条时间线。他说，这条时间线中的一部分是 "从维基百科上拼凑得来的"，并不完全准确，但显示了 "英伟达硬件的历史有多长"。他说，虽然时间轴是从 1999 年开始，但在 2006 年 NV50 开始，变得更有趣了。它引入了每个上下文特有的虚拟内存地址；这个功能代表了图形硬件的一个重要转折点。

[Dave Airlie]

从 2010 年的 "Fermi"（GF1xx）开始，英伟达的产品发布大致是按两年的周期。2012 年的"Kepler"（GK1xx）硬件中加入了 Vulkan 支持。2014 年的"Maxwell"有两个版本（GM1xx 和 GM2xx）；后者也被称为 "Maxwell 2"，其中引入了 signed firmware。这个趋势或多或少地延续到 2016 年的 "Pascal"（GP1xx），2017 年的 "Volta"（GV1xx），2018 年的 "Turing"（TU1xx），以及 2020 年的 "Ampere"（GA1xx）。Turing 中加入了对 GPU system processor（GSP）的支持；他在演讲的稍后部分解释了该功能的重要性。

从 Maxwell 2 开始，英伟达决定，出于安全和其他方面的考虑，其设备固件不能简单地以未签名方式来加载了。因此，固件需要由英伟达进行签名，并加载到设备上的各个处理器中。这给 nouveau 项目带来了困难，因为它需要复杂的启动流程，要按特定的顺序将多个 firmware image 放入设备之内，而这是 "非常难实现的"。

英伟达和 nouveau 最终共同决定了一个流程，那就是英伟达将提供签名过的固件。但是要让所有硬件都能正常工作仍然很困难。哪怕在启动时做了所有正确的步骤，这个设备也还是仅仅提供了基本配置。这些设备已经通电并可以正常运行，但 "你不能调整它的 clock 频率，就无法让它更快运行"。手动选择英伟达设备的性能级别就被称为 "reclocking"。驱动程序中也没有电源管理功能。Airlie 说，这是 nouveau 的一个分水岭，因为对驱动程序投入大量精力之后只能让图形加速硬件运行在最慢模式下，并且对功耗方面也不友好，这没有意义。

GSP 是一个基于 RISC-V 的处理器，是在 Turing 和后来的硬件中添加进来的。GPU 上已经有 "六七个小处理器"，但 GSP 则是为了成为 "统治它们的那一个处理器"。GSP 的固件文件约为 30 或 40MB；早期的固件文件大多在 256KB 左右，也就是说 GSP 的 size 有了大幅增加。但它是设备中的唯一固件了，可以初始化其余的处理器。实际上，英伟达将其大部分专有代码的内核驱动转移到了 GSP 中。

他说，这一切都发生在英伟达内核驱动程序开源宣告的同时。这些都是基于一个只跟 GSP 直接交互的英伟达专有驱动程序 fork 出来的；事实证明，内核和 GSP 之间的 API 里没有什么重要的内容，所以可以作为开源发布。由于英伟达有一些客户希望能得到开源驱动程序，所以该公司这样做就有价值了。然而，这些驱动程序的外观和行为，跟现有的内核图形驱动程序不同，所以它们无法进入 upstream 内核，Airlie 说。

nouveau

这就是英伟达世界的现状，这一切都为介绍 nouveau 做了一个很好的引子。此项目始于 2007 年左右，目的是对 NVIDIA GPU 进行逆向工程来创建 Linux 驱动。它支持从 NV04（1999 年）到 Ampere 的硬件，这些硬件 "处于各种失去维护的状态"。

但由于各种因素，该项目最近有一些停滞。一个社区开源图形项目所面临的一个大问题是，一旦有人在这个项目上工作得很好，就会被人知道，他们就会被雇佣而去做其他的图形硬件工作。实际上，只有一个全职的 nouveau 开发人员在这个项目上工作，那就是红帽公司的 Ben Skeggs。

此外，在签名固件出现后，由于它缺乏 reclocking 和电源管理功能，这对我们的项目来说是令人沮丧的；开源驱动程序不可能跟专有驱动程序竞争。很难证明值得在 nouveau 中投入大量精力。除此之外，Skeggs 还花了很多时间试图让 NVIDIA 提供的固件可以正常加载以及在硬件上运行。

大多数情况下，nouveau 的内核驱动目前来说只能实现硬件基本能用。英伟达提供的固件与专有驱动程序所使用的固件并不一样，没有经过完整的测试。只有 NVIDIA 才能真正 debug 该固件中的问题，所以必须与 NVIDIA 工程师进行多次来回的交流。不过最近该项目一直在增加对 GSP 的支持，因为这可以给 reclocking 等功能提供了一个高级的接口，所以希望 nouveau 内核驱动程序能够使用标准的 NVIDIA GSP 固件，并以这种方式来驱动硬件；"我们等着看吧"。

OpenGL and Vulkan

Mesa 中有一个 nouveau OpenGL 驱动。他认为它已经通过了 OpenGL 4.5 的一致性测试，但从未提交认证。直到最近，它还是只有 "糟糕的多线程上下文支持"，所以它对老式的单线程游戏等情况是可用的，但对 Firefox 或现代游戏等程序则无法支持；不过，最近已经 fix 了。然而，由于缺乏对硬件的 reclocking 支持，该驱动没有进行很多优化。

最近，在 Karol Herbst 和 Airlie 的帮助下，Jason Ekstrand 为 nouveau 开发了一个 Vulkan 驱动。在演讲的时候，这还是个小新闻，但在那之后事情就有了更多进展。驱动程序的目标是针对从 Kepler 到 Ampere 的硬件的 Vulkan 1.0，目前正在通过了很多一致性测试。但是为了完成该驱动，并使其按照人们预期的方式工作，就需要在内核中添加新的用户空间 API。

他说，要让 Vulkan 真正发挥作用，需要三个功能。第一个是将物理内存分配（用在 buffer object 上）与 GPU 虚拟内存的分配都分开。在 nouveau 中，所有这些都是一步完成的，这对 OpenGL 来说是很好的，但对 Vulkan 来说是不可行的，因为它需要对 mapping 进行更多的控制。

第二，需要支持 synchronization object 已经相关的处理，以便调度器可以在发送新任务之前等待现有的 GPU 工作完成。这是对 GPU 工作进行适当的交错执行的方式，Airlie 说。最后一部分是一个叫做 VM_BIND 的虚拟内存处理接口；这是英特尔驱动中正在研究的东西，而 amdgpu 驱动已经有了它的许多部件。这是一个用于虚拟内存和命令提交（command submission）的 API，也是为了满足 Vulkan 的需求。

他说，这些都是不少工作量。在 GSP 支持就位，并且可以进行 reclocking 之后，这些工作就是 nouveau 的下一步目标了，但确实需要一些时间。Vulkan 驱动开发者已经开始关注这项工作，但有些循环依赖，使人很难看出是如何循序渐进地进行这项工作的。这将会有大量代码需要 review，所以要想采用零散合入的方式将其纳入 upstream 内核将会是一个挑战。

Future

他说，有一些即将到来的问题还没有正面去处理。比如 30 或 40MB 的固件镜像是相当大的；通常情况下，这些镜像被放到 initramfs 中。但把多个 initramfs 镜像放入启动分区就可能会超出可用空间。因为缺乏固定的固件 ABI，所以问题变得更严重，有可能需要包含多个 NVIDIA 固件镜像文件。nouveau 项目将不得不选择支持哪几个版本的固件，并且让每个版本都必须可用；他曾想过是否有办法将固件加载推迟到真正 mount 了根文件系统之后，但目前还没有真正解决这个问题。

从长远来看，将英伟达的固件 API 加入到 nouveau 驱动中可能并没有什么意义，因为 nouveau 驱动对一切工作都有自己的想法。可能需要抛开现有的 nouveau 传统做法，实现一个新的驱动程序，只使用 NVIDIA 的 API 跟 GSP 交互，这可能会是正确的途径。此外，reclocking 硬件以及加速 GPU 的能力可能可以允许创建一个跨平台的 compute stack，来取代目前已经存在的由特定供应商提供的解决方案（如 CUDA）。所有这些解决方案都在自己的孤岛之上，缺乏真正的开发者社区，但也许这可以改变；"我们已经为 Vulkan 做了，我们已经为 OpenGL 做了，我不明白我们有什么理由不继续这样做"，尽管这将需要大量的时间，以及可能需要大量资金。

一位听众问及 Vulkan Compute 是否可行，但 Airlie 说它并不是针对 CUDA 和类似软件同类的问题的。它比 OpenGL Compute 要好，但离真正的 compute stack 还有一段距离。Ekstrand 对此表示赞同，他指出，虽然人们希望看到 Vulkan Compute 处理更多的 "科学" 计算的场景，但它永远不会成为一个全栈的解决方案；他说，Vulkan 最多只能提供 run-time 部分。

大家对 Airlie 所描述的 GSP 固件和 initramfs 的大小问题进行了一些讨论，包括给出了若干个解决这个问题的方法。希望了解该讨论或讲座中其他细节的人，可以在 YouTube 上查看该讲座的视频。

[编者感谢 LWN 的用户支持我去都柏林参加 Linux Plumbers 会议]。

全文完
LWN 文章遵循 CC BY-SA 4.0 许可协议。

欢迎分享、转载及基于现有协议再创作～

长按下面二维码关注，关注 LWN 深度文章以及开源社区的各种新近言论～