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

Question

上下文

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

问题

我当前的实现通过将纹理数据复制到 CPU 内存然后将 CPU 内存复制回 GPU 以供主 OpenGL 上下文进行渲染来处理将纹理从一个上下文复制到另一个上下文。因此，我运行的插件越多，我的软件运行速度就越慢，因为这一切都发生在一个线程上。 在插件使用与主 OpenGL 图形上下文相同的图形 API 的一些罕见场景中，我已经能够使用共享上下文。否则，我将无法使用共享上下文，因为 GLFW 等库没有公开必要的 API 来实现与外部库的共享上下文。

问题

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

其他想法

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

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

Answer 1

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

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

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

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