将纹理从一个 OpenGL 库复制到另一个库有哪些选择？

Question

语境

我正在开发一个基于插件的架构，旨在允许每个插件使用自己的图形 API，只要它可以传递引擎可以使用主 OpenGL 图形上下文和着色器摄取和渲染的标准纹理格式。 理想情况下，每个插件都不会知道也无法访问引擎正在使用的主 OpenGL 图形上下文。 这意味着每个插件都必须提供自己的上下文并将图形渲染为纹理。

问题

My current implementation handles copying textures from one context to another by copying the texture data to CPU memory and then copying the CPU memory back into the GPU for the master OpenGL context to render. 因此，我运行的插件越多，我的软件运行速度就越慢，因为这一切都发生在一个线程上。 在插件使用与主 OpenGL 图形上下文相同的图形 API 的一些罕见场景中，我已经能够使用共享上下文。 否则，我无法使用共享上下文，因为诸如 GLFW 之类的库不会公开必要的 API 来实现与外部库的共享上下文。

问题

有什么解决方案可以提高性能，将多个插件实现渲染到纹理，以便主上下文可以渲染显示？

额外的想法

我目前的解决方案是尝试在单独的线程上运行每个插件，其中内部上下文和渲染将发生，然后是一个同步点，所有插件都必须将它们的纹理复制回主线程上的主上下文。 在我走这条路之前，我想确保没有其他可能的解决方案可以使用。

如果绝对必要，我可以看到我的软件将传递主上下文以允许插件利用它来创建共享上下文的场景。 在这种情况下，我不需要将纹理复制到 CPU memory 并且只需传递纹理的指针即可。 对于我要解决的问题，这将是最后的努力类型的解决方案。

Answer 1

没有免费的午餐。 您为 API 不可知论付出的代价是您放弃了了解 API 所允许的任何效率。 OpenGL 具有允许一个上下文与另一个上下文共享对象的机制。 但是，如果您决定不知道/不关心插件是否使用 OpenGL，则必须针对最低常见的恶魔进行编码。 对于这种情况，这意味着通过 CPU 复制纹理。

这不会很快，但这就是你的设计选择引导你的地方。

停止如此不可知论会更容易或更合理。 您应该告诉插件您正在使用 OpenGL 并且他们也必须使用 OpenGL。 您应该让他们使用您创建的 OpenGL 上下文，这允许您与他们共享您的对象。

这样做会使一切变得非常简单。 且高效。