-
-
Notifications
You must be signed in to change notification settings - Fork 5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Adding cuda-nvcc recipe #21350
Adding cuda-nvcc recipe #21350
Conversation
Hi! This is the friendly automated conda-forge-linting service. I wanted to let you know that I linted all conda-recipes in your PR ( Here's what I've got... For recipes/cuda_nvcc:
|
Hi! This is the friendly automated conda-forge-linting service. I wanted to let you know that I linted all conda-recipes in your PR ( Here's what I've got... For recipes/cuda_nvcc:
|
Hi! This is the friendly automated conda-forge-linting service. I wanted to let you know that I linted all conda-recipes in your PR ( Here's what I've got... For recipes/cuda_nvcc:
|
Hi! This is the friendly automated conda-forge-linting service. I wanted to let you know that I linted all conda-recipes in your PR ( Here's what I've got... For recipes/cuda_nvcc:
|
Co-authored-by: Marius van Niekerk <[email protected]>
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 ( |
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 ( |
Doesn't nvcc have a maximum supported compiler version? Is that limit monitored here? |
Hi! This is the friendly automated conda-forge-linting service. I wanted to let you know that I linted all conda-recipes in your PR ( Here's what I've got... For recipes/cuda-nvcc:
|
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 ( |
recipes/cuda-nvcc/meta.yaml
Outdated
- nvvm # [linux] | ||
- Library\nvvm # [win] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does it make sense for nvvm
to be a separate package? I'm thinking about downstream packages like Numba
who don't use nvcc
but do use nvvm
.
Regardless, this could be split out later if desired.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this could make sense. If we can raise this as an issue on the feedstock we could align this change for all formats, rather than a conda-forge only change here.
- add cuda-version - explicit target_names - about sections in every output - add arm-variant
recipes/cuda-nvcc/meta.yaml
Outdated
- cuda-nvcc_{{ target_platform }} =={{ version }} | ||
- {{ pin_compatible("cuda-version", max_pin="x.x") }} | ||
run_constrained: | ||
- gcc_impl_{{ target_platform }} >=6,<13 # [linux] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we need to do similar with clang or msvc?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since we only use clang
on macOS and that is skipped, think we don't need to worry about that.
On Windows we don't distribute compiler packages and instead rely on CI to have them. Not sure what more we can do there
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since we only use
clang
on macOS and that is skipped, think we don't need to worry about that.
A user could presumably install it and want to use it in their environment though?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry am not following. How would they install it? This recipe isn't built on macOS
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There's linux-64 clang builds that someone could install and use in their environment.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah ok. That makes more sense. Thanks Keith! 🙏
There is a clang
package. Though the package that encodes target_platform
would be in clang-compiler-activation-feedstock
. However this is only configured for macOS targets currently.
That said, suppose one could add Linux targets for clang
. Maybe we could save this as a follow up issue (for whenever those packages get added)?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We can always repodata patch at that time. I'm fine to defer it to a follow up.
@@ -0,0 +1,17 @@ | |||
if not exist %PREFIX% mkdir %PREFIX% |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm unfamiliar with Windows, is this something we should be doing in all of our recipes? We didn't do that in libcublas, for instance. We're not specifically writing anything to the %LIBRARY_PREFIX%
directory in this file.
done | ||
fi | ||
else | ||
cp -r $i ${PREFIX} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some questions:
- I assume that we're intentionally not including the contents of
bin
into thetargetsDir
? - We probably want to put the
nvvm
contents into thetargetsDir
right? cicc
is insidenvvm/bin
, butnvcc
needs to be able to find it. Does that need special handling to be placed into${PREFIX}/bin
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The current layout is fine. The bin
and nvvm
directories will be copied into ${PREFIX}/bin
/ and ${PREFIX}/nvvm
. Since the relative layot has stayed consistent, nvcc
doesn't need to be modified to know where the nvvm
directory is
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are we OK writing to ${PREFIX}/nvvm
? My understanding was that we were avoiding writing to such top-level directories as much as possible to avoid clobbering, but perhaps we're OK treating nvvm
as CUDA-specific in the same way that we are treating targets
as CUDA-specific.
Do we still want to include some of these contents in targets
or only put them in the top-level ${PREFIX}/*
directories?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We need nvvm
in $PREFIX
due to the relative pathing Robert mentioned. nvcc
expects bin
nvvm
and targets
to all be at the same level.
Clobbering shouldn't be a concern here as it was with things like src/example.c
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We are already patching nvcc.profile
, so it's not a big deal to patch a couple more lines.
If we are going with filesystem hierarchy, they should not be in $PREFIX
and rather in somewhere like $PREFIX/lib/nvcc/nvvm
and $PREFIX/lib/nvcc/targets
just like gcc
does with $PREFIX/lib/gcc
Thoughts @mbargull, @conda-forge/core?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nvcc.profile
is not patched on Linux. It is only patched on Windows to address shipping different CCCL versions as requested in PR ( #21953 ). Preferably it would not be patched at all (even on Windows). Open to a better solution that doesn't require the patch on Windows (if we have ideas). Though this is probably best taken up in the feedstock since we are blocked on Windows builds atm ( #21723 (comment) ).
It's worth noting that there are already cases where we install non-traditional things in $PREFIX
. For example go
adds $PREFIX/go
. With go
, trying to move away from that model breaks the compiler in weird ways.
Typically all CUDA components are placed in the same relative paths where they are then QA’d and deployed. The proposal here suggests dividing them up between different paths that will deviate from the process. This risks introducing new issues unique to this non-standard deployment model and makes it harder to support.
Finally would add Numba is dependent on this location. So changing it here means Numba (and maybe other libraries) will need updates.
recipes/cuda-nvcc/meta.yaml
Outdated
- sysroot_{{ target_platform }} 2.17 # [linux] | ||
- __glibc >=2.17 # [linux] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Out of scope for fixing right now, but for future note: Is there no relationship between these packages? Should there be?
recipes/cuda-nvcc/meta.yaml
Outdated
host: | ||
- sysroot_{{ target_platform }} 2.17 # [linux] | ||
- __glibc >=2.17 # [linux] | ||
- cuda-version {{ cuda_version }} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What is the benefit of including cuda-version
in the host environment? Isn't the purpose to be a metapackage ensuring compatibility across dependencies, i.e. something we really only need in run
? What build requirements are being constrained by including this in host
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Defining this in host
allows us to use the pin_compatible
function in the run section. There may be more context though.
recipes/cuda-nvcc/meta.yaml
Outdated
run: | ||
- sysroot_{{ target_platform }} 2.17 # [linux] | ||
- __glibc >=2.17 # [linux] | ||
- cuda-cudart-dev |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we need a version constraint here, or is that all managed using cuda-version
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe cuda-version
suffices here.
Fix cuda-nvcc tests
Make a single output recipe.
We were running into some issues during testing, which we were struggling to resolve here. So for now we have cut this down to the minimal working recipe. Think it will be easier to try to add back the removed functionality in the feedstock. Though please let us know if you have other thoughts on that. |
Planning on merging EOD Monday if no comments |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Testing the package locally ( conda install -c ..../staged-recipes/build_artifacts/ cuda-nvcc cuda-cudart
) in a clean env.
This creates a broken compiler, due to ${CXX}
having no value. We need to either require a CXX compiler or only optionally add this env var when CXX
exists.
(ctk) rmaynard@rmaynard-dt:~/Work/cmake/conda_test_build$ conda list
# packages in environment at /home/rmaynard/miniconda3/envs/ctk:
#
# Name Version Build Channel
_libgcc_mutex 0.1 conda_forge conda-forge
_openmp_mutex 4.5 2_gnu conda-forge
cuda-cccl_linux-64 12.0.90 ha770c72_1 conda-forge
cuda-cudart 12.0.107 hcb278e6_0 file:///home/rmaynard/Work/conda-forge/staged-recipes/build_artifacts
cuda-cudart-dev 12.0.107 hcb278e6_0 file:///home/rmaynard/Work/conda-forge/staged-recipes/build_artifacts
cuda-cudart-dev_linux-64 12.0.107 hcb278e6_0 file:///home/rmaynard/Work/conda-forge/staged-recipes/build_artifacts
cuda-cudart-static 12.0.107 hcb278e6_0 file:///home/rmaynard/Work/conda-forge/staged-recipes/build_artifacts
cuda-cudart-static_linux-64 12.0.107 hcb278e6_0 file:///home/rmaynard/Work/conda-forge/staged-recipes/build_artifacts
cuda-nvcc 12.0.76 h59595ed_0 file:///home/rmaynard/Work/conda-forge/staged-recipes/build_artifacts
cuda-version 12.0 hffde075_0 conda-forge
libgcc-ng 12.2.0 h65d4601_19 conda-forge
libgomp 12.2.0 h65d4601_19 conda-forge
libstdcxx-ng 12.2.0 h46fd767_19 conda-forge
Alex added a clearer error message above. If we want to do more here, let's raise an issue in the feedstock and discuss |
Thanks all! 🙏 Let's follow up on anything else in the feedstock 🙂 Will also include a PR link related to follow ups pertaining to comment ( #21350 (comment) ) once available. ( edit: filed issue conda-forge/cuda-nvcc-feedstock#1 ) |
Checklist
url
) rather than a repo (e.g.git_url
) is used in your recipe (see here for more details).