在两个应用程序之间共享OpenGL帧缓冲区/渲染缓冲区

Question

假设我有一个应用程序A女巫负责通过OpenGL库在屏幕上绘制内容。为了实现紧密集成，我想让这个应用程序A完成它的工作，但是在FBO中或直接在渲染缓冲区中渲染，并允许应用程序B具有只读访问此缓冲区以处理屏幕上的显示（基本上将其渲染为2D纹理）。

似乎FBO属于OpenGL上下文，上下文在进程之间不可共享。我当然明白，允许多个进程两个混乱使用相同的上下文是邪恶的。但在我的特殊情况下，我认为这是合理的，认为它可能非常安全。

注意：

应用A为QApplication，应用B为native win32

编辑：

渲染大小接近全屏，我想的是2048x2048 32bits缓冲区（我现在不使用alpha通道，但为什么不使用后者）。

Answer 1

Framebuffer对象不能在OpenGL上下文之间共享，无论它们是否属于同一进程。但纹理可以共享和纹理可以用作帧缓冲对象的颜色缓冲附件。

如果图形系统为此作业提供API，则实际可以在进程之间共享OpenGL上下文。在X11 / GLX的情况下，可以在多个进程之间共享间接呈现上下文。在Windows中可能有可能实现一些真正粗暴的黑客攻击。 MacOS X，不知道如何做到这一点。

因此，最简单的方法是使用像素缓冲区对象来获得对渲染图片的高效访问。然后通过共享内存将其发送到另一个应用程序并将其上传到那里的纹理（再次通过像素缓冲区对象）。

Answer 2

在 MacOS 中，您可以使用 IOSurface 在两个应用程序之间共享帧缓冲区。

Answer 3

根据我的理解，除非是内核模式对象，否则您将无法在Windows下的进程之间共享对象。即使是共享纹理和上下文也可以创建性能命中，它还为您提供了同步SwapBuffer（）调用的额外责任。特别是在Windows平台下，OpenGL实现是臭名昭着的。

在我看来，您可以继续使用事件，互斥，窗口消息，管道等进程间通信机制来同步渲染。但只是意识到以这种方式接近的性能考虑因素。内核模式对象很好但每次转换到内核的成本都是100毫秒。对于高性能渲染应用来说，这是非常昂贵的。在我看来，你必须重新考虑多进程渲染设计。