使用 Nvidia GTX 590 的多 GPU GPUDirect 点对点通信问题

Question

我有一个带有 2 个 GTX 590 卡（4 个 GPU）的 linux 机器。使用 CUDA 4.0 驱动程序，我能够调用 GPUDirect 内存访问并验证我的 4 个 GPU 的所有可能对之间的成功复制。

但是，在我升级到 CUDA 4.1 驱动程序（或任何后续驱动程序）后，我的 GPUDirect 访问对受到限制。

例如，在 CUDA 4.0 下，以下之间启用了点对点：

GPU0 GPU1

GPU0 GPU2

GPU0 GPU3

GPU1 GPU2

GPU1 GPU3

GPU2 GPU3

但在 CUDA 4.1（或更高版本）下，我仅限于以下之间的访问：

GPU0 GPU1（同一张卡）

GPU2 GPU3（同一张卡）

GPU1 GPU3

在使用最新的 CUDA 5.x 驱动程序时，任何人都可以解释这一点或知道解决方法吗？

---

$ lspci -tv（有趣的部分）给出：

-[0000:00]-+-00.0  ATI Technologies Inc RD890 Northbridge only single slot PCI-e GFX Hydra part
       +-02.0-[0c-0f]----00.0-[0d-0f]--+-00.0-[0f]--+-00.0  nVidia Corporation Device 1088
       |                               |            \-00.1  nVidia Corporation GF110 High Definition Audio Controller
       |                               \-02.0-[0e]--+-00.0  nVidia Corporation Device 1088
       |                                            \-00.1  nVidia Corporation GF110 High Definition Audio Controller
       :
       +-0b.0-[04-07]----00.0-[05-07]--+-00.0-[07]--+-00.0  nVidia Corporation Device 1088
       |                               |            \-00.1  nVidia Corporation GF110 High Definition Audio Controller
       |                               \-02.0-[06]--+-00.0  nVidia Corporation Device 1088
       |                                            \-00.1  nVidia Corporation GF110 High Definition Audio Controller

在我看来，所有路径在物理上都是可用的（树状结构），它们在使用 cuda 4.0 时是可用的，但在使用 cuda 4.1 及更高版本时，cudaDeviceCanAccessPeer() 会为“跨卡”通信提供 false。请注意，所有主机到设备的路径始终可用（当然）。

Answer 1

启用 CUDA 点对点访问由 GPU 驱动程序管理，该驱动程序检查系统配置以确定点对点访问是否可能工作。

例如，当 2 个设备之间的直接通信必须通过 QPI 链路传输时，不启用对等访问，如 here 所述。

因此，GPU 驱动程序会检查系统配置，并根据系统拓扑是否可识别以及识别的拓扑是否符合某些启发式方法来确定是否启用对等访问，以确定是否支持对等访问会成功的。

在您的情况下，如果您可以在同一张卡上的设备之间进行通信，那仅仅意味着 GPU 驱动程序拓扑识别启发式表明，当唯一的干预设备是卡上的 PCIE 开关时，Peer to Peer 将成功并且所以它被启用（cudaDeviceCanAccessPeer 将返回 true）。

在您的情况下，我想说，如果您可以在同一张卡上的设备之间成功启用对等访问，但在任何其他情况下都没有，那么您的系统拓扑可能会陷入某种“无法识别”的情况或可能被列入黑名单设想。换句话说，这可能是预期的行为。

如果您可以在同一张卡上的设备之间启用对等访问，也可以在不同卡上的某些设备对之间启用对等访问，但在不同卡上的其他设备对之间无法启用，这可能是机器配置问题或错误。

驱动程序维护的管理启发式方法以及白名单和黑名单可能会因驱动程序版本而异，这就解释了为什么当您从旧版本迁移到新版本时会看到行为差异。 （是的，随着您迁移到新版本，启发式方法会变得更加严格。）

例如，当启发式最初在 CUDA 4.0 附带的 270.41.19 驱动程序中定义时，RD890 芯片组可能被认为对 PCIE P2P “安全”。后来，根据测试或客户报告，可能已经发现一些带有RD890的主板在P2P方面存在某种问题。随后，P2P 可能因此在基于 RD890 的系统的驱动程序中被“关闭”。我不知道这是否适用于 RD890，我只是举例说明可能发生的情况，以说明启发式算法会随着时间的推移变得更加严格的原因。

我提供上述内容并不是对您的情况的完整解释，因为如果您可以在不同卡上的某些 GPU 之间启用 P2P，但不能在 不同卡上的其他 GPU 之间启用 P2P ，那么这对我来说听起来像是出乎意料的行为。我的描述的其余部分只是背景信息。

您的描述对我来说并不完全清楚，因为您首先表明：

GPU0 GPU1（同一张卡）

GPU2 GPU3（同一张卡）

GPU1 GPU3

是成功的路径。假设GPU1 <-> GPU3 代表“跨卡”通信，这对我来说似乎是出乎意料的行为。

后来，你指出：

但在使用 cuda 4.1 及更高版本时，cudaDeviceCanAccessPeer() 会为“跨卡”通信提供 false。

如果这是真的，它可能只是基于驱动程序中启用启发式修改的预期行为。

请注意，一般来说，P2P 支持可能因 GPU 或 GPU 系列而异。在一种 GPU 类型或 GPU 系列上运行 P2P 的能力并不一定表明它可以在另一种 GPU 类型或系列上运行，即使在相同的系统/设置中也是如此。 GPU P2P 支持的最终决定因素是通过cudaDeviceCanAccessPeer 查询运行时提供的工具。 P2P 支持也会因系统和其他因素而异。此处的任何陈述均不保证任何特定设置中的任何特定 GPU 都支持 P2P。