The main functionality of sharing OpenGL contexts is to make the object lookup tables unique to be able to access the same objects in multiple contexts. Having multiple OpenGL contexts shared in different threads comes with some locking overhead inside the OpenGL driver. The potential performance impact of that depends on the use case.
It’s a common technique to use one thread for asynchronous resource management, e.g. loading textures on the fly, and a main rendering thread using these resources. That needs some care to make sure things currently used for rendering aren’t touched in the resource handling thread.
For your use case I wouldn’t expect much of an overhead. You would need to be careful to wait for the renderer to have finished displaying the last texture and some critical section around the texture update function to block the renderer from accessing the texture while you’re uploading it.
Now, with all that said, what you’re doing is only going to work on single GPU systems.
When setting up an OptiX context to use more than one device, the final output buffers are not on the device but in pinned host memory. Means there is no way to use an OpenGL PBO to do OpenGL interop on that buffer.
An architecture which would support completely asynchronous ray tracing with OptiX would need to handle that case differently. Like having a ray tracing thread which does all OptiX handling and a rasterizer (main) thread which cares about all display with OpenGL in the app.
Then you would just need to have a critical section in which you copy the OptiX result buffer to some shared location (on the host) and signal to the display thread that there is a new image to be uploaded which then locks that memory during the texture upload. And so forth.
That’s obviously going to be slower than real OpenGL interop, but, for example, in a Windows system with one graphics board in WDDM mode for display and one or preferably more in TCC mode for ray tracing (TCC can’t do OpenGL interop either), that would be optimal.
The GUI would be full speed and the ray tracing wouldn’t be limited by Windows WDDM timeouts (TDR) when doing arbitrary complex ray tracing algorithms.
Also with NVLINK capable boards, the TCC mode will allow to use peer-to-peer access across the NVLINK bridges in OptiX automatically which increases your possible scene size.
This is more of a rendering than real-time view on the problem.