1.) No, if all OptiX device programs you need inside your OptiX pipeline are inside that single *.optixir file, then you don’t need an additional *.cu file and can load that as your only OptiX module, build all program group descriptions, and the pipeline from the programs inside that.
Of course if these include any headers you would need these as well to build your solution and to translate the *.cu files to their target module code.
2.) If you had carefully read all links I provided, my recommended solution is to NOT use sutil functions and its hardcoded absolute example build paths to locate your OptiX module files (*.optixir or *.ptx) at all.
Instead put them either directly next to your executable and read it with a relative path like "./optixTriangle_generated_optixTriangle.cu.optixir",
or in case you have multiple OptiX device code files and want them to be cleanly separated per application, put them into some folder relative to the executable and load them from there, something like "./my_app_name_modules/optixTriangle_generated_optixTriangle.cu.optixir" which then also doesn’t need that unique prefix "optixTriangle_generated_" to distinguish files per example anymore but can use shorter names
That way your program only uses relative paths to locate its files and would work anywhere when copied into a different folder location, which the OptiX SDK examples don’t(!) unless you set two environment variables which is a completely unnecessary restriction.
Loading *.optixir binary or *.ptx text files from disk can be done with the same function and I show that in my OptiX examples.
This builds the OptiX module paths depending on what target has been used inside the project (PTX or OptiX-IR):
https://github.com/NVIDIA/OptiX_Apps/blob/master/apps/GLTF_renderer/Application.cpp#L6357
This reads the module from disk: https://github.com/NVIDIA/OptiX_Apps/blob/master/apps/GLTF_renderer/Application.cpp#L6386
using this function: https://github.com/NVIDIA/OptiX_Apps/blob/master/apps/GLTF_renderer/Application.cpp#L3503
It’s that simple when not using sutil’s method with the hardcoded absolute example paths.
If you do not know how to build your CMakeLists.txt to generate the OptiX module files into the desired folder with the shorter names (e.g. optixTriangle.optixir), look into the CMake macro I’m using to generate custom build rules for the OptiX device code here:
https://github.com/NVIDIA/OptiX_Apps/blob/master/3rdparty/CMake/nvcuda_compile_module.cmake
Used here: https://github.com/NVIDIA/OptiX_Apps/blob/master/apps/GLTF_renderer/CMakeLists.txt#L159
In case you’re building a CUDA application using the CMake native LANGUAGE CUDA feature, the CMakeLists.txt should not use that macro to build custom build rules but a CMake Object Library to separate the OptiX device code from native CUDA kernel code because latter get translated and linked to native CUDA objects.
Explained here: https://forums.developer.nvidia.com/t/code-organization-and-cmake/290506/2
and here: https://forums.developer.nvidia.com/t/converting-vs-property-sheet-into-cmake-settings/287159/5