-
-
Notifications
You must be signed in to change notification settings - Fork 780
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
patch for cusparseLt 0.6.1 #8074
Conversation
Stumbled on this while trying to figure out why the cupy main does not build on a machine it did in December. Tracked it down to cusparseLT 0.5.2 installed on that machine. Rebasing this PR on today's main (f643379) builds fine (great!) but fails down the line with (the specific test file is fairly random)
On a different machine which does not have Hat tip @andfoy for effectively guiding me down this exercise. |
@ev-br could you create an issue for the error that you see (and ping me)? It's not about cuSPARSELt but something else. |
Either an update to this PR or cleaning up the cupy cache locally made the problem reported in #8074 (comment) disappear. So I guess I can confirm that this PR, when rebased on main, works for
|
@ev-br |
@kmaehashi |
Hi sorry to keep you waiting! I'll try to get this in this week. |
/test mini |
Let me push the required CI changes (#8351) to the branch 🙏 |
/test mini |
@kmaehashi Thank you so much for writing the Docker setup. |
As this is now in, is there a timeline on the next release? (I'm looking to fetch it via pypi in keeping with an existing build) |
@jake-arkinstall I'm curious about the usecase. Do you build/distribute CuPy built with cuSPARSELt support? Is it fine if there is a new v14 alpha release on PyPI? This is a backward-incompatible change (dropping support for earlier cusparseLt versions), and usually, we don't backport such PRs to v13. |
Long story! I am building a package with Nix, and at the moment nixpkgs' cuda packages have a slightly frustrating support matrix when combining certain packages (which I'm in the fun position of wanting to combine). I have a local clone where I'm getting everything up to date so it all works together, with the intention of filing a PR to nixpkgs with shiny new things. The existing version uses the pypi package as the source. I have a version that fetches cupy from git at the commit this was merged at, replaces the third_party submodules with nix derivations corresponding to their git repos, and adds the required dependencies for building. It works for me, but I know that it'd be a hard sell in a PR. If there is a plan for a release with these changes, then I'll keep my local version for now, await the release, then file a PR to nixpkgs with the release details. If not, then I can decide to try the PR anyway or just keep the derivation for my project alone and decouple it. All this is very much a "me" problem and I certainly wouldn't want to cause a fuss over it. I'm just trying to gauge rough timelines to see how I should synchronise. |
Thanks for sharing the background! As for the CuPy v14.0.0a1 release, which will be made from the One thing to note: So far, only cuSPARSELt usage in CuPy is a undocumented private thin wrapper to the C API as illustrated in the example. Building with or without cuSPARSELt support does not affect the CuPy's core functionalities/performance. |
#6757
This PR is compatible only on CUDA 12 and cusparseLt 0.6.0/1 (not 0.5.0, 0.5.2).