我一直在使用OpenCL开始GPU的开发。我一直在玩突破极限的代码。
在此期间，我遇到了GPU上的计算时间相对较长的情况，这导致GUI变得没有响应和/或GPU任务花费了很长时间，以至于设备驱动程序被重置。
虽然我理解为什么会发生这种情况，但我并不是在寻找原因和解释，我希望了解的是，我可以用系统用于GUI操作的GPU将计算推进多远。
是否有此类互动的指导方针/最佳实践
是否有任何编程方法可以允许长时间运行GPU计算，并且仍然允许GUI保持响应。
我知道基本的建议是将GPU任务拆分为相对较小的任务。我认为这是不可能的，因为我正在探索GPU编程的局限性。
任何在线讨论都将非常有用。
Jim 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工作负载可以分解为每个几秒钟的片段，而不会有任何显著的性能损失。因此，从这个意义上说，分解任务并没有偏离GPU计算"突破极限"的目标。如果控制程序将工作连续分派给OS显示器使用的GPU，则它仍然可能影响OS显示器的响应性。解决此问题的一个不会降低性能的方法是使用远程桌面、VNC或类似功能远程访问计算机。