Start refactoring C API and pylibcugraph to Use DLPack - #5590
Start refactoring C API and pylibcugraph to Use DLPack#5590alexbarghi-nv wants to merge 32 commits into
Conversation
…-nv/cugraph into plc-dlpack-everywhere
|
Auto-sync is disabled for draft pull requests in this repository. Workflows must be run manually. Contributors can view more details about this message here. |
alexbarghi-nv
added
improvement
|
/ok to test |
1 similar comment
|
/ok to test |
|
/ok to test |
|
/ok to test |
|
/ok to test |
|
/ok to test d0b35e4 |
alexbarghi-nv
changed the title
|
/ok to test 575ebfe |
|
/ok to test fc0fddc |
|
/okay to test 4d65a87 |
|
/okay to test 63e046e |
|
/ok to test 62abaf8 |
|
/ok to test dac9f4f |
BradReesWork
changed the title
BradReesWork
changed the title
|
This is just the first PR and not the final version. There are a number of dependencies on other packages that prevents fully supporting DLPAck version 1.0 at this point. But this sets up the code for simply updating the dependency file when cuDF and others have moved to DLPack 1.0 |
alexbarghi-nv
left a comment
alexbarghi-nv
left a comment
There was a problem hiding this comment.
@BradReesWork just 1 comment; otherwise looks ok.
| endfunction() | ||
|
|
||
| set(CUGRAPH_MIN_VERSION_dlpack 0.8) | ||
| set(CUGRAPH_MIN_VERSION_dlpack 1.0) |
There was a problem hiding this comment.
Do we need to change this to 0.8? Or maybe it's safe to build with 1.0+ here as long as we set our runtime version to 0.8+. That would make sense I think.
There was a problem hiding this comment.
I'm not familiar with dlpack's version guarantees. This assumption usually does not hold, and I would set it to 0.8 to be safe - unless you know better about dlpack's behavior.
msarahan
left a comment
msarahan
left a comment
There was a problem hiding this comment.
I don't think this is safe, and I don't understand the thinking. I read rapidsai/build-planning#308 and I understand that an earlier effort was closed for 26.08 because cudf wasn't ready. I think the correct approach is to remain pinned to 0.8 until all of the projects are ready to change over.
I approve of the added pinnings, but I think the cmake file needs to revert back to 0.8.
| endfunction() | ||
|
|
||
| set(CUGRAPH_MIN_VERSION_dlpack 0.8) | ||
| set(CUGRAPH_MIN_VERSION_dlpack 1.0) |
There was a problem hiding this comment.
I'm not familiar with dlpack's version guarantees. This assumption usually does not hold, and I would set it to 0.8 to be safe - unless you know better about dlpack's behavior.
5 participants
Overview
Refactor pylibcugraph to use DLPack for array exchange instead of calling NumPy and CuPy APIs directly. The C API owns DLPack interpretation and validation, while the Python bindings route array conversions through that common boundary.
Changes
>=1.0,<1.1but staying at 0.8 independencies.yamlRelease target
This PR targets
mainfor the 26.10 release. The DLPack dependency updates previously tracked in #5602 are incorporated here so the API refactor and its required dependency range land together.The cross-project DLPack migration is tracked in rapidsai/build-planning#308 and related to NVIDIA/cuvs#2354.
Validation
rapids-dependency-file-generator --clean --warn-all --strictdependencies.yamland the generatedall_*.yamlenvironments with PyYAMLgit diff --checkdlpack>=1.0,<1.1Broader C++ and Python tests are handled by the PR's CI workflows.