[cmake-developers] CUDA as a compiler instead FindCUDA?
Adam Strzelecki
ono at java.pl
Sat Jan 17 10:13:28 EST 2015
> 1. Support for dependency scanning. If I change a header included by file.cu I want file.cu to be recompiled. This is easy for makefiles, hard for anything else.
.cu is superset of C++ so it should be pretty easy to get dependency scanning working same as for regular .cpp/.h files using CMake facilities.
> 2. In the past there have been bugs with nvcc, such as leaving a partially written output file during generation that failed, that FindCUDA has worked around.
I don't see why we should care about that? If they still exist isn't it what NVIDIA partner bug report site is for?
> 3. Host flags generally need to be propagated to the CUDA flags (I'll admit that this support in FindCUDA isn't perfect).
You mean user-defined preprocessor definitions or compiler flags? Host compiler flags are picked up by nvcc from host compiler itself. Aside of that, CMake will insert -D definitions as well to any extra compiler.
So you may only want to wrap CMAKE_CXX_FLAGS into CMAKE_CUDACXX_FLAGS using -Xcompiler which can be tricky, but I believe we can workaround that somehow.
> 4. How do you support other targets besides cubin (obj), such as PTX?
For what purpose? Debugging?
> 5. How would separable compilation work? Especially since you can't easily replace the linker.
Correct me if I am wrong, but we will still use platform linker.
> 6. If you support PTX, can you use the output as input for other custom commands (I like to encode the PTX into strings compiled into C++ files using bin2c from CUDA).
Again can you please elaborate more why would you like to handle PTX yourself if CUDA does it for you, i.e.:
nvcc -arch sm_30 -> makes .o contain native device code
nvcc -arch compute_30 -> makes .o contain ptx code compiled later by the driver itself
This sounds like some custom behavior.
--Adam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20150117/a5653c14/attachment.html>
More information about the cmake-developers
mailing list