I’m a bit confused by two examples in the SDK; execution_cuda and optix7. In the first one, in direct call mode, it shows how to compile the module to link the texture functions like tex_lookup_float4_2d that maps to tex::lookup_float4(). But the compilation is directly into a cuda module (cubin file).
But, in Optix7, you must provide PTX code that is ompiled and then used to create callables that can be added in the binding table.
What confuses me is with Optix7, how can I merge a PTX, from an MDL, with the texture functions that I would implement (already compiled to PTX).
sorry, somehow I missed this topic. Surely you already solved this problem, but for completeness, here’s my answer.
The Optix 7 example demonstrates two ways how to use the texture runtime.
In both cases, the texture runtime is included in the optix7_mdl_closest_hit_radiance.cu (#include "texture_support_cuda.h").
NO_DIRECT_CALL defined: optix7_mdl_closest_hit_radiance.cu is compiled with Clang 7 to bitcode and provided to the MDL SDK as backend option “llvm_renderer_module” as the renderer module. The generated code will then be linked and optimized together with the provided code, which not only contains the calls to the generated code but also the texture runtime.
NO_DIRECT_CALL not defined: In this case, the generated code is called as callables. The texture runtime is only present in the single closest hit shader calling those callables. The functions are marked as extern "C" to make them visible to the OptiX pipeline linker. And it seems like, the pipeline linker is able to correctly link the texture runtime functions requested in the generated code with these functions.
Sorry, I don’t have a super convincing answer for that. If you want more details about that, I can ask the responsible team :D