Linux 7.3 提高了 vRAM 不足时的性能

今年早些时候，我在博客中介绍了我为改进游戏 VRAM 管理所做的工作。现在，经过几个月在邮件列表中徘徊后，内核补丁终于被合并到上游并排队等候 Linux 7.3！万岁！为了庆祝，让我们更深入地看一下我在上一篇文章中写的一句话：[游戏] 应该表现得更加稳定 - 只要游戏本身不使用比您实际拥有的更多的 VRAM。因此，有人可能会问：如果他们实际上使用的 VRAM 比您实际拥有的 VRAM 多怎么办？人们对此的典型预期似乎是，一旦发生这种情况，你就完蛋了。游戏将开始左右崩溃，性能下降到无法玩的水平，良好的游戏体验变得不可能。但这真的只是生活中不可避免的事实吗？到底是什么让 VRAM 耗尽如此困难？而且，最重要的是：我们怎样才能让它尽可能不那么糟糕？设定期望 理论上，VRAM 耗尽应该完全是性能问题，而不是稳定性问题。自 GPU 驱动程序出现以来，对过度使用 VRAM 的支持就已经存在：如果驱动程序过度使用 VRAM，通常允许您请求任意数量的 VRAM，并且您将获得内核驱动程序决定它可以放入 GPU 上存在的物理内存的数量。在性能方面，当 VRAM 耗尽时性能不佳的总体原因相当简单。一旦游戏请求的 VRAM 超过实际存在的数量，部分游戏内存就必须移动/驱逐到 CPU RAM。对于 GPU 来说，访问 CPU RAM 比 VRAM 慢得多：CPU RAM 通常不仅比专用 GPU 的 VRAM 慢，而且所有内存访问都必须通过 PCI 总线。 PCI 总线会增加延迟，并且通常也是从 CPU 内存获取时带宽的限制因素。由于 PCI 速度限制，过度使用 VRAM 时确实存在一些不可避免的性能限制。假设 GPU 通过 PCIe 4.0x16 连接连接，您将获得略低于 32GiB/s 的带宽。 PCIe 总线每毫秒可传输约 32.2MiB 的数据。对于每秒 30 帧（每帧 33.3 毫秒）的最小帧速率，GPU 能够访问的绝对最大数据量约为 1,075.5MiB，略高于 1GiB 的数据量。换句话说，如果大量内存被逐出，GPU 需要在一帧中从被逐出的内存中获取超过 1GiB 的数据，那么根本不可能达到 30 FPS。并非所有内存都是平等的 同时，仅仅在 GPU 上读取一点点 CPU 内存并不会立即宣判性能的死刑。事实上，GPU 驱动程序有时会决定让命令缓冲区数据和相关分配等内容驻留在 CPU RAM 中，即使有大量可用的 VRAM！每当 GPU 执行这些命令时，它都必须访问 CPU 内存，但在这些情况下，一切都运行得很好。那么是什么让这些访问变得不同——为什么它们都很好，但 VRAM 耗尽却看起来是灾难性的？显着影响微积分的一件事是缓存。由于无论缓存内存位于 CPU 还是 GPU 上，缓存命中时的访问延迟都是相同的，因此通过 PCI 总线获取的较高初始成本可以通过缓存命中来分摊（在某种程度上）。我们可以通过编写测量不同缓冲区大小的访问延迟的微基准来估计获取 CPU RAM 和 VRAM 之间的延迟差异（使用对抗性访问模式来尽可能减少缓存命中率）。您得到的结果可能如下所示（在 RDNA3 上捕获）： 正如预期的那样，如果缓冲区适合 L2（或任何更高级别的缓存），则 CPU RAM 支持的内存和 VRAM 支持的内存的访问延迟完全相同，因为在这两种情况下数据都是直接从缓存获取的。当大小为 6MB（RDNA3 上的二级缓存大小）时，每次访问 CPU 内存延迟高达约 2400 个周期，而设备内存延迟保持在相同的大致范围内。请注意，VRAM 访问也经过无限高速缓存，但 CPU 内存访问则不然（它们在 L2 未命中时直接命中 PCIe）。我怀疑这是因为无限缓存直接位于 VRAM 之上，因此任何不访问 VRAM 的访问也不会到达无限缓存。显然，内存并不是一开始就缓存在任何地方的，因此第一次访问仍然会有相当高的延迟。此外，失去 Infinity Cache 肯定也会造成伤害：PCIe 读取的延迟似乎是 Infinity Cache 命中的大约 7.3 倍，是从 VRAM 读取的大约 4.6 倍。这种增加的延迟需要非常高的缓存命中率才能完全分摊 PCIe 的成本。这意味着只有一小部分使用情况下，使用 CPU 内存的速度减慢如此之小，以至于当您有选择时，您会主动决定使用它而不是 VRAM。当您从 VRAM 中逐出内存时，几乎不可避免地会出现至少一些