确定cuda设备是否正在使用？

如何解决确定cuda设备是否正在使用？

是否可以直接测试任何内核当前是否正在使用cuda设备？

我有一个后台线程，可在分形程序完全使用时启动“原始” cuda内核。该线程建立了较大的图像阵列，然后我希望该阵列让用户平稳地平移，旋转和缩放。

如果大图形转换当前未使用它，我的GUI线程希望使用GPU，因为它以100 fps的速度运行。如果使用了GPU，我可以转而以10-20 fps的速度使用cpu 代码。

如果在后台线程内核已经运行时使用GUI线程GPU代码，则GUI线程将明显冻结，直到后台内核完成。我试图通过切换这些帧的cpu 代码来消除这种冻结。我已经研究过中断后台内核，但是我看到的解决方案这样做会增加内核的计算成本和/或重置上下文，这两者似乎都过分了。

有没有一种方法可以直接（异步）检测GPU是否正在使用（任何内核）？我想从技术上讲，GPU始终被用作2-D显示驱动程序，因此当然要排除该活动。

我的解决方法是在我的程序中有一个标记，用于跟踪所有内核是否已完成。我需要在程序的两个宿主线程之间以及“模型”和“视图”中最嵌套的对象之间传递该标志。我开始写这篇文章，并认为这是一个混乱的解决方案，即使如此，也并非总是100％准确。因此，我想知道是否有更好的方法，尤其是是否可以在GUI线程中直接决定是否需要对下一帧使用GPU或cpu 代码的决定进行测试。

我使用的是python 3.7，但需要使用ccupy访问GPU，但是我愿意尝试改编C ++解决方案。

我看过文档，但是仅具有cuda的基本知识，这就像在大海捞针中寻找针头一样： https://docs.nvidia.com/cuda/cuda-runtime-api/group__CUDART__DEVICE.html#group__CUDART__DEVICE

解决方法

这是我在@RobertCrovella的帮助下使用的解决方案。

import cupy as cp

stream_done: bool = cp.cuda.get_current_stream().done

if stream_done or worker_ready:
    # use cupy to draw next frame
else:
    # use numpy to draw next frame

worker_ready是从后台工作器GPU线程传递的一个布尔值，指示其活动。

有关stream_done的信息，请参见docs。在我的程序中，我仅使用1个cuda流（（未指定）默认流）。否则，我想您需要根据问题测试每个流。

经过大量测试，我发现：

cp.cuda.get_current_stream().done在内核运行后立即在后台线程中为True，但是在我的代码没有在True和False状态之间调用GPU的情况下，我仍然需要在其中进行测试的地方变为False。我无法解释这种行为，但是我发现我不能完全依靠stream_done。我的测试表明：如果stream_done在所需的时间点为True，那么使用GPU始终是安全的；如果stream_done为False，则使用GPU可能安全，也可能不安全。

我还让后台线程在启动和停止时触发一个事件，该事件更改了GUI线程的worker_ready bool。我的测试表明，worker_ready在确定是否可以使用GPU方面比stream_done更准确。在stream_done为True且worker_ready为False的情况下，我的测试表明GPU代码也将快速运行，大概是因为后台线程当时正在执行CPU代码。

因此，我所提出的解决此问题的最佳方法是，如果满足任一条件，则使用GPU代码。但是，即使这样也不能消除我要消除的视觉滞后。

我要解决的问题是，当GPU上正在运行后台进程并且用户试图平移时，偶尔会出现至少0.5s的明显滞后。我试图通过测量从按下鼠标到显示平移图像的时间来量化这种滞后。测得的时间延迟为0.1s或更短。因此，无论单击鼠标后代码有多快，无论使用GPU还是CPU，都无法消除滞后。对我来说，这意味着当GPU被占用时，启动鼠标按下事件本身会延迟触发。大概是因为GPU也正在运行显示驱动程序。除此以外，我没有任何确凿的证据：

如果后台线程未运行，则将滞后消除。
将内核缩短几个数量级并没有减少延迟。
增加block_size使其远离完全占用状态似乎可以消除大部分时间的滞后，尽管并不能完全消除滞后。