What is difference in pytorch and pytorch-cpu (and pytorch-gpu)

[hiroalchem]

Comment:

I wanted to install pytorch in the conda-forge channel and came across this repository while searching.
There is pytorch, pytorch-cpu and pytorch-gpu, what is the difference between them? Also, if I want to use pytorch with gpu in conda-forge, is my understanding correct that currently only linux (pytorch-gpu) can be installed?

[h-vetinari]

Pytorch-cpu & pytorch-gpu are the old names for compatibility with the packages that used to be published in the pytorch channel. It's necessary to distinguish the packaging with / without the CUDA bindings, but changing the package-name is not a great solution for this, because now other packages that want to depend on pytorch capabilities (resp. their packaging) need to mirror the whole logic about -cpu/-gpu. So the better way is to have a single pytorch package, which will be filled by the GPU version if conda can detect CUDA, or the cpu version otherwise.

in short:

conda install -c conda-forge pytorch

should work. In case of doubt, you can specify the buildstring directly to select the respective variant

conda install -c conda-forge pytorch=*=cpu*   # for cpu version
conda install -c conda-forge pytorch=*=cuda*  # for gpu version

[hiroalchem]

All right, I understand the situation.
However, I am in an environment with nvidia drivers installed, but
conda install -c conda-forge pytorch
command does not install the gpu version (and other cuda dependencies like cudatoolkit), am I wrong?

[h-vetinari]

It's possible that conda cannot find your drivers, though that would be unusual (you can check the output of conda info and see if there's anything about CUDA or the __cuda virtual package).

If you're on some exotic setup (e.g. HPC, or installed in weird location) and conda cannot find your CUDA drivers, you can override what conda detects as your CUDA version (or its absence) and do

CONDA_OVERRIDE_CUDA=11.2 conda install -c conda-forge pytorch

See here for details.

[hiroalchem]

>conda info

     active environment : base
    active env location : C:\Users\alche\anaconda3
            shell level : 1
       user config file : C:\Users\alche\.condarc
 populated config files :
          conda version : 22.9.0
    conda-build version : 3.22.0
         python version : 3.9.13.final.0
       virtual packages : __cuda=11.7=0
                          __win=0=0
                          __archspec=1=x86_64
       base environment : C:\Users\alche\anaconda3  (writable)
      conda av data dir : C:\Users\alche\anaconda3\etc\conda
  conda av metadata url : None
           channel URLs : https://repo.anaconda.com/pkgs/main/win-64
                          https://repo.anaconda.com/pkgs/main/noarch
                          https://repo.anaconda.com/pkgs/r/win-64
                          https://repo.anaconda.com/pkgs/r/noarch
                          https://repo.anaconda.com/pkgs/msys2/win-64
                          https://repo.anaconda.com/pkgs/msys2/noarch
          package cache : C:\Users\alche\anaconda3\pkgs
                          C:\Users\alche\.conda\pkgs
                          C:\Users\alche\AppData\Local\conda\conda\pkgs
       envs directories : C:\Users\alche\anaconda3\envs
                          C:\Users\alche\.conda\envs
                          C:\Users\alche\AppData\Local\conda\conda\envs
               platform : win-64
             user-agent : conda/22.9.0 requests/2.28.1 CPython/3.9.13 Windows/10 Windows/10.0.19045
          administrator : False
             netrc file : None
           offline mode : False

The driver seems to be found by conda, is that correct?
I would like to confirm that
conda install -c conda-forge pytorch
this alone will install the necessary cuda-related items as a library with dependencies?

[h-vetinari]

this alone will install the necessary cuda-related items as a library with dependencies?

It should work by default (you can check in the list of packages that are about to be downloaded if the buildstring after the pytorch version begins with cuda or cpu), but you can enforce that selection as I said above:

In case of doubt, you can specify the buildstring directly to select the respective variant

conda install -c conda-forge pytorch=*=cpu*   # for cpu version
conda install -c conda-forge pytorch=*=cuda*  # for gpu version

In any case you should first add the configuration that's the only supported one for conda-forge which is mentioned on every feedstock:

conda config --add channels conda-forge
conda config --set channel_priority strict

Note that this will effectively replace all installed packages with the versions from conda-forge (upon the next conda install invocation), but mixing with other channels is prone to problems, so if you want to use packages from conda-forge, that's the way.

Finally, you shouldn't be installing stuff like pytorch into your base environment, but rather create a new environment (e.g. conda create -n my_env pytorch python=3.10) for the given project that you're working on.

[h-vetinari]

Ah, nevermind, I just see now that you're on windows, where we unfortunately don't have pytorch builds yet: #32. In this case, you can only try to use the builds from the pytorch or default channel

[hiroalchem]

Hmmm, I see, I understand the situation.
But I didn't understand the details, does this mean that now to make it installable on windows, we need to build it locally and upload it? Is there anything I can do?

[hmaarrfk]

yes. that is likely the sustainable way to do it.

there was some good work made in #134

I think it would be a good starting point (maybe) but it would be nice if you could keep the contributor's authorship by using git-cherry-pick.

Generally. make a PR, the CI should be able to compile 6 hours worth of the process. This builds confidence. Then we can invoke the process outlined in
https://github.com/conda-forge/cfep/blob/main/cfep-03.md

[hadim]

Pytorch-cpu & pytorch-gpu are the old names for compatibility with the packages that used to be published in the pytorch channel.

Jumping here as I am using pytorch-gpu as a shortcut for pytorch=*=*cuda*. Is pytorch-gpu going to still be supported moving forward or is it best to always use pytorch=*=*cuda* instead?

[h-vetinari]

According to me (not necessarily everyone else here), it's subject to removal at any time (pending usage numbers etc.), so best not to rely on it.

Side note: If conda is able to find your cuda drivers (check conda info), you shouldn't even have to specify the build string to get the GPU version, just pytorch should suffice.

[hadim]

According to me (not necessarily everyone else here), it's subject to removal at any time (pending usage numbers etc.), so best not to rely on it.

Understood.

Side note: If conda is able to find your cuda drivers (check conda info), you shouldn't even have to specify the build string to get the GPU version, just pytorch should suffice.

Yeah, I know, but we are building various and complex conda envs in container images in CI, and I found that forcing for pytorch-gpu prevents me various headaches :-D (this pipeline has been setup quite a long time ago, and I know the pytorch situation is much better today but just in case I prefer to keep it)

[hmaarrfk]

I'm pretty hesitant to remove it for the reasons in conda-forge/conda-forge.github.io#1894

[h-vetinari]

I'm pretty hesitant to remove it for the reasons in conda-forge/conda-forge.github.io#1894

The situation here is not as complicated as the ones you describe in that issue. If we dropped pytorch-gpu for some new version, users would simply have to adapt their dependencies to get the newer versions. This - i.e. dropping a compatibility output for a given version - worked without a hitch (or at least, there were no problems that I heard of) after renaming abseil, grpc etc.

[h-vetinari]

I have a proposal to make the conda-forge linter complain when it finds pytorch-{cpu,gpu} dependencies in feedstocks. That way we can ensure its use goes down and eventually remove the wrappers.