一个设备的多个 CUDA 上下文 - 有什么意义吗？答案

【问题标题】：Multiple CUDA contexts for one device - any sense?一个设备的多个 CUDA 上下文 - 有什么意义吗？
【发布时间】：2015-07-09 23:00:07
【问题描述】：

我以为我掌握了这一点，但显然我没有:) 我需要使用 NVENC 从不采用编码器接受的任何格式的帧执行并行 H.264 流编码，所以我有以下代码管道：

调用通知新帧已到达的回调
我将帧复制到 CUDA 内存并执行所需的色彩空间转换（只有第一个 cuMemcpy 是同步的，所以我可以从回调中返回，所有挂起的操作都推送到专用流中）
我将一个事件推送到流中，并让另一个线程等待它，一旦它被设置，我就将 CUDA 内存指针与正确颜色空间中的帧一起提供给解码器

出于某种原因，我假设如果我在并行线程中执行此管道，我需要为每个线程提供专用上下文。代码很慢，经过一番阅读，我了解到上下文切换实际上很昂贵，然后我实际上得出结论，这是没有意义的，因为在上下文中拥有整个 GPU，所以我锁定了来自其他转码器线程的任何并行处理.

问题 1：在这种情况下，我是否适合为执行上述管道的每个线程使用单个上下文和在此上下文上创建的显式流？

问题 2： 有人能告诉我 CUDA 设备上下文的唯一目的是什么吗？我认为这在多 GPU 场景中是有意义的，但是在任何情况下我想为一个 GPU 创建多个上下文？

【问题讨论】：

什么是 NVCENC ？我听说过 NVENC 和 NVCUVENC。
@RobertCrovella，我的错，NVENC 拼写错误。

标签： c++ cuda video-encoding cuda-context

【解决方案1】：

问题 1：在这种情况下，我是否适合为执行上述管道的每个线程使用单个上下文和在此上下文上创建的显式流？

你应该没问题。

问题 2：有人能告诉我 CUDA 设备上下文的唯一目的是什么吗？我认为这在多 GPU 场景中是有意义的，但是在任何情况下我想为一个 GPU 创建多个上下文？

the programming guide 中讨论了 CUDA 设备上下文。它表示与特定进程相关联（即与该特定进程对 GPU 的使用相关联）的所有状态（内存映射、分配、内核定义和其他与状态相关的信息）。不同的进程通常会有不同的上下文（就像不同的设备一样），因为这些进程有独立的 GPU 使用和独立的内存映射。

如果您使用 GPU 的多进程使用，您通常会在该 GPU 上创建多个上下文。正如您所发现的，可以从单个进程创建多个上下文，但通常不是必需的。

是的，当您有多个上下文时，在这些上下文中启动的内核将需要上下文切换才能从一个上下文中的一个内核转到另一个上下文中的另一个内核。这些内核不能同时运行。

CUDA 运行时 API 使用为您管理上下文。在使用运行时 API 时，您通常不会显式地与 CUDA 上下文交互。但是，在驱动程序 API 使用中，上下文是显式创建和管理的。

【讨论】：

当您说多个上下文不能同时运行时，这是否仅限于内核启动，还是指内存传输？我一直在考虑在同一个 GPU 上进行多进程设计，该 GPU 使用 IPC API 在进程之间传输缓冲区。这是否意味着实际上，一次只有一个进程可以独占访问整个 GPU（而不仅仅是特定的 SM）？这不是我设计的杀手，但令人失望。就调度而言，这如何与每个进程中的流上的异步排队内核/副本相互作用？
关于您的第一个问题，我认为我的回答中倒数第二段非常清楚地表明我在谈论并发内核，但我做了一些细微的修改以消除疑问。关于其余部分，我建议您提出一个新问题。在 cmets 领域深入研究这些主题是不切实际的。
@RobertCrovella 鉴于最终需要跨线程同步的单个 cuda 上下文 (cuvidCtxLock) 这是否意味着我们永远无法使用 NVENC API 真正并发执行？如果我在单个线程本身中循环多个流的帧以进行编码，它会更快吗？

【解决方案2】：

显然几年过去了，但 NVENC/NVDEC 现在似乎从视频编解码器 SDK 的 9.1 版（大约 2019 年 9 月）开始支持 CUstream：https://developer.nvidia.com/nvidia-video-codec-sdk/download

9.1 的新功能 - 编码：NVENC 中的 CUStream 支持增强了 CUDA 预处理和 NVENC 编码之间的并行性

我是 CUDA 的超级新手，但我的基本理解是 CUcontexts 允许多个进程使用 GPU（通过执行中断彼此工作的上下文交换），而 CUstreams 允许从内部协调共享 GPU 的资源一个进程。

【讨论】：