docs: Update the CudaPackage (build system) description

[tldahlgren]

This PR expands on the CudaPackage description by:

• elaborating on the variants;
• adding relevant URLs/links;
• adding a discussion of conflicts with examples;
• adding a description of the cuda_flags method; and
• correcting and expanding on the Usage section.

[ax3l]

Thank you for improving the docs of this! ✨

[adamjstewart]

@Rombur would be a good person to review too

[adamjstewart]

Should we be using cuda_flags here? The base class has a static method for this.

[tldahlgren]

The base class' cuda_flags returns a list of '--generate-code arch=compute_{0},code=sm_{0} --generate-code arch=compute_{0},code=compute_{0}'.format(s) for s in the list of arch's passed it. Is that equivalent when the flags are specified this way?

[tldahlgren]

Note the dealii package has a comment that it has compiler errors when using the values returned from cuda_flags (see https://github.com/spack/spack/blob/develop/var/spack/repos/builtin/packages/dealii/package.py).

[tldahlgren]

The dihydrogen package only uses -arch=sm_60 (for its CMAKE_CUDA_FLAGS macro) when there is a single architecture with the value auto.

[tldahlgren]

@Rombur @adamjstewart Are these changes sufficient under the circumstances?

[adamjstewart]

Docs look good to me. I know very little about CUDA, I just use it for PyTorch. One thing I might suggest adding is an example where you determine the cuda_arch for your GPU and set it globally in packages.yaml.

As for the CudaPackage base class, I've been thinking this for a while now, but doesn't it make more sense to move the compiler-/platform-specific conflicts to the cuda package? That way they will always be used even if a package doesn't inherit from CudaPackage.

[tldahlgren]

Docs look good to me. I know very little about CUDA, I just use it for PyTorch. One thing I might suggest adding is an example where you determine the cuda_arch for your GPU and set it globally in packages.yaml.

As I mentioned in the new ROCmPackage doc, I'm hesitant to add something like this to here since there is a risk it could cause issues in some environments. In that case, I referred to comments in the package (with a link to the package).

Unfortunately, the CudaPackage doesn't have comments with that advice.

As for the CudaPackage base class, I've been thinking this for a while now, but doesn't it make more sense to move the compiler-/platform-specific conflicts to the cuda package? That way they will always be used even if a package doesn't inherit from CudaPackage.

I'm not sure I follow the issue here. What do you mean by the cuda package? The cuda.py (build system) defines CudaPackage.

[adamjstewart]

What do you mean by the cuda package?

var/spack/repos/builtin/packages/cuda/package.py

CudaPackage is just a set of common mixins for CUDA things. But not every package that uses CUDA uses CudaPackage or needs the variants. If we move this stuff to the package recipe, it will always be used for every package.

[tldahlgren]

What do you mean by the cuda package?

var/spack/repos/builtin/packages/cuda/package.py

Ah! Guess my head is buried too much in the core.

CudaPackage is just a set of common mixins for CUDA things. But not every package that uses CUDA uses CudaPackage or needs the variants. If we move this stuff to the package recipe, it will always be used for every package.

Thanks for the clarification.

[tldahlgren]

@adamjstewart Since Rombur approved this PR, is the content sufficient for now under the assumption it can be updated, as needed, should any of the changes you mentioned be performed?

[tldahlgren]

Thanks @adamjstewart