[OptiX 6.0] Using the semantic variable rtCurrentRay is not allowed from bound callable program

Hi,

In OptiX 6.0, reading rtCurrentRay in a bound callable program results in an error “Using the semantic variable rtCurrentRay is not allowed from bound callable program”. Is it a new limitation?

I don’t understand why this limitation must be introduced in OptiX 6.0. From the new doc and release note, it is not mentioned.

If reading rtCurrentRay is not allowed anymore, then we can only pass additional variables to our callable programs. Would it use more stacks ?

Thanks.

The rtCurrentRay is only accessible inside the closet hit, any hit, miss, intersection and visit program domains.
(Note that visit programs have been removed along with selectors from the RTX execution strategy.)
http://raytracing-docs.nvidia.com/optix/guide/index.html#programs#internally-provided-semantics

From where did you call your bound callable program?
Could you provide a minimal reproducer by changing one of the OptiX SDK examples?

My recommendation would be to not use bound callable programs at all and restructure your code to use bindless callable programs instead.
They definitely do not have access the rtCurrentRay because their scope is only themselves and the OptiX context.

Hi Detlef,

These bound callable programs are called from closet hit. I use bound callables because I guess that it may reduce stack and register usage. I read rtCurrentRay and read-write rtPayload there, such as different ways to evaluate lighting (e.g., with current ray and attenuation), different ways to generate next rays (e.g., update next ray origin and direction) and etc. The extended scope may bring knowledge to OptiX for possible optimizations.

If I use bindless callables, then I have to explicitly declare new variables, copy and pass them to the bindless callables. Would this way use more stack and registers ?

Thanks,

Thanks, I’ve asked internally what’s going on with that.

I’m using bindless callable programs exclusively. Bound callable programs are potentially slower.
Yes, that needs some copying of data to local structures which can then be passed on to the bindless callable program.

I normally use a reference to a local structure to pass as argument, e.g. State in the examples below and that is a small one. Often that structure can be used throughout the caller.
My main concern is kernel size and architecture elegance, then memory accesses. Getting that right almost automatically results in good performance. I only need one closest hit program for all materials in my path tracers, and one of them implements almost the full Material Definitition Language (MDL) spec and, boy, that needs some amount of local storage, but without recursions that is not a problem.

Also it’s actually supported to pass references/pointers of the current rtPayload, although that is generally illegal and an error for any variable declared with rtDeclareVariable otherwise.
Example where I’m using that:
https://github.com/nvpro-samples/optix_advanced_samples/blob/master/src/optixIntroduction/optixIntro_07/shaders/closesthit.cu#L116
https://github.com/nvpro-samples/optix_advanced_samples/blob/master/src/optixIntroduction/optixIntro_07/shaders/closesthit.cu#L137

Thank you for the suggestions, and also the confirmation about the rtPayload.
It is actually not difficult to convert to use bindless callables in my case then.

Your examples have been helpful. Bound callables is a major difference, now I am trying to converge :)