将GPU与OpenCL结合使用的最佳实践

我已经开始使用OpenCL开发GPU。 我一直在玩推动极限的代码

在此期间，我遇到了GPU上的计算时间相对较长的情况，这会导致GUI变得无响应和/或GPU任务花费很长时间，以致设备驱动程序被重置

虽然我理解为什么会发生这种情况，但我并不寻找和解释原因， 我希望了解的是，我可以用系统用于GUI操作的GPU将计算推进多远

是否有此类互动的指导方针/最佳实践

是否有任何编程方法允许长时间运行GPU计算，并且仍然允许GUI保持响应

我知道基本建议是将GPU任务划分为相对较小的任务。我假设这是不可能的，因为我正在探索GPU编程的限制

任何在线讨论都会非常有用

---

Jim K

一个解决方案是使用两个显示设备：一个用于操作系统，另一个用于计算。但打破长期平衡也有好处。例如，假设一个GPU任务需要10天。您如何知道GPU任务在这10天内是否真正正常运行？将任务分解为几秒钟的段可以让您向控制程序添加进度报告功能。中断任务还允许控制程序实现定期状态保存功能，以便在断电后恢复。如果您想使用多个GPU来进一步加速计算，那么将任务分解为更小的部分是至关重要的。当每个GPU完成前一个部分时，可以给它分配一小部分工作。这样，所有GPU都将保持满载状态，直到任务完成。相反，如果将任务划分为每个GPU的大部分，则很难或不可能调整各个部分的大小，以便GPU同时完成所有任务

---

我相信大多数GPU工作负载可以分成几秒钟的部分，而不会造成任何明显的性能损失。因此，从这个意义上讲，分解任务并不会降低GPU计算的“极限”目标。如果控制程序将工作连续分派到操作系统显示器使用的GPU，则仍可能影响操作系统显示器的响应。这个问题的解决方案不会降低性能，它是使用远程桌面、VNC或类似工具远程访问计算机。

要回答您的问题，没有任何方法可以实现在一个GPU上拥有一个长期运行的内核和维护一个正常运行的GUI的目标。如果您想要长时间运行的内核和功能强大的GUI，那么必须使用专用GPU进行计算。如果在同一个GPU上进行计算时需要一个响应良好的GUI，那么必须有短时间运行的内核。你可能每周都会在AMD或Nvidia论坛上抱怨这个功能

---

唯一一种与平台无关的划分工作的方法是限制发送到GPU的工作量，使其在大约1/60秒（对于60Hz屏幕）内完成，并包括一个睡眠命令，该命令使CPU线程短时间处于睡眠状态，以便其他应用程序可以将任务发送到GPU。您可能需要调整时间限制，以找到不影响用户的内容。

您可能对异步编程感兴趣，这是在后台执行某些任务时保持应用程序响应的常用“解决方案”。这取决于你使用的语言，在C++中有Boost或最新的C++ 11标准，它们都支持异步任务/方法。是窗口本身变得无响应，而不是我的GUI。事实上，我正在使用命令行，我从编程的一般原则中知道这一切都是正确的。但是，由于我在探索极限，我仍然处于这种状态。（这样做的原因是技术的预期未来使用）。我目前拥有的是一个100万个工作项和一个4人的工作组（我也在探索极限）。总时间约为5秒（可调谐）。在执行时，系统GUI不工作。这也是人为的，因为我在探索极限。我同意斯科特德的观点。如果你的问题需要5秒钟，你需要把它分开。GPU任务应该在不到一秒钟的时间内运行，否则您的系统将变得非常无响应。运行100个50毫秒内核的效率不会低于1个5000毫秒内核的效率。这正是我所期望的。我只是想让更了解OpenCL的人来证实这一点。