# Reverting to earlier CUDA - version report stubborn

**URL:** <https://discourse.julialang.org/t/reverting-to-earlier-cuda-version-report-stubborn/6247>\
**Category:** GPU\
**Created:** [October 4, 2017, 6:04pm UTC](https://discourse.julialang.org/t/reverting-to-earlier-cuda-version-report-stubborn/6247 "2017-10-04T18:04:06Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![Colin\_Beckingham](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/colin_beckingham/32/4878_2.png) [@Colin\_Beckingham](https://discourse.julialang.org/u/Colin_Beckingham)\
**Post date:** [October 4, 2017, 6:04pm UTC](https://discourse.julialang.org/t/reverting-to-earlier-cuda-version-report-stubborn/6247/1 "2017-10-04T18:04:06Z")

</div>

I’m trying to revert versions of CUDA from 9 to 7. The removal of 9 and install of 7 seems to have gone ok but CUDAdrv.version() is still reporting v"9.0.0".  
I have Pkg.rm() twice each for CUDAdrv and CUDAnative and cleaned out any .julia/.cache and .julia/v.0.6/CUDA\*, followed by Pkg.add() again, but I’m missing something since CUDAdrv.version is still echoing cuda 9. I’m guessing there is something else to be cleaned out?

---

<div class="post-metadata">

**Author:** ![maleadt](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/maleadt/32/10097_2.png) [@maleadt](https://discourse.julialang.org/u/maleadt)\
**Post date:** [October 4, 2017, 6:18pm UTC](https://discourse.julialang.org/t/reverting-to-earlier-cuda-version-report-stubborn/6247/2 "2017-10-04T18:18:33Z")

</div>

`CUDAdrv.version()` is querying `libcuda` for the CUDA version, which returns the CUDA compatibility level of the kernel module. This is mostly independent from the CUDA toolkit installation (providing, eg. `libcudart.so`, and also `nvcc` etc).  
You probably still have the more recent kernel module installed or loaded.

---

<div class="post-metadata">

**Author:** ![Colin\_Beckingham](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/colin_beckingham/32/4878_2.png) [@Colin\_Beckingham](https://discourse.julialang.org/u/Colin_Beckingham)\
**Post date:** [October 5, 2017, 9:45am UTC](https://discourse.julialang.org/t/reverting-to-earlier-cuda-version-report-stubborn/6247/3 "2017-10-05T09:45:10Z")

</div>

Right. So I made a valiant attempt to go back to an earlier version using available openSUSE repos but ultimately failed since the OS refused to insert the earlier module. Rather than struggle with that issue I returned to the more advanced driver and I find I can compile a matrix multiplication from the samples using nvcc so I think for now I will stick with the odd mix of driver 9 and cuda 7. No doubt there are more surprises to come, but I can experiment until I have a better card.

---

<div class="post-metadata">

**Author:** ![maleadt](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/maleadt/32/10097_2.png) [@maleadt](https://discourse.julialang.org/u/maleadt)\
**Post date:** [October 5, 2017, 9:57am UTC](https://discourse.julialang.org/t/reverting-to-earlier-cuda-version-report-stubborn/6247/4 "2017-10-05T09:57:53Z")

</div>

> [@Colin\_Beckingham](#):
>
> No doubt there are more surprises to come, but I can experiment until I have a better card.

One of those surprises is that CUDAnative.jl won’t work anymore. Some details: NVIDIA ships their PTX-\>SASS compiler both as part of the driver (where you can load a module with PTX code, as we do with CUDAnative.jl using CUDAdrv.jl), and as a part of `nvcc` to generate fat binaries early-on. That’s why you can use your CUDA 8 `nvcc` to generate SASS for `sm_21`, but CUDAnative.jl won’t be able to compile the `sm_21` PTX to SASS (or, I hope, will refuse to do so because it knows it’ll fail).