CUDA驱动程序API与CUDA运行时

CUDA运行时使编译CUDA内核并将其链接到可执行文件成为可能。这意味着您不必在应用程序中分发Cubin文件,也不必通过驱动程序API加载它们。正如您所指出的,它通常更容易使用。

相比之下,驱动程序API更难编程,但对如何使用CUDA提供了更多的控制。程序员必须直接处理初始化、模块加载等。

显然,可以通过驱动程序API查询比通过运行时API更详细的设备信息。例如,只能通过驱动程序API查询设备上可用的可用内存。

来自CUDA程序员指南:

它由两个API组成:

• 一个称为CUDA驱动程序API的低级API,
• 一个更高级别的API称为CUDA运行时API,它是在 CUDA驱动程序API。

这些API是互斥的:应用程序应该使用一个或 其他。

CUDA运行时通过提供隐式的 初始化、上下文管理和模块管理。C主机代码 NVCC生成的是基于CUDA运行时(参见第4.2.5节),因此 链接到此代码的应用程序必须使用CUDA运行时API。

相反,CUDA驱动程序API需要更多的代码,更难编程和 调试,但提供了更好的控制级别,并且是独立于语言的,因为它只 处理Cubin对象(参见第4.2.5节)。尤其是,更难 自执行以来,使用CUDA驱动程序API配置和启动内核 必须使用显式函数调用指定配置和内核参数 而不是第4.2.3节中描述的执行配置语法。此外,设备 仿真(参见第4.5.2.9节)不适用于CUDA驱动程序API。

API之间没有明显的性能差异。您的内核如何使用内存以及它们在GPU上的布局(在翘曲和块中)将有更显著的效果。

我发现,对于在多线程应用程序中部署库,驱动程序API提供的CUDA上下文控制非常关键。我的大多数客户希望将GPU加速集成到现有的应用程序中,而现在,几乎所有的应用程序都是多线程的。因为我不能保证所有的GPU代码都将从同一个线程初始化、执行和释放,所以我必须使用驱动程序API。

我在运行时API中的各种工作区的初始尝试都导致了失败,有时是以惊人的方式——我发现我可以通过执行来自不同线程的错误CUDA调用集来重复、立即重新启动计算机。

自从我们通过驱动程序API迁移了所有东西之后,一切都很好。

J

需要注意的几个重要事项:

首先,API之间的差异仅适用于主机端代码。这些谷粒完全一样。在主机端,驱动程序API的复杂性非常小,基本区别在于:

在驱动程序API中,您可以访问在类似运行时API的上下文中不可用的功能。

模拟器只处理为运行时API编写的代码。

噢,目前CUDPP是一个非常方便的库,它只与运行时API一起工作。

参数对齐和驱动程序API存在一些实际问题。有关更多信息,请参阅CUDA 2.2 Beta(或更高版本)文档。