-
Notifications
You must be signed in to change notification settings - Fork 302
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
Add MG support to the C API #2110
Add MG support to the C API #2110
Conversation
…the changes in this PR.
rerun tests |
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.
Except for few minor issues, looks good to me.
|
||
ret_code = cugraph_resource_handle_init_comms(handle, prows, &ret_error); | ||
TEST_ASSERT(result, ret_code == CUGRAPH_SUCCESS, "handle create failed."); | ||
TEST_ASSERT(result, ret_code == CUGRAPH_SUCCESS, cugraph_error_message(ret_error)); |
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.
Same here. We may consider adding a utility function to set prows from p in our C++ main codebase and call that function in MG C++ tests, MG C tests, and python tests.
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.
Ultimately we need a more complete design of this portion of the system. @rlratzel and I discussed this a bit. The problem is that in order to properly configure the raft handle in the C API we would need to replicate a bunch of code that RAFT has implemented in Python and have it callable from C.
Our short term solution is to allow the calling program to create and configure a raft handle and then pass it into the C API call. I think the right long term solution is to have RAFT migrate the dynamic configuration of the comms object (which requires doing a dlopen
of the appropriate shared object library) from python into C++ so that we can call it from the C API.
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.
Umm... not sure how all these are related to computing p_rows from p, but I get this is not directly relevant to this PR. We should discuss how to properly compute p_rows (& p_cols) from p, but I agree that this should be a separate discussion.
…graph recipe to match CI environment.
Fix for gmock CI build problem has been merged. rerun tests |
…s/cugraph into fea_c_api_mg_implementation
Codecov Report
@@ Coverage Diff @@
## branch-22.04 #2110 +/- ##
===============================================
Coverage ? 54.98%
===============================================
Files ? 12
Lines ? 662
Branches ? 0
===============================================
Hits ? 364
Misses ? 298
Partials ? 0 Continue to review full report at Codecov.
|
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.
Approving ops-codeowner
file changes
rerun tests |
…khastings/cugraph into fea_c_api_mg_implementation
Latest dask-cudf packages are available which should fix a CI failure. rerun tests |
@gpucibot merge |
This PR adds multi-GPU support to the C API. The calls were already defined but if multi-GPU was defined they would return errors.
Closes #2091