[cmake-developers] CUDA as a compiler instead FindCUDA?

[James Bigler]

On Sat, Jan 17, 2015 at 8:13 AM, Adam Strzelecki <ono at java.pl> wrote:

> 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.
>
>
CMake doesn't support dependency scanning for Visual Studio.

> 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?
>
>
It may not be my fault, but it's my problem.  If I can correct for problems
and help others not have to deal with those same problems, I'm going to do
that.  We all have to deal with imperfect tools, and not all of us can wait
for 1-2 years for bugs to be fixed.


> 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?
>
>
CUDA supports two usage APIs.  The runtime API that is used when you
compile your code to object files, and the driver API that compiles to PTX
or CUBIN and then loads that code into the driver directly.  FindCUDA
supports both.

> 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.
>
>
You can't use the platform linker for separable compilation unless you also
produce intermediate linkage files.  In order to produce intermediate
linkage files you need all the object files compiled with separable linking
to be run through another tool that produces this intermedate link file
that will also need to be linked into the executable module.

> 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.
>

See my comment above regarding the driver versus runtime CUDA API.  Yes it
is different behavior, but I was able to accommodate both compilation
models with the same tool.  I would love for what you propose to work for
both compilation modes, so if it is possible I would like to design it in.
Otherwise it can't be a complete replacement for FindCUDA.

James
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20150203/b4f6e07f/attachment.html>