问题标签 [cuda-context]

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

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

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

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

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

我正在使用 Cuda 驱动程序 api，现在我遇到了关于创建 Cuda 纹理对象的问题，它总是返回 CUDA_ERROR_INVALUD_VALUE。

我发现函数 cuTexObjectCreate 被宏包装：

而我由 cuCtxCreate_v2 创建的 Cuda 上下文总是返回 api 版本 3020。这是否意味着我应该创建一个高版本的上下文？我应该调用哪个函数？或者是别的什么？

这是示例代码：

PS：工作环境：GTX960；Cuda7.5；windows7-x64；visual studio 2013；

有没有办法在给定的时间发现有多少进程在 GPU 上运行并可能管理它们（yield，resume，kill ... 必要时）。我想要做的是当我运行不同的程序时，监控 GPU 上的每个进程活动。我没有看到如何做到这一点。我看到 GPU 上下文是进程的 CPU 等价物，但是我读到的所有解释都是关于在单个程序中影响它。同样，我想要的是跟踪 GPU 上的所有活动（就像使用该nvidia-smi工具，但使用我自己的方式）。任何人都可以帮助我吗？这甚至可能吗？

当我开始 cuda 调试时，Nsight 返回此错误：

在当前不可调试的 GPU 上创建了 CUDA 上下文。断点将被禁用。

适配器：GeForce GT 720M

这是我的系统和 CUDA 信息。

请注意，安装了最新版本的 CUDA 和 Nsight。

我搜索了这个问题，但找不到我的答案。太感谢了。

谁能解释或向我推荐一些关于什么是 CUDA 上下文的好资料？我搜索了 CUDA 开发人员指南，但对它并不满意。

任何解释或帮助都会很棒。

问题1）

当我调用 CUDA 驱动 API 时，通常我需要先将上下文（代表 GPU 运行时）推送到当前线程。对于 normal cuMalloc，内存将分配在上下文指定的 GPU 上。但是如果我尝试调用cuMallocManaged创建统一内存，是否还需要推送 GPU 上下文？

问题2）

假设我有 2 个 GPU，每个都有 1 GB DRAM。那么我可以分配2 GB的统一内存吗？每个 GPU 拥有一半吗？

当我开始 Cuda 调试时，Nsight 返回此错误：

在当前不可调试的 GPU 上创建了 CUDA 上下文。断点将被禁用。

适配器：GeForce GT 720M

我有 Visual Studio 2017 和 NVIDIA Nsight 5.4。有什么解决办法吗？我读到 Nsight 版本 >= 5.2 不支持我的卡。

安装较旧的 Nsight 版本没有帮助，因为它不支持 VS 2017 ...

我开发的软件通常包括 OpenGL 和 Nvidia CUDA SDK。最近，我也开始寻找优化运行时内存占用的方法。我注意到以下内容（调试和发布版本仅相差 4-7 Mb）：

应用程序启动 -总共不到1 Mb

OpenGL 4.5 上下文创建（+ GLEW 加载程序初始化） -总共45 Mb

CUDA 8.0 上下文（驱动程序 API）创建总共114 Mb。

如果我在“无头”模式下创建 OpenGL 上下文，则 GL 上下文会少用 3 Mb，这可能会用于默认帧缓冲区分配。这是有道理的，因为窗口大小是 640x360。

因此，在 OpenGL 和 CUDA 上下文启动后，该进程已经消耗了114 Mb。

现在，我对在 GL 和 CUDA 上下文创建期间发生在幕后的操作系统特定的东西没有深入的了解，但是 GL 的 45 Mb 和 CUDA 的 68 对我来说似乎很多。我知道通常有几兆字节用于系统帧缓冲区、函数指针（可能大部分分配发生在驱动程序端）。但是仅使用“空”上下文达到 100 Mb 以上看起来太多了。

我想知道：

1. 为什么 GL/CUDA 上下文创建会消耗如此大量的内存？

2. 有没有办法优化它？

被测系统设置：Windows 10 64bit。NVIDIA GTX 960 GPU（驱动程序版本：388.31）。8 Gb 内存。Visual Studio 2015，64 位 C++ 控制台项目。

我使用 Visual Studio 内置的诊断工具 -> 进程内存部分测量内存消耗。

更新

按照 datenwolf 的建议，我尝试了 Process Explorer。这是我得到的屏幕截图（底部标记为黄色的我的过程）：

我将不胜感激有关该信息的一些解释。我总是在“VS 诊断工具”窗口中查看“私人字节”。但在这里我还看到“工作集”、“WS Private”等。哪一个正确显示了我的进程当前使用了多少内存？281,320K 看起来太多了，因为正如我上面所说，启动时的进程什么都不做，而是创建 CUDA 和 OpenGL 上下文。

仅使用驱动程序 api，例如，我有一个带有以下单个进程的分析 (cuCtxCreate)，cuCtxCreate 开销几乎可与 GPU 之间的 300MB 数据复制相媲美：

在此处的CUDA 文档中，它说 (for cuDevicePrimaryCtxRetain) Retains the primary context on the device, creating it **if necessary**。这是从命令行重复调用同一进程的预期行为（例如运行 1000 次进程以显式处理 1000 个不同的输入图像）？设备是否需要 CU_COMPUTEMODE_EXCLUSIVE_PROCESS 才能按预期工作（多次调用时重复使用相同的上下文）？

现在，即使我多次调用该过程，上图也是相同的。即使不使用分析器，时间也显示大约 1 秒的完成时间。

编辑：根据文档，主要上下文是one per device per process. 这是否意味着使用多线程单应用程序时不会出现问题？

什么是主要上下文的重用时间限制？进程之间的 1 秒可以吗，还是必须以毫秒为单位才能保持主上下文处于活动状态？

我已经将 ptx 代码缓存到一个文件中，因此唯一剩余的开销看起来像 cuMemAlloc()、malloc()，cuMemHostRegister()因此重新使用上次调用同一进程的最新上下文可以很好地优化时序。

编辑 2：文档说The caller must call cuDevicePrimaryCtxRelease() when done using the context.. 来电者这里有任何进程吗cuDevicePrimaryCtxRetain？我可以在数百个顺序调用的进程列表中只在第一个调用的进程中使用保留并在最后一个调用的进程上使用释放吗？如果最后一个进程无法启动且未调用，系统是否需要重置？cuDevicePrimaryCtxRelease

编辑3：

主要上下文是为此而设计的吗？

• 一切都是为 sm_30 编译的，设备是 Grid K520。
• GPU 在 cuCtxCreate() 期间处于提升频率
• 项目是在 Windows Server 2016 操作系统和 CUDA 驱动程序安装上编译的 64 位（发布模式），与 windows-7 兼容（这是 K520 + windows_server_2016 的唯一方法）

^{注意：该问题已更新以解决评论中提出的问题，并强调该问题的核心是关于 Runtime- 和 Driver API 之间的相互依赖关系}

CUDA 运行时库（如 CUBLAS 或 CUFFT）通常使用“句柄”的概念来总结此类库的状态和上下文。使用模式非常简单：

但是，关于这些句柄如何与驱动程序和运行时上下文以及多个线程和设备进行互操作，有许多微妙的细节。该文档列出了有关上下文处理的几个分散的详细信息：

• 在http://docs.nvidia.com/cuda/cuda-c-programming-guide/index.html#context的 CUDA 编程指南中对上下文的一般描述

• 多个上下文的处理，如http://docs.nvidia.com/cuda/cuda-c-best-practices-guide/index.html#multiple-contexts上的 CUDA 最佳实践指南中所述

• 运行时和驱动程序 API 之间的上下文管理差异，在http://docs.nvidia.com/cuda/cuda-driver-api/driver-vs-runtime-api.html中进行了解释

• http://docs.nvidia.com/cuda/cublas/index.html#cublas-context的 CUBLAS 上下文/句柄的一般描述及其线程安全http://docs.nvidia.com/cuda/cublas/index .html#thread-safety2

然而，一些信息似乎并不完全是最新的（例如，我认为应该使用cuCtxSetCurrent而不是cuCtxPushCurrentand cuCtxPopCurrent？），其中一些似乎来自“主要上下文”处理通过驱动程序 API 公开之前的时间，并且某些部分过于简单化，因为它们仅显示最简单的使用模式，仅对多线程进行模糊或不完整的陈述，或者不能应用于运行时库中使用的“句柄”概念。

我的目标是实现一个运行时库，它提供自己的“句柄”类型，并允许在上下文处理和线程安全方面与其他运行时库等效的使用模式。

对于库可以在内部仅使用Runtime API实现的情况，事情可能很清楚：上下文管理完全由用户负责。如果他创建自己的驱动程序上下文，则将适用文档中有关运行时和驱动程序上下文管理的规则。否则，运行时 API 函数将负责处理主要上下文。

但是，可能存在库内部必须使用Driver API的情况。例如，为了将 PTX 文件作为CUmodule对象加载，并从中获取CUfunction对象。当库应该（对于用户而言）表现得像运行时库，但内部必须使用驱动程序API 时，就会出现一些问题，即必须如何“在后台”实现上下文处理。

到目前为止，我所想出的都在这里勾勒出来。

_{（它是“伪代码”，因为它省略了错误检查和其他细节，并且......所有这些都应该在 Java 中实现，但这在这里不应该相关）}

1. “句柄”基本上是一个包含以下信息的类/结构：

2.创建时，必须涵盖两种情况： 可以在调用线程的驱动程序上下文为当前时创建。在这种情况下，它应该使用这个上下文。否则，它应该使用当前（运行时）设备的主要上下文：

3.当调用库的内核时，相关句柄的上下文对于调用线程来说是当前的：

在这里，有人可能会争辩说，调用者负责确保所需的上下文是当前的。但是，如果句柄是为主要上下文创建的，那么该上下文将自动变为当前上下文。

4.当句柄被销毁时，这意味着cuDevicePrimaryCtxRelease必须调用它，但前提是上下文是主上下文：

例如，从我迄今为止的实验来看，这似乎暴露了与 CUBLAS 句柄相同的行为。但是我彻底测试这个的可能性是有限的，因为我只有一个设备，因此无法测试关键情况，例如有两个上下文，两个设备中的每一个都有一个。

所以我的问题是：

• 是否有任何既定的模式来实现这样的“句柄”？
• 是否有任何使用模式（例如，使用多个设备和每个设备一个上下文）无法被上面概述的方法覆盖，但会被 CUBLAS 的“句柄”实现覆盖？
• 更笼统地说：是否有关于如何改进当前“处理”实施的建议？
• 修辞：CUBLAS 句柄处理的源代码在某处可用吗？

（我还查看了tensorflow 中的上下文处理，但我不确定是否可以从中得出有关如何为运行时库实现句柄的建议......）

^{（此处删除了“更新”，因为它是根据评论添加的，应该不再相关）}