I may have asked this here before, and not gotten a response, I’m not sure.
What would be the consequences of trying to maintain two GL contexts in different threads, one for the onscreen rendering and another for building procedural textures and the like?
Basically my design has a rasterizer thread continuously spitting data to a context that is displayed to the screen, but I need the application thread to be able to load data into textures and perform elementary GL blend operations on and between the textures to generate some procedural effects. I don’t want to do the blending on the CPU since once I’ve loaded pixel data into a texture, I want it to stay there.
Would it be okay in this situation to create another GL context sharing texture and display list space with the rasterizer context in which I would build textures? I imagine this seriously cuts down performance on both contexts, though. If I could use an aux. buffer in the primary context I could just temporarily interupt rendering and switch to it for the texture operations. As it stands I’m looking at having to batch all GL operations not intended for the screen and execute them between frames. Is this the better idea?