是否可以在应用程序之间共享 Cuda 上下文？
我想在两个独立的 Linux 进程之间传递 Cuda 上下文（使用我已经设置的 POSIX 消息队列）。
使用 cuCtxPopCurrent() 和 cuCtxPushCurrent() ，我可以获取上下文指针，但该指针是在我调用该函数的进程的内存中引用的，并且传递进程之间的它是没有意义的。
我正在寻找其他解决方案。到目前为止我的想法是：
- 尝试深度复制 CUcontext 结构，然后传递副本。
- 看看我是否可以找到一个共享内存解决方案，其中我的所有 Cuda 指针都放置在那里，以便两个进程都可以访问它们。
- 将进程合并为一个程序。
- Cuda 4.0 中可能有更好的上下文共享，我可以切换到它。
我不确定选项（1）是否可行，也不确定选项（2）是否可用或可能。如果我想让事情变得通用（这是在劫持垫片内），（3）并不是一个真正的选择。 (4) 我会看看 Cuda 4.0，但我也不确定它是否能在那里工作。
谢谢！
I'd like to pass a Cuda context between two independent Linux processes (using POSIX message queues, which I already have set up).
Using cuCtxPopCurrent() and cuCtxPushCurrent(), I can get the context pointer, but this pointer is referenced in the memory of the process in which I call the function, and passing it between processes is meaningless.
I'm looking for other solutions. My ideas so far are:
- Try to deep copy the
CUcontextstruct, and then pass the copy. - See if I can find a shared-memory solution where all my Cuda pointers are placed there so both processes can access them.
- Merge the processes into one program.
- It is possible that there is better context sharing in Cuda 4.0, which I could switch to.
I'm not sure option (1) is possible, nor if (2) is available or possible. (3) isn't really an option if I want to make things generic (this is within a hijack shim). (4) I'll look at Cuda 4.0, but I'm not sure if it will work there, either.
Thanks!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
一句话，不。上下文隐式地与创建它们的线程和应用程序相关联。单独的应用程序之间不存在可移植性。这与 OpenGL 和各种版本的 Direct3D 几乎相同 - 不支持在应用程序之间共享内存。
CUDA 4 使 API 线程安全，以便单个主机线程可以同时保存超过 1 个上下文（即超过 1 个 GPU），并使用规范的设备选择 API 来选择它正在使用的 GPU。如果我正确理解你的问题/应用程序，这在这里没有帮助。
In a word, no. Contexts are implicitly tied to the thread and application that created them. There is no portability between separate applications. This pretty much the same with OpenGL and the various versions of Direct3D as well - sharing memory between applications isn't supported.
CUDA 4 makes the API thread safe, so that a single host thread can hold more than 1 context (ie. more than 1 GPU) simultaneously and use the canonical device selection API to choose which GPU it is working with. That won't help here, if I am understanding your question/application correctly.