Hello,
Ludovic Courtès writes:
> Yeah, we could think about a transformation option. Maybe
> ‘--with-configure-flags=python-pytorch=-DAMDGPU_TARGETS=xyz’ would work,
> and if not, we can come up with a specific transformation and/or an
> procedure that takes a list of architectures and returns
ure they can be combined however, as the GPU code is included
>>> in the shared libraries. Thus all dependent packages like
>>> python-pytorch-rocm would need to be built for each architecture as
>>> well, which is a large duplication for the non-GPU parts.
>>
>&g
ot sure they can be combined however, as the GPU code is included
>> in the shared libraries. Thus all dependent packages like
>> python-pytorch-rocm would need to be built for each architecture as
>> well, which is a large duplication for the non-GPU parts.
>
> Yeah, but maybe that
Hello!
David Elsing skribis:
> after seeing that ROCm packages [1] are available in the Guix-HPC
> channel, I decided to try and package PyTorch 2.2.1 with ROCm 6.0.2.
Nice!
> The changes for the ROCm packages are here [4] as a modification of
> Guix-HPC. There, the python-
Hi Ricardo,
thanks for the information!
Ricardo Wurmus writes:
> Oh, commit 8429f25ecd83594e80676a67ad9c54f0d6cf3f16 added
> python-pytorch2 at version 2.2.1. Do you think you could adjust your
> patches to modify that one instead?
I already adjusted the patches yesterday to remove the
Hi David,
> after seeing that ROCm packages [1] are available in the Guix-HPC
> channel, I decided to try and package PyTorch 2.2.1 with ROCm 6.0.2.
Excellent initiative!
> For this, I first unbundled the (many) remaining dependencies of the
> python-pytorch package and updated
Hello,
after seeing that ROCm packages [1] are available in the Guix-HPC
channel, I decided to try and package PyTorch 2.2.1 with ROCm 6.0.2.
For this, I first unbundled the (many) remaining dependencies of the
python-pytorch package and updated it to 2.2.1, the patch series for
which can
