Update to use CUDA

[stefanozampini]

Checklist

• [x] Used a personal fork of the feedstock to propose changes
• [x] Re-rendered with the latest conda-smithy (Use the phrase code>@<space/conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
• [x] Ensured the license file is being packaged.

Things to do:

• [ ] how to enable CUDA 12?

[conda-forge-webservices[bot]]

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

[stefanozampini]

Hypre complex failures (https://dev.azure.com/conda-forge/feedstock-builds/_build/results?buildId=921211&view=logs&j=517fe804-fa30-5dc2-1413-330699242c05&t=c7d0fcb4-3a10-5b26-dfea-e879a93fc2ab) should be fixed by https://gitlab.com/petsc/petsc/-/merge_requests/7497

[stefanozampini]

Should the tests be disabled when libcuda.so is not present? https://dev.azure.com/conda-forge/feedstock-builds/_build/results?buildId=921270&view=logs&jobId=696704cc-6fef-57a3-ea36-f27779b8cd5e&j=2ed0550f-e734-5ebf-52c6-1bfc19f5811c&t=9c969b19-a14a-5482-8fb9-78bdf745c3c6

[dalcinl]

Should the tests be disabled when libcuda.so is not present?

Maybe there is a way to link with libcuda.so from the stubs, perhaps via setting LIBRARY_PATH (for the GCC+linker) and LD_LIBRARY_PATH (for the dynamic linker) ? Or there are not even stubs to search for?

[stefanozampini]

Maybe add __cuda as the set of requirements for the test?

On Thu, Apr 25, 2024, 18:50 Lisandro Dalcin @.***> wrote:

Should the tests be disabled when libcuda.so is not present?

Maybe there is a way to link with libcuda.so from the stubs, perhaps via setting LIBRARY_PATH (for the GCC+linker) and LD_LIBRARY_PATH (for the dynamic linker) ? Or there are not even stubs to search for?

— Reply to this email directly, view it on GitHub https://github.com/conda-forge/petsc-feedstock/pull/193#issuecomment-2077619300, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABHCKANY5PYFLOGYHOJ4DY3Y7EQ3BAVCNFSM6AAAAABGXHIA7SVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANZXGYYTSMZQGA . You are receiving this because you authored the thread.Message ID: @.***>

[stefanozampini]

Maybe add __cuda as the set of requirements for the test? … On Thu, Apr 25, 2024, 18:50 Lisandro Dalcin @.> wrote: Should the tests be disabled when libcuda.so is not present? Maybe there is a way to link with libcuda.so from the stubs, perhaps via setting LIBRARY_PATH (for the GCC+linker) and LD_LIBRARY_PATH (for the dynamic linker) ? Or there are not even stubs to search for? — Reply to this email directly, view it on GitHub <#193 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABHCKANY5PYFLOGYHOJ4DY3Y7EQ3BAVCNFSM6AAAAABGXHIA7SVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANZXGYYTSMZQGA . You are receiving this because you authored the thread.Message ID: @.>

Nope, it didn't work. So maybe we will disable the test for those archs?

Also, by looking at the logs, PETSc uses rpath for /usr/local/cuda/lib64 https://dev.azure.com/conda-forge/feedstock-builds/_build/results?buildId=922006&view=logs&j=2ed0550f-e734-5ebf-52c6-1bfc19f5811c&t=9c969b19-a14a-5482-8fb9-78bdf745c3c6&l=4141. I think we should use runpath, or try to use a similar trick as for -L$PREFIX/lib for the other dependencies. @dalcinl What do you think?

[dalcinl]

. I think we should use runpath

I'm not sure what do you mean exactly. Are you talking about passing -Wl,--enable-new-dtags to use new newer RUNPATH semantics instead of the older RPATH semantics in shared libraries? In general, I would agree, although with the particular of CUDA, I'm not fully aware of all the gory details.

[stefanozampini]

@dalcinl Builds are clean, I'm skipping running the compiled tests for aarch64 for now. We can figure out the cross-compilation issue with curand later

[dalcinl]

Stefano, if you know for a fact a build is broken and will not work, I believe the usual conda-forge approach to it is to skip it, simply because broken package files should not be published. Or this is just a CI testing issue, and the packages to work if installed in systems with newer enough GLIBC? Have you tried? In that case, then yes, we can move forward. Please confirm (or we can discuss it in person in a couple hours).

[dalcinl]

@stefanozampini Just in case, can do it with two commits? One for the recipe/config changes, and another for the re-rendering changes from conda-smithy? Maybe this is not really necessary, but that's how I've always done it, and I prefer to follow established patterns in things I do not understand in full :sweat_smile:.

[dalcinl]

@leofang Any chance you can give a quick glance to the changes to meta.yml here?

[leofang]

You have CUDA 12 support added to your recipe, but no CI/CD pipelines spawned. I suggest that you manually add the CUDA 12 migrator to .ci_support/migrations and rerender.

For complex recipes like this one, cupy-feedstock can be a good reference (for supporting both CUDA 11/12 which have different file layouts + many CUDA packages + Python + ...), but no big issue from a quick glance other than the missing CIs.

[dalcinl]

For complex recipes like this one, cupy-feedstock can be a good reference

We did, but we were not sure about the CUDA 12 migration, so @stefanozampini leaved it out. Now we know better. Many thanks, @leofang !

[leofang]

No worries, last time I heard we're preparing a doc refresher for conda-forge CUDA packages. It might take some time to finalize, sorry for the learning curve. Before it lands, feel free to ping me or anyone from @conda-forge/cuda to ask for help.

[stefanozampini]

@leofang, I see cupy feedstock only builds with 11.8 or 12.4 https://github.com/conda-forge/cupy-feedstock/blob/main/recipe/meta.yaml#L37. Is the idea to use 11.8 or 12.4 only?

[leofang]

CuPy was built with both CUDA 11.8 & 12.4. The built packages can serve both CUDA 11.x and 12.x users, not limited to the build versions (but obviously some selected features will require a newer CUDA version).

[stefanozampini]

thanks. So, to support the same in PETSc, I need to copy-paste the ignore_run_exports paraphernalia and related run_constrained stuff that are in cupy?

[stefanozampini]

@conda-forge-admin please rerender

[github-actions[bot]]

Hi! This is the friendly conda-forge automerge bot!

I considered the following status checks when analyzing this PR:

• linter: passed
• azure: passed

Thus the PR was passing and merged! Have a great day!