Is installing CUDA for host PC through SDK Manager required

Is there anything that requires me to use the SDK manager to install CUDA on my host laptop? My laptop is running Ubuntu 20.04, which the SDK manager does not currently support. I would prefer to stay on 20.04 rather than downgrade to 18.04 as the kernel update fixed some bugs with my laptop.

20.04 is not officially supported yet, but you can sometimes succeed at “lying” to SDKM and getting it to work anyway. See:

However, I have to caution you that although the above works for the safe flashing of the Jetson, that this is not necessarily safe for GPU driver install on the host PC. My guess is only a guess, but it is unlikely the above would be any threat to the host PC anyway since packages themselves know of dependencies. If the above were to fail for installing to the host PC, then it is very likely going to be nothing more than refusing to install due to dependencies which could not be resolved.

If your host PC already has the NVIDIA driver installed, then there is nothing “special” about installing CUDA on it. Jetsons require some specific drivers for the integrated GPU, but the PC discrete GPU drivers are nothing special. The Nsight edition of Eclipse might require installing from SDKM, but you could uncheck anything else and just install the development tools.

If it were me personally I’d start by finding out if the PC’s GPU driver is in place. You’d hope “nouveau” does not show up here:

lsmod | egrep -i nouveau
# If you don't have "`glxinfo`", then "`sudo apt-get install mesa-utils`":
glxinfo | egrep -i '(nvidia|version|nouveau)'

If the above works without finding nouveau, then your GPU driver is in place on the PC. You could see if you already have the NVIDIA repository in place:
dpkg -l | egrep 'cuda-repo'

If this is in place, then you can install CUDA using “apt-get” instead of SDKM (and you wouldn’t have to “lie” about being 20.04, you’d just run your host PC normally), but aside from the GPU driver itself, I think SDKM will be easier due to having all of the right packages for CUDA 10.2. Example of using apt-get to install one of the packages:
sudo apt-get install cuda-driver-dev-10-2

Just to emphasize, I think there isn’t much risk, but the risk which does exist would be during GPU driver install to the host PC, and not the CUDA install. CUDA is just a regular package depending on the GPU driver, while the GPU driver is part of the running GUI.

@linuxdev Thank you very much. I have figured some of that portion out. What I am really curious about is whether SDKM adds anything additional that I cannot get through normal install via apt or the .deb files for CUDA on this website.

You cannot use the separately published CUDA packages. These are not for iGPUs. However, as long as you’ve added the NVIDIA repository, you can use apt-get to install CUDA. I think pretty much everything is available so long as you have the repository (although less conveniently) for the Jetson.

There are some host PC side packages which I have no idea if they are available on the PC without SDKM. For example, the examples (I think I here echoes…:P). Or perhaps the Nsight edition of Eclipse which works with remote arm64 differs. I’ve never really tried to get that content separately for the host PC (aside from GPU driver and CUDA), so I couldn’t tell you if there is something available only via SDKM on the host PC.

What do you mean by this? Do you mean that the CUDA packages installed through apt (as opposed to SDKM), cannot be used for testing and developing for the Jetson?

As for the examples and NSight Eclipse, that makes some sense. Thank you very much.

The apt mechanism can be used. So can SDKM downloads. These are tied to repositories specific to Jetsons.

However, there are NVIDIA web site download URLs for CUDA which a desktop PC user might find of interest. Those downloads which are not specifically for the Jetson cannot be used.

The GPU of a Jetson is integrated (iGPU), and connects directly to the memory controller. Most of the non-Jetson drivers and software depend on a GPU which is discrete (dGPU) and on the PCI bus. Much of the software which is not specific to a Jetson depends on PCI query functions to know where the GPU is. All of those drivers and software would fail with an iGPU as there is no way for a PCI query to have knowledge of the iGPU.

There are some drivers on NVIDIA download URLs which are for arm64/aarch64, but those too won’t work on a Jetson. The correct architecture is necessary, but even arm64 won’t work with an iGPU when the software depends on a dGPU.

@linuxdev That makes sense on the iGPU part.

To make sure I understand: The SDKM is really just adding an APT repository to my computer to donwload the CUDA tools that will be used on the desktop PC. Is that what you are saying?

Yes, SDKM is just a tool to find the right APT repository for your hardware. In the case of a Jetson there are very specific requirements which are in conflict with the PC version of GPU drivers and tools. The PC version is generally available in other ways (such as web site download in either “.deb” format, or another format which does not care about any package tools), but is incompatible with a Jetson (only arm64 iGPU drivers and tools can be used). Stick to SDKM as much as you can and you’ll know you are getting compatible versions without reading all of the documents.

Once the repository is set up, then regardless of whether you are speaking of a Jetson or a PC, then the APT tool should find the correct version. Most of the time it is easier to just use SDKM since one of its functions is to set up the correct repository (then you don’t have to manually download things and make sure you have the right version).

An example of something you can do with a host PC for CUDA, but cannot do with a Jetson, is to install more than one CUDA release. Normally if you were to install a second release on a PC you would have to worry about the old release being removed during the “upgrade” of CUDA. However, if you were to manually download the “.run” file version of the install software, then the package database would not see this and would leave both versions installed. The “.run” version is just a bash scripted file copy which does not use APT. When I used Fedora on my host I used the “.run” version since package versions did not work with that Fedora release. I had perhaps three versions of CUDA. You could do something similar on an Ubuntu host and have available 3 or 4 versions of CUDA.