[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Enabling ROCm on Everything



On Wed, 2023-03-22 at 10:38 +0100, Gard Spreemann wrote:
> "M. Zhou" <lumin@debian.org> writes:
> > 
> > However, as long as the cuda compute architectures are backward-compatible,
> > we can just build several selected architectures that will work in most cases.
> > For instance, the upstream has built their binary release of pytorch-cuda
> > for the following cuda architectures:
> >   37, 50, 60, 61, 70, 75, 80, 86, 90
> > But I suppose 61, 75, and 86 will be sufficient for the debian build of
> > pytorch-cuda. These correspond to the GTX 1XXX, RTX 2XXX, and
> > RTX 3XXX series of GPUs. The users of datacenter GPUs are not likely
> > to use the debian packaged pytorch-cuda. In most cases they will
> > stick to anaconda. Even if the user has a datacenter GPU, the
> > code still runs thanks to backward compatibility.
> 
> But then again, Debian is the Universal operating system. I think
> history has shown time and time again that it's best if we don't try to
> guess where, how and in what situations the user will run Debian. Of
> course, I do appreciate the technical problem here – just sharing a
> thought :-)

Umm... as I don't plan to split GPU architecture for pytorch-cuda, we
always have the chance to change the supported architecture. Now
we are targetting at experimental and we can surely wait and hear
some feedback form the BTS.

The pytorch upstream has deprecated BUILD_SPLIT_CUDA cmake
option, and says the binaries are no longer bloat up as of the
2.0.0 release. I can surely do some experiments and compare the
binary size.

If the binary size with support for all GPU archs is not insane, I do
not have a good reason to exclude them then.


Reply to: