[CMake] CMake CUDA 3.8+/9 support as a first class language with out Visual Studio Support... err what?

[Brian J. Davis]

>
> My responses are inline.
As are mine.
> On Sat, Jul 29, 2017 at 7:00 PM, Brian J. Davis <bitminer at gmail.com <http://public.kitware.com/mailman/listinfo/cmake>> wrote:
> >/@Robert />//>/I created a fresh simple cmake project in 3.9. This appeared to find 
> CUDA />/8.0 successfully so it may have something do with my other project 
> settings />/that I am trying to get to work with 3.9, VS13, CUDA 7.5/8.0. />//>/Using: />//>/message( CUDACXX = ${CUDACXX}) />/message( CMAKE_CUDA_COMPILER = ${CMAKE_CUDA_COMPILER}) />//>//>/Reports />//>/CUDACXX= />/CMAKE_CUDA_COMPILER=C:/Program Files/NVIDIA GPU Computing />/Toolkit/CUDA/v8.0/bin/nvcc.exe />/Configuring done />/Generating done />//>/The question was at setting the CUDA version say 7.5 or 8.0. />//>/I search doc for CUDACXX and CMAKE_CUDA_COMPILER with no hits. Is this />/stuff documented anywhere. /
> Unfortunately the environment variables are not documented anywhere
> and this is a known issue
> that I hope to have fixed in CMake 3.10.
>
> The CMAKE_CUDA_COMPILER falls under the the CMAKE_<LANG>_COMPILER documentation
> now with the new CUDA support (
> https://cmake.org/cmake/help/v3.8/variable/CMAKE_LANG_COMPILER.html  ).
>

So let me get this straight.  Changes appear to begin in 3.7 / 3.8 with 
VS started to be supported in 3.9, but the only way us schleps on the 
internet know how to use it is to wait until 3.10. Wow... seriously.  
And well I am not holding out *hope*.

> >//>/Do I really need to say set: />//>/CMAKE_CUDA_COMPILER=C:/Program Files/NVIDIA GPU Computing />/Toolkit/CUDA/v7.5/bin/nvcc.exe />//>/To get CMake to compile for 7.5? I mean: />//>/find_package(CUDA 7.5) />//>/you could agree is/was much simpler. I am becoming frustrated and 
> confused />/by these changes. /
> It might be possible in the future to provide other hint controls to
> tell CMake which
> version of CUDA you would like to use before the project /
> enable_language call. This
> would be something that is best addressed on the cmake developer list or as
> a gitlab issue (https://gitlab.kitware.com/cmake/cmake/issues  )
In the future with the robots... anything is possible... provided they 
are not out to kill us.

Why would I bother to seemingly point out the obvious @developers list 
or issue tracker.  Hopefully anyone reading this can tell I am a bit 
frustrated at this point.  Huh here's how that would go:

Me: Hey Devs you forgot to document how to use the tool.  Do you expect 
anyone but you to know how to use it?

Devs: Huh yea we know...  Ugh ... errr... Huhhh were getting to that.

Me: sigh...
> >//>/I can't even get a simple CUDA app to run using FindCUDA (will 
> compile) or />/compile using v3.9 and new project( CXX CUDA). />//>/Your example at: />//>/https://cmake.org/cmake/help/latest/manual/cmake-compile-features.7.html />//>//>/Used: />//>/add_executable(CudaConsumeCompileFeatures main.cu) />//>/Is is required now that main.cpp be a .cu file now? I wouldn't think so, />/but I am so lost in the woods on this that I am not sure of anything />/anymore. /
> So with the new CUDA support you can mix C/C++/CUDA sources together
> inside a single library or executable. This example was only using CUDA
> in the executable to reduce the complexity of the test.
>
Only if I can get it to work.  Which I can't ... and would not know how 
anyway as well it is not documented... so why waste my time.
> >//>/How do I get all the toolkit and sdk include and lib dir variables now 
> as />/FindCUDA provided? /
> The toolkit include directory can be found by querying
> CMAKE_CUDA_TOOLKIT_INCLUDE_DIRECTORIES
> As far as CUDA SDK libraries those can simply used with target_link_libraries
> as the SDK library path is considered to be an implicit link directory, and will
> always be on the link line. This is actually the same for the CUDA sdk include
> directory ( it will be placed on the include line when building ).
>
> >//>/I am so curfuffled by these changes. /
> These changes are needed to allow targets using CUDA to properly work with
> 'Modern' CMake (https://cmake.org/cmake/help/v3.8/manual/cmake-buildsystem.7.html#build-specification-and-usage-requirements).
> Without these changes usage requirements and CUDA would never work together.
>
I assume the term *work* is used loosely.... VERY loosely.  I hate to 
point out the obvious, but I can't get it to work now and have not clue 
or seemingly hope on figuring it out other than to check out CMake and 
roll my own version after reading impl in order to figure out how it 
does and how to get it to work.  By that time I'd rather revert to 
writing VS xml project file by hand.

Regarding 960M and CUDA  7.5/7.5, 8.0/7.5, and 7.7/9.0

Answer is:

960M was likely released post CUDA  7.5 driver and possibly post 8.0.  
Seems that architecture differences do not allow old drivers to work on 
newer arch cards.   Once 9.0 driver was released... 7.5 run time worked 
with 9.0 driver, but for some reason not 8.0. Seems CUDA and Nvidia 
Runtime/Drivers have a dirty little secret much like Java and the runtimes.

At this point I cannot get CMake 3.2 or 3.9 to work with CUDA 7.5/9.0, 
VS 13, on Win10Pro/Enterprise.  And from the state of doc it seems not 
worth my effort to even try anymore.






-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20170731/dad13741/attachment.html>