What are some options for copying textures from one OpenGL library to another?

Question

Context

I'm developing a plugin based architecture that is designed to allow each plugin to utilize its own graphics API so long as it can pass a standard texture format that the engine can ingest and render utilizing a master OpenGL graphics context and shaders. Ideally, each plugin will not be aware nor have access to the master OpenGL graphics context the engine is using. This means each plugin must provide their own context and render the graphics to a texture.

Problem

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. Therefore, the more plugins I'm running, the slower my software runs since this all occurs on one thread. I've been able to make use of shared contexts in some rare scenarios where the plugin uses the same graphics API as the master OpenGL graphics context. Otherwise, I have been unable to use shared contexts as libraries such as GLFW don't expose the necessary API to achieve shared contexts with external libraries.

Question

What would be some solutions to improving performance rendering multiple plugin implementation to texture so that the master context can render to display?

Additional Thoughts

My current solution is to try and run each plugin on a separate thread where the internal context and rendering would occur followed by a synchronization point where all plugins have to copy their textures back to the master context on the main thread. Before I go down this road, I wanted to make sure there wasn't another possible solution I could make use of.

If absolutely necessary, I could see a scenario where my software would pass the master context around allowing plugins to utilize it to create shared contexts. In this scenario, I would not need to copy textures to CPU memory and would simply pass the texture's pointer around. This would be a last ditch effort type of solution for the problem I'm trying to solve.

Answer 1

There is no such thing as a free lunch. The price you pay for API-agnosticism is that you give up any efficiencies that knowledge of the API would allow for. OpenGL has mechanisms to allow one context to share objects with another. But if you have decided that you don't know/care if a plugin is using OpenGL, you have to code against the lowest-common-demonator. And for this case, that means copying the textures through the CPU.

That's not going to be fast, but that's where your design choices have led you.

It would be easier or more reasonable to just stop being so agnostic. You should tell plugins that you're using OpenGL and that they have to use OpenGL too. And you should make them use OpenGL contexts you create, which allows you to share your objects with them.

Doing that makes everything very simple. And efficient.