我一直在使用 OpenCL 开始使用 GPU 进行开发。我一直在玩推动限制的代码。
在此期间，我遇到了 GPU 上的计算时间相对较长的情况，这会导致 GUI 变得无响应和/或 GPU 任务花费的时间过长以至于设备驱动程序被重置。
虽然我理解为什么会发生这种情况并且我不是在寻找和解释原因，但我希望了解的是，我可以使用系统用于 GUI 操作的 GPU 将计算推到多远。
是否有此类交互的任何指导方针/最佳实践
是否有任何编程方法可以允许长时间运行 GPU 计算并仍然允许 GUI 保持响应。
我知道基本的建议是将 GPU 任务拆分为相对较小我假设这是不可能的，因为我正在探索 GPU 编程的限制。
任何在线讨论都会非常有用。
吉姆·K
要回答您的问题，没有什么可以实现您的目标，即拥有一个长时间运行的内核并在一个 GPU 上维护一个正常工作的 GUI。如果您想要长时间运行的内核和正常运行的 GUI，则必须使用专用 GPU 进行计算。如果您希望在同一 GPU 上进行计算时获得响应式 GUI，则必须使用运行时间较短的内核。您可以每周在 AMD 或 Nvidia 论坛上抱怨请求此功能。
唯一能想到的独立于平台划分工作的方法是限制发送到 GPU 的工作量，使其在 1/60 秒（对于 60Hz 屏幕）内完成，并包含一个睡眠命令，该命令将CPU 线程休眠一会儿，以便其他应用程序可以将任务发送到 GPU。您可能必须调整该时间限制以找到不影响用户的内容。
一种解决方案是使用两个显示设备：一个用于操作系统，另一个用于计算。但从长远来看，打破有好处。例如，假设一个 GPU 任务需要 10 天。您如何知道 GPU 任务在这 10 天期间真正运行正常？将任务分成几秒钟的片段允许您向控制程序添加进度报告功能。分解任务还允许控制程序实现周期性状态保存功能，以便在电源故障后恢复。如果您想使用多个 GPU 来进一步加速计算，那么必须将任务分成更小的部分。当每个 GPU 完成前一个片段时，可以将一小部分工作分配给它。这样，所有 GPU 将保持完全加载，直到任务完成。
我相信大多数 GPU 工作负载都可以分解为几秒钟的片段，而不会造成任何显着的性能损失。因此，从这个意义上说，分解任务并没有减损 GPU 计算“突破极限”的目标。如果控制程序不断地向操作系统显示器使用的GPU分配工作，它仍然可能影响操作系统显示器的响应能力。解决此问题且不会降低性能的方法是使用远程桌面、VNC 或类似工具远程访问机器。