I am trying to include tiny-cuda-nn to my optix renderer. Adding it as a static library through CMAKE creates the make files however, on compile MSVC throws error MSB3721 while compiling the target .cu files where all the headers from the cuda folder in the optix framework throws import error. The relevant log is given below :
Your NVCC command line tries to compile shader.cu to object code. (See your --compile and -o render.dir\Debug\shaders.obj options.)
If that shaders.cu file contains OptiX device code, that is the wrong NVCC command line.
The cuda/LocalGeometry.h header is from the OptiX SDK examples and you seem to be missing the proper include directory.
You have -I"C:\ProgramData\NVIDIA Corporation\OptiX SDK 8.0.0\include" which contains all headers for the OptiX API. That is usually all you need when writing your own applications.
The OptiX SDK examples are separate and their headers are inside C:\ProgramData\NVIDIA Corporation\OptiX SDK 8.0.0\SDK\cuda then.
My application is stand alone, I have just used certain files from the framework examples.
I am trying to do some network inferencing in shader code. Currently, I have implemented my own network inference module in cuda code, and it is my understanding that the same can be done with tiny-cuda-nn which is compiled in cuda which will make maintaining my code a lot easier and I dont have to implement everything, every time I need to use something new with neural networks.
I tried to do the same with one of the examples and I do not understand why simply compiling a static library in cuda breaks optix. And I dont know where it is breaking because my code works without any problems when not including the library.
Again, if your shaders.cu compilation is for OptiX device code, the NVCC command line options for that are incorrect.
You must not use --compile for any OptiX shader code. You must use either --ptx or --optix-ir.
Means somehow you broke your build envirionment.
CMake bugs aside, if you’re trying to use the CMake CUDA LANGUAGE feature, that will try to compile ALL *.cu files to object code.
You must put OptiX device code *.cu files into a CMake Object Library to exclude them from the default CUDA build process.
Please follow the links in the posts I provided which explain that with an example CMakeLists.txt.
Leads to here: https://forums.developer.nvidia.com/t/why-am-i-getting-optix-dir-notfound/279085/4
For clarification of the initial post, you have a MSVS solution which contains a project which implements an application using OptiX and that is working fine standalone, but when you add tiny-cuda-nn which is using the CMake LANGUAGE CUDA feature as another project to that same solution, then the OptiX project fails to compile the *.cu files?
That is a bug in CMake!
If you look inside the *.vcxproj files of the working and non-working versions of your OptiX project, the OptiX device code *.cu files were flagged as None for the CUDA compilation (because they are using custom build rules) where the broken project contains CudaCompile for these OptiX *.cu files and that is resulting in the incorrect --compile -o name.obj NVCC command line options.
Means adding a project which is using CMake LANGUAGE CUDA feature to a solution affects the compilation rules for other projects inside the solution and that is clearly a CMake defect.
I don’t know if that has been fixed inside the newest available CMake version. If not, then a workaround would be to either keep the projects in separate solutions (in case the tiny-cuda-nn generates a library you can link to), or you convert your OptiX project CMakeLists.txt to one which also uses the CMake native LANGUAGE CUDA feature as described above where the OptiX device code *.cu files are handled in a CMake Object Library inside the project. (All that Object Library does is using explicit NVCC command line options for the given *.cu files.)
Ahh I see, that makes a lot of sense. I think the problem is with CMake. I have found an alternative solution by including tiny-cuda-nn as a static library built outside of my project environment. However, tiny-cuda-nn has a bunch of STL dependencies, and I am unsure how to best deal with it. Any help would be appreciated.
Yes, that would be a problem when you’re using STL inside the API of the library. That’s why APIs usually using C-interfaces to overcome that dependency from the different runtime versions and allocators.
If you keep these in separate solutions, then you would need to to make sure, you’re always keeping the build environments in perfect sync.
If you still want to add the tiny-cuda-nn project to your solution, then that would either need to use a CMake version with this problem fixed, or you would need to convert your OptiX application’s CMakeLists.txt to a project which also uses the CMake LANGUAGE CUDA feature and isolate the build of the OptiX *.cu files to a CMake “Object Library” inside that.
Again, follow the links I posted for an example CMakeLists.txt doing exactly that. It’s not too complicated.
Or don’t use CMake but build up the solution and projects inside it manually inside the MSVS IDE and set the CUDA Toolkit Visual Studio Integration options per *.cu as needed. That is tedious and not portable to other OSes though.