I recently upgraded from msvc 2005 to 2015.
I have compiled my code with revision 4.2 of cuda toolkit for year. I'm now learning the hard way that there is no forward compatibility betweend visual and cuda, however Google shows that some trick exists to force the compilation (messing up with .props and .targets files).
From what I understand, cuda 4.2 is a no-go. nvcc seems to have an hardcoded check on the msvc revision.
My questions are:
is there a way to compile with cuda 5.x or 6.x?
worst case scenario is that I have to update to cuda 7.5, does it even work?
Thanks for your help.
Update: CUDA 8RC supports VS2015 Update 1 officially (not update 2).
For CUDA toolkits prior to CUDA 8RC, none officially list MSVC 2015 as a supported environment, including CUDA 7.5 (the most recent production toolkit, at the moment).
For recent CUDA toolkits, the official support matrix is given in the windows getting started guide or installation guide which you would have to review for each toolkit version, to find the support for that version.
Since support for a VS version means that the CUDA toolkit will make changes to the VS environment (e.g. installing CUDA build customization rules, what you refer to as "messing with .props and .targets") and also provide appropriate project definition files for each of the cuda sample projects, if you wanted to work around this, you would have to duplicate those functions yourself. There might be non-standard ways to do this, but you would be operating in unsupported territory.
CUDA 8 is the first version to support MSVC 2015, including the community edition (with the exception of cross compiling). At the time of writing this, CUDA 8 is available as a release candidate if you are signed up for the NVIDIA "Accelerated Computing Developer Program".
Related
I read on the CUDA toolkit documentation (11.3.0) that "Deployment and execution of CUDA applications on x86_32 is still supported, but is limited to use with GeForce GPUs."
This looks in conflict with the fact that I was able to run a 32-bit app on my Tesla T4. (I verified that the code was actually running on the GPU and the app was 32-bit).
Have I misinterpreted the documentation? Why am I able to run 32-bit apps on a Tesla GPU?
(I'm running Visual studio 2017 on Windows 10)
It's a question of what is supported.
Other things may work, or they may not.
I've recently downloaded and successfully compiled a small CUDA dll using NVCC (10.2). Unfortunately because I have the most recent toolkit version the distribution requires the most recent driver version too. So I was wondering if there was an NVCC flag that enabled me to effectively target an earlier driver version and then distribute with an older runtime.
Currently, I have to check the run time and driver versions in order to check for compatibility.
The CUDA toolchain, runtime API and its support libraries are versioned and if you build runtime API code with a given toolkit version, you must ship the resulting code with all the libraries from that version or have users install that toolkit version (aka the tensorflow problem).
If you use the driver API, then you can potentially target a lower compute capability with PTX which might be backward compatible with a different driver. I say might because there are still PTX version support limits which can stop it from working correctly.
If you want to support older CUDA versions, just install the older toolchain and build using that toolkit.
Not a duplicate of this question
When downloading NVIDIA GPU drivers, I've also been asked for some time which CUDA toolkit I prefer.
Now, what does this choice imply when downloading a driver?
As far as I know, different CUDA toolkits have different minimum drivers supporting them (also stated in the release notes), but what does this choice at the driver download page imply?
Generally speaking, there is a backwards compatibility strategy for drivers with respect to CUDA toolkits. For example, the latest driver should work with any older CUDA toolkit. An older driver may not work with a newer CUDA toolkit.
That is a general statement of compatibility. You can find it expressed here (e.g. table 1) also.
However, each CUDA toolkit ships with a particular driver branch. For example CUDA 10.1 ships with a 418.xx driver branch (this corresponds to the version of the GPU driver that is bundled with the CUDA toolkit installer).
So even though a 430.xx driver is compatible with and should work with CUDA 10.1, that isn't actually the driver branch that ships with CUDA 10.1
The dropdown allows you to select a driver that is in the same branch as the driver that particular CUDA toolkit was shipped with and has the highest test coverage with.
Since newer drivers ship with the CUDA runtime (I can choose 9.1 or 9.2 in the drivers download page) my question is: should my library (which uses a CUDA kernel internally) be shipped with -lcudart_static?
I had issues launching kernels compiled with 9.2 on systems which used 9.1 CUDA drivers. What's the most 'compatible' way of ensuring my library will run everywhere a recent CUDA driver is installed? (I'm already compiling for a virtual architecture)
Since newer drivers ship with the CUDA runtime (I can choose 9.1 or 9.2 in the drivers download page)
No, that's incorrect. That choice in the drivers download page is related to the fact that each CUDA version has a minimum required driver version associated with it. It does not mean that the driver ships with the CUDA runtime (stated another way, the driver does not install libcudart.so on linux and never has - with some careful experimentation on a clean install, you can prove this to yourself.)
Some additional comments:
-lcudart_static is actually the default for current/recent versions of nvcc. You can discover this by reading the nvcc manual. Therefore, by default, your executable, when compiled/built with nvcc should already be statically linked to the CUDA runtime library corresponding to the version of nvcc that you are using for compilation. The reason you might need to specify this or something like this is if you are building an application with e.g. the gnu toolchain (on linux) rather than nvcc.
The purpose of static linking to the CUDA runtime library is, as you surmise, so that an application can be built in such a way that it does not need an installation of the CUDA toolkit to run properly. It only needs a machine with a proper GPU driver install.
The most compatible way to ensure that an application will run on a range of machines with a range of GPU driver installs is to compile your application using the oldest CUDA toolkit required to meet the needs of the earliest GPU driver in the range you intend to cover. Again, you can refer to the table here.
Running a simple application on nvidia Visual Profiler shows the error:
Encountered invalid option : --openacc-profiling
======== Use "nvprof --help" to get more information.
Any gpu applicatiion I try to profile gets the same error.
I tried to uncheck the option "Enable OpenACC profiling" and got the same error.
Versions:
nvprof --version
nvprof: NVIDIA (R) Cuda command line profiler
Copyright (c) 2013 - 2014 NVIDIA Corporation
Release version 6.5.14 (21)
And
NVIDIA Visual Profiler
Version: 6.5
It appears (based on comments above) that the issue here was a mixed configuration - a CUDA 8 version of nvvp (the visual profiler) calling a CUDA 6.5 version of nvprof.
The visual profiler performs some of its work by calling nvprof to do low-level profiling. As a result, it is passing command-line switches to nvprof, and so nvprof is expected to match, version-wise, the version of nvvp that is being used. If that is not the case, problems like this can occur.
The solution is to have a consistent install. It should be possible to have both CUDA 6.5 and CUDA 8 installed on the same machine, but it's necessary for the PATH and LD_LIBRARY_PATH variables to be set in such a way that the CUDA 8 version of nvvp will find/invoke the CUDA 8 version of nvprof, for example. Generally, the instructions contained in the linux install guide for setting of these variables should be sufficient, but care should be taken, for example, to be sure that there is not some previous version of nvprof that will be found due to the PATH setting when using CUDA 8. It's not possible cover all the possible ways in which this may happen, so some rudimentary linux administration skills will be necessary to ensure such a configuration is internally consistent.
Otherwise, if these skills don't exist, the linux install instructions may provide the best solution - remove all previous versions of CUDA when installing a new version. That is another possible approach which, if done correctly, should absolutely prevent a problem such as this from occurring.