From Kepler to Maxwell, do I need CUDA 6.5 ?

Currently using CUDA 6.0 and just received a couple GTX 980s which I want to benchmark.

Is there any specific reason to upgrade my current version of CUDA? Will I be able to generate 5.2 code using CUDA 6.0?

Windows 7 64 bit, SP1


Sorry, I cannot speak to the code generation issue due to lack of experience with Maxwell. As for specific benefits of moving to CUDA 6.5, Mark Harris listed a whole bunch in this blog post:

You probably need the latest driver package to operate the GTX 980 as these are very recent devices.

You cannot compile to a 5.2 specific target without the latest CUDA 6.5 toolkit with the update for cc5.2:

So, no, you cannot generate cc5.2 code with CUDA 6.0 (i.e. with nvcc).

If you want to use any given GPU, you must use a driver that is compatible with that GPU. Whatever drivers are compatible with GTX980/970 will be compatible with any currently shipping CUDA toolkit.

If you use an older toolkit, and you want to run on GTX980/970, you will need to be sure to compile to a target that includes PTX. (e.g. nvcc -arch=sm_35 … ) Such code will be JIT-compiled by your GTX980/970 compatible driver to run on your cc5.2 GPUs.

So no, you don’t have to move off of CUDA 6.0 in order to use the GTX980/970. You will need to move forward to a compatible driver, and if you want to compile to a cc5.2 target specifically, you will need the latest CUDA 6.5 update.

I did upgrade the driver already to the latest, and know see I will need to upgrade CUDA to 6.5 as well.


I like the fact that the CUDA 6.5 installer left CUDA 6.0 around so I can still link against it.

There definitely is a modest performance difference between the two, as some basic ‘building block’ applications I use somehow have a consistent 10% difference in running when built with CUDA 6.0 vs 6.5 ( using Kepler generation).

Hello gents,

I’m a bit confused, that’s why I would like to reopen this topic.
I’m using Cuda toolkit 6.0 compiling my kernels using the following parameters:
-gencode arch=compute_30,code=sm_30
I was using GTX 780 till know, and everything worked like charm.

I got now GTX 970 on my desk trying to run some performance tests. At first it takes ages to start, than it happens that my kernels are crashing spontaneously.
However, I’m using driver version 6.5.

The “maxwell compatibility guide” confirms txbobs statement. Furthermore, the guide says:
“When using CUDA Toolkit 6.x, to ensure that nvcc will generate cubin files for all recent GPU architectures as well as a PTX version…”
Does this mean that my problem will be solved by simply adding the following parameters?
-gencode arch=compute_52,code=sm_52

Did I’m missing something? Should I change to Cuda 6.5?


The ability to use CUDA 6.0 (which knows nothing about cc5.x) compiled binaries on a cc5.x device depends on a driver JIT-compile from PTX.

-gencode arch=compute_30,code=sm_30

does not generate any PTX in your compiled binary (i.e. executable). Therefore, binaries generated that way likely won’t run (correctly) on a cc5.x device.

you will not be able to specify:

-gencode arch=compute_52,code=sm_52

on a CUDA 6.0 setup, because it knows nothing about cc5.x

You can insert PTX into your compiled binary with:

-gencode arch=compute_30,code=compute_30 -gencode arch=compute_30,code=sm_30

which should allow the forward JIT-compile process to be successful on your GTX970 (assuming you have a GTX970 compatible driver loaded.)

note that in lieu of the above switches,


is a convenient shorthand, which is why I referenced it in my first comment in this thread.

This is admittedly an intricate topic, but it’s all spelled out in the nvcc manual:

(Or you could do a complete load of CUDA 6.5, not just the driver, in which case you can specify cc5.x architecture when you are compiling).

In my humble opinion the answer is “yes”. CUDA 6.5 provides an assortment of improvements as pointed out at the link to NVIDIA’s developer blog I gave in my post above. It has native support for your Maxwell-based GPU.

Personally I have not encountered any issue after switching to CUDA 6.5 on 64-bit Windows 7. As for issues reported on the internet, I have seen multiple reports of trouble with sm_1x devices when using OpenCL with the latest driver packages (obviously OpenCL != CUDA), and some versioning conflict between CUDA toolkit and the driver package on Mac OS X (unclear whether this latter issue has been resolved or not).

From my viewpoint the risks of moving to CUDA 6.5 seem minimal, and the benefits tangible.

Many tnx to both of you, for the enlightening answers.