在支持 OpenCL 的程序之间共享 GPU
是否有一种方法可以在两个独立的支持 OpenCL 的程序之间共享 GPU，或者更具体地说，在两个同时需要 GPU 执行 OpenCL 内核的独立进程之间共享 GPU？如果是这样，这是如何完成的？
Is there a method to share the GPU between two separate OpenCL capable programs, or more specifically between two separate processes that simultaneously both require the GPU to execute OpenCL kernels? If so, how is this done?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
这取决于你所说的共享。
一般来说，您可以在同一个 GPU 上创建 2 个进程来创建 OpenCL 设备。然后驱动程序/操作系统/GPU 负责确保一切正常工作。
也就是说，大多数实现都会对 GPU 执行进行时间切片来实现这一点（就像图形中发生的那样）。
我感觉这并不完全是你所追求的。你能用一个用例来扩展你的问题吗？
It depends what you call sharing.
In general, you can create 2 processes that both create an OpenCL device, on the same GPU. It's then the driver/OS/GPU's responsibility to make sure things just work.
That said, most implementations will time-slice the GPU execution to make that happen (just like it happens for graphics).
I sense this is not exactly what you're after though. Can you expand your question with a use case ?
当前的 GPU（除了 NVidia 的 Fermi）不支持同时执行多个内核。此外，迄今为止 GPU 还不支持抢占式多任务处理；这是完全合作的！内核的执行不能被暂停并在以后继续。因此，任何基于时间的 GPU 共享的粒度都取决于内核的执行时间。
如果您运行多个需要 GPU 访问的程序，则应确保内核的运行时间较短（根据经验，小于 100 毫秒），以便 GPU 时间可以在需要 GPU 周期的内核之间进行时间分割。这样做也很重要，否则主机系统的图形将变得非常无响应，因为它们也需要 GPU 访问。这可能会导致内核处于无限或长循环中，显然会使系统崩溃。
Current GPUs (except NVidia's Fermi) do not support simultaneous execution of more than one kernel. Moreover, to this date GPUs do not support preemptive multitasking; it's completely cooperative! A kernel's execution cannot be suspended and continued later on. So the granularity of any time-based GPU sharing depends on the kernels' execution times.
If you have multiple programs running that require GPU access, you should therefore make sure that your kernels have short runtimes (< 100ms is a rule of thumb), so that GPU time can be timesliced among the kernels that want GPU cycles. It's also important to do that since otherwise the host system's graphics will become very unresponsive as they need GPU access too. This can go as far that a kernel in an endless or long loop will apparently crash the system.