GPU access and nvcc

Two versions, and they are not the same

nvidia-smi reports what the driver sees. nvcc --version reports what the toolkit is. A driver newer than the toolkit is normal; a toolkit newer than the driver fails at the first CUDA call with cudaErrorInsufficientDriver. Write both numbers, plus the device name and compute capability, into the lab notes before you measure anything, because every number in this track is conditional on them.

Ask the device what it is

int n = 0;
cudaGetDeviceCount(&n);                 // zero devices is a valid answer
cudaDeviceProp p{};
cudaGetDeviceProperties(&p, 0);
printf("%s sm_%d%d %d SMs %zu B smem/block\n",
       p.name, p.major, p.minor, p.multiProcessorCount, p.sharedMemPerBlock);

A successful cudaGetDeviceCount with zero devices is the quiet failure: the runtime loaded, the driver answered, and there is nothing to run on. The deviceQuery sample prints the same fields plus the limits you will need later.

Compile for the part you have

nvcc -arch=sm_86 -O3 -o vadd vadd.cu

sm_XY comes from the major and minor numbers above. nvcc --list-gpu-arch prints the targets your toolkit still supports, which is a shorter list than the one in older notes. Compiling for several parts is a -gencode arch=compute_86,code=sm_86 line per target, and each one is a real build cost.

These names follow the CUDA 13.5 documentation set. Run nvcc --version and check the same page for your release before trusting an option spelling, since major toolkits change flags and drop sm_ targets.

Things that break

nvidia-smi lists the GPU, the build succeeds, and the device count is zero: an empty or wrong CUDA_VISIBLE_DEVICES, a container without the device nodes, or a WSL setup whose driver lives only on the Windows side. A zero count with cudaSuccess is never a compile problem. The other failure is a launch that reports no kernel image, which is an architecture mismatch rather than a missing GPU.