Re: Enabling ROCm on Everything
On 2023-03-27 05:44, M. Zhou wrote:
> I changed my mind. Now I agree with the fine-grained ROCm architecture split solution.
> When finalizing the pytorch-cuda packaging, I realized that it won't induce much
> burden to me if we will build python3-torch-rocm-{gfx900,gfx906,etc}. I have already
> prepared some code (for cuda variant) that is reusable for the rocm variants as well.
I'm wondering: do we even need GPU-arch-specific builds of pytorch?
I just did a test build of rocrand for (1) only gfx806 and for (2) only
gfx903, and it looks like both libraries built have identical ABI.
Cory, re-reading your initial mail, it reads like you are suggesting
that this is indeed the case (or am I reading to much into it?):
On 2023-03-21 06:17, Cordell Bloor wrote:
> One possible split would be on the GFX architecture major version. There would be binary packages for librocsparse0-gfx8, librocsparse0-gfx9, librocsparse0-gfx10, and librocsparse0-gfx11 with each providing librocsparse0.
If all GPU-arch-specific builds indeed share ABI, then pytorch etc.
don't need special builds. We could have pure meta-packages like
pytorch-rocm-gfx900 that depend on the correct implementation.
We could even go so far as to use the alternatives system to bridge
interface and implementation and thus make implementations
runtime-switchable, analogous to what Mo does for the BLAS
implementations. But I don't see a use case for that (yet).
Reply to: