You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Solution to issue cannot be found in the documentation.
I checked the documentation.
Issue
11.7.1 had a huge ABI break that moved from redefining all of the CUDA functions in Cython to externing them: NVIDIA/cuda-python@cfa118a
For any library that uses the Cython parts of cuda-python, this can lead to a runtime failure if something was built with 11.7.1 and then tries to run on 11.7.0, or vice versa because the function signature changes. I.E. if built with 11.7.1 and then tried to run on 11.7.0:
E TypeError: C function cuda.ccudart.cudaStreamSynchronize has wrong signature (expected cudaError_t (cudaStream_t), got __pyx_t_4cuda_7ccudart_cudaError_t (__pyx_t_4cuda_7ccudart_cudaStream_t))
We should probably add a repodata patch to make anything pre 11.7.1 require <11.7.1 and anything post 11.7.1 require >=11.7.1,<12?
The rmm packages in conda-forge are impacted by this as they're built with 11.7.1, but the rmm packages in the rapidsai channel are built with something older, presumably to avoid specifically this.
We may want to build rmm on conda-forge with the 11.7.0 release for consistency with the rest of RAPIDS… this is tough. @kkraus14 or others, do you have thoughts on that?
edit: this might be a bad idea but I’m not sure. I might pause that thought.
@jakirkham Any thoughts on this? We definitely need a repodata patch, but AFAIK it only applies if cuda-python is pinned in the host or run section. If the build-time version is not specified (as in the case of rmm) repodata cannot help. Am I right?
Activity
leofang commentedon Sep 12, 2022
@vzhurba01 @m3vaz This impacts CUDA Python wheel users too...
bdice commentedon Sep 12, 2022
We may want to build
rmmon conda-forge with the 11.7.0 release for consistency with the rest of RAPIDS… this is tough. @kkraus14 or others, do you have thoughts on that?edit: this might be a bad idea but I’m not sure. I might pause that thought.
leofang commentedon Sep 12, 2022
It should be doable. Only RMM 22.08.0 was built with CUDA Python 11.7.1. We could mark it as broken on conda-forge, rebuild with CUDA Python 11.7.0, and set a constraint on its runtime dependency to avoid 11.7.1, if everyone is OK. But it's better if we discuss
rmmissues in https://github.com/conda-forge/rmm-feedstock, not here.leofang commentedon Sep 12, 2022
See conda-forge/rmm-feedstock#15.
leofang commentedon Sep 29, 2022
@jakirkham Any thoughts on this? We definitely need a repodata patch, but AFAIK it only applies if
cuda-pythonis pinned in the host or run section. If the build-time version is not specified (as in the case ofrmm) repodata cannot help. Am I right?leofang commentedon Oct 2, 2022
Made two PRs to address this issue:
cuda-python11.7.1 conda-forge-repodata-patches-feedstock#325jakirkham commentedon Oct 3, 2022
Have been out for a few weeks. So only now catching up on this.
Adding
run_exportsseems reasonable.Some kind of repodata patch is needed. Commented there on how we might approach that.
jakirkham commentedon Nov 17, 2023
AFAICT this has been addressed. Going to close this out. Please feel free to reopen if I've missed something. Thanks all! 🙏