Performance implications of context-level configuration

I’m in the process of building a more complex system on top of Optix and I’m wondering about the performance implications of some top-level context functions such as setEntryPointCount, setRayTypeCount, setRayGenerationProgram.

I was thinking of allowing a user of that system to instantiate several different kinds of renderers (that may have any number of ray_gen programs), and binding one to be “active” on the context before triggering a render. In a straightforward implementation, each unique bind (e.g., no-op when binding the same renderer) would setEntryPointCount, and bind the relevant ray_gen with setRayGenerationProgram. But now I wonder about the overhead incurred when switching renderers.

The alternative would be to size the EntryPointCount and RayTypeCount to the total number of permutations possible. This wouldn’t be so bad for the RayTypeCount: I can see how all the permutations can use a small common set of ray types, especially since material programs will have to be configured for those rays. For the ray_gens it would be a different story. Potentially I could “reserve” a safe number of entry points on the context and then attribute slots to specific renderers as they come online. What is the impact of “resizing” the EntryPointCount? And would that invalidate prior setRayGenerationProgram calls?

In general, any idea of what the cost of such top-level reconfiguration is? What happens when these APIs are called? What is their impact?

Any feedback is appreciated :)