For some techniques it 'may' be useful to be able to have two separate OptiX 'contexts' and to be able to share buffers between them in a similar way you can with OpenGL contexts between threads etc. The idea I think may be reasonable solution is that an entry point could be an 'object' that a context instantiates instead of just being 'part' of a context. This would mean each entry-point object has an idea of its own mini-context and variables set on it are essentially in a new context scope and exist only for that entry point so validation of variables and recompilation of the OptiX kernel is more lean. Its a change of interface but I was thinking of this solution because of an observation made in http://developer.nvidia.com/devforum/discussion/3351/asynchronous-read-of-zero-copy-output-buffers-in-optix

We could see this possibly being useful as you could have a render context and a collision context so it is possibly to run them in parallel/asyncronous to each other or on a separate GPU. This opens up the ability to have an easier interface for parallel kernel launches within OptiX if/when this were possible. For now it would be sufficient to assume launches are executed in series but the GPU affinity could be set at the EntryPoint level in future when the architecture allows I guess. Currently we have about 5/6 with some being debugging/edge-detection/anti-aliasing/collision entry points etc. From our understanding having a single entry point being compiled when something changes would make things a lot faster to compile.