CUDA for ppc64le / aarch64

[jaimergp]

Comes from conda-forge/conda-forge-pinning-feedstock#725

Let's summarize how CUDA is doing in ppc64le / aarch64 as of today.

PowerPC

• CUDA <10.2 is not supported. We never had cudatoolkit there (see 9.2, 10.0, 10.1 not built on ppc64le #12)
• CUDA 10.2 is available and all the infra is there (docker images, nvcc, and cudatoolkit itself). We just did not roll out the migrator yet. See here for manual instructions (not recommended).
• CUDA >= 11 is on hold because CentOS8 is "required" and there are no plans to support it just yet. A hybrid image could be created on COS7, but that might pose licensing issues. More info

ARM

Basically no support yet. CUDA offers aarch64 support since v11.0, and we also have to distinguish between the SBSA compliant builds, and the custom L4T (Jetson) variants.

• SBSA packages are being tackled in Add SBSA aarch64 CTK pkgs for CUDA 11.X #59.
• Docker images have not been added yet, but being CUDA 11, they will require CentOS 8 too, so basically we have the same limitations as in PPC.

---

In short, adding support for CUDA 11+ on non-x64 archs will require substantial work due to the CentOS 8 issue, which is being discussed here.

[jakirkham]

The current plan based on previous discussion is just to use CentOS 7 images for the builds (even for newer CUDA versions). Please see this comment ( conda-forge/conda-forge.github.io#1432 (comment) ) for details.

[isuruf]

That's not what we discussed in the core gitter chat. In the core gitter chat, we agreed to use CentOS 8 images with CentOS 7 sysroot.

[jaimergp]

So we would build the images as usual but then use cdt_name=cos7 and sysroot_*=2.17 on our recipes, or is there anything else involved? Is this being tackled by somebody or is it more like "would be nice to have"? I have some free time I can use to do this if some instructions are provided! :)

[isuruf]

So we would build the images as usual but then use cdt_name=cos7 and sysroot_*=2.17 on our recipes, or is there anything else involved?

Yes

Is this being tackled by somebody or is it more like "would be nice to have"?

It'd be nice to have, but nobody is working on it.

[jaimergp]

I guess it'll make sense to wait until the split packages are ready since this would only benefit 11.0 - 11.2, and these are not going to be part of the build matrix down the road, right?

[jakirkham]

That's not what we discussed in the core gitter chat. In the core gitter chat, we agreed to use CentOS 8 images with CentOS 7 sysroot.

Ok. Have submitted a CentOS 8 based ARM image PR ( conda-forge/docker-images#189 )

[leofang]

use cdt_name=cos7 and sysroot_*=2.17 on our recipes

With the new images added, does it still hold, or should we use cdt_name=cos8 + sysroot_*=2.17?

[jakirkham]

Yeah the original sounds right. We are just reusing CentOS 7 things on CentOS 8 images. Though will let Isuru confirm 🙂

[leofang]

Hmmm if it's not cos8 it could be problematic, as we've set it in nvcc-feedstock and then a few other places:
https://github.com/conda-forge/nvcc-feedstock/blob/408c93112830bfbd8707ea5bc8a4be7cb6b94462/recipe/conda_build_config.yaml#L108-L114

[leofang]

Hmmm if it's not cos8 it could be problematic, as we've set it in nvcc-feedstock and then a few other places:
https://github.com/conda-forge/nvcc-feedstock/blob/408c93112830bfbd8707ea5bc8a4be7cb6b94462/recipe/conda_build_config.yaml#L108-L114

Hi @isuruf, should I fix the cos8 usages, and then send a PR to fix the repodata? Or you'd prefer to mark them as broken instead?

[leofang]

I just checked: cdt_name does not go into the repodata. It is only used to calculate the hash (for build string).

[isuruf]

It should be changed to cos7. No need to mark them as broken

[leofang]

I think we have everything done here for ppc64le/aarch64. Feedstock maintainers are free to enable the support via cbc.yaml. A migrator is being added in conda-forge/conda-forge-pinning-feedstock#2001. For any follow-up discussion please feel free to open new issues. Thanks everyone!