Skip to content

Latest commit

 

History

History
101 lines (77 loc) · 3.61 KB

README.md

File metadata and controls

101 lines (77 loc) · 3.61 KB
Raw

Taken from comment ( #1 (comment) ) summarizing the intended usage of this package.

Summary

In-scope for cuda-version

Questions/demands listed below are addressed:

  • Which CUDA versions a package would support?
  • How a particular CUDA library is tied to a specific CUDA version?
  • How to pull in dependencies that align with a particular CUDA Toolkit release?
  • What CUDA compiler version a package was built with?
  • The ability to get a specific shipped full toolkit at a given version, i.e. 12.0 or 12.1.
  • The ability to get specific packages at a given toolkit version, i.e. 12.0 or 12.1.
  • Support for CUDA minor version compatibility
  • Not to allow solving to an incompatible environment

Out-of-scope for cuda-version

What CUDA driver version requirements might exist?

Driver requirement should be set up using the __cuda virtual package. For package maintainers/users who wish to overwrite (at their own risk), use the environment variable CONDA_OVERRIDE_CUDA.

How CUDA version tracking support ties into CUDA compatibility

  • For CUDA components from CTK, we currently disallow mix-n-match. This constraint is something we will revisit in the future.
  • For downstream packages depending on CUDA, use cuda-version >=X.0,<X+1 to allow minor version compatibility (see below).

The ability to get specific packages not tied to a given toolkit version, i.e. I may want to get Thrust 2.0.1

Unclear if possible under the "tight constraint" scheme that we plan to adopt.

Scheme

  • This feedstock (cuda-version):
    • Set up the driver requirement using __cuda for a given CTK major version X (see #1 (comment)).
  • nvcc compiler:
    • Pin a range of cuda-version, with the lower bound being the CTK version X.Y that it comes with
  • CTK components:
    • Pin at the exact cuda-version corresponding to the CTK version X.Y that they come with. Exceptions should be discussed on a case-by-case basis.
    • This applies to all flavors (lib, lib-dev and lib-static)
  • Downstream packages:
    • Depend on needed CTK components without version constraints, and set the version constraint on CUDA by depending only on cuda-version (plus __cuda, if applicable)
  • Downstream users:
    • Use cuda-version as the CTK version selector to set up a consistent environment

Examples

For maintainers of nvcc

Example: nvcc from the CTK version X.Y

build:
  run_exports:
    strong:
      - cuda-version >=X.Y,<X+1

### For maintainers of all CTK components

Example: cuBLAS from the CTK version X.Y
```yaml
- host:
  - cuda-version X.Y
- run:
  - {{ pin_compatible("cuda-version", max_pin="x.x") }}

Example: cuSOLVER depends on cuBLAS from the same CTK version X.Y

- host:
  - cuda-version X.Y
  - libcublas
- run:
  - {{ pin_compatible("cuda-version", max_pin="x.x") }}
  - {{ pin_compatible("libcublas", max_pin="x.x") }}

For maintainers of GPU packages depending on CUDA

Example: A package depends on cuBLAS and supports CUDA minor version compatibility

- run:
  - cuda-version >=X.0,<X+1
  - libcublas

For users of GPU packages

Example: Set up an environment compatible with CTK 12.1

conda install -c conda-forge cupy rmm "cuda-version=12.1"

Example: Set up an environment compatible with CTK 12 (of any minor version)

conda install -c conda-forge cupy rmm "cuda-version=12"

Example: Just set up a legit CUDA environment

conda install -c conda-forge cupy rmm