2

我有一个带有 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() 会为“跨卡”通信提供错误。请注意，所有主机到设备的路径始终可用（当然）。

4

1 回答 1

4

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

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

因此，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() 会为“跨卡”通信提供错误。

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

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

于 2013-10-25T14:01:28.053 回答