Account for RAFT update to SNMG APIs #454
Conversation
| * @param[in] index_params configure the index building | ||
| * @param[in] index_dataset a row-major matrix on host [n_rows, dim] | ||
| * | ||
| * @return the constructed IVF-Flat MG index | ||
| */ | ||
| auto build(const raft::device_resources& handle, | ||
| auto build(const raft::device_resources_snmg& clique, |
There was a problem hiding this comment.
One of the main goals with having the "snmg" resources object match the single-gpu object is that we wanted to be able to remove this additional MG. We should now be able to accept device_resources and then check to see if a nccl clique has been set on it (which would imply that it's a multi-gpu resources object and not a single-gpu object). The whole goal with doing this was to consolidate code paths.
There was a problem hiding this comment.
The NCCL clique is not set as a resource anymore, but we should still be able to implement the dispatching by checking the dynamic type of the device_resources. The real question then is, do we truly want dispatching on both the regular API (cuvs::neighbors::build) and the mg namespace (cuvs::neighbors::mg::build)? It kind of make sense that a user providing a device_resources_snmg instance to the regular API (cuvs::neighbors::build) would want things to be deployed on multiple GPUs. However, the reverse is not necessarily true. A user who explicitly chose the mg namespace, but did not provide the adequate device_resources_snmg would fallback to single GPU, potentially unintentionally. Is this what we want?
I propose that we implement the dispatching mechanism solely on the regular API (cuvs::neighbors::build) in a dedicated follow-up PR? This also allows the MG doc to explicitly avert users that they should use an adequate device_resources_snmg to use the MG API. What do you think?
NCCL clique initialization function PR in RAFT : rapidsai/raft#2487
Removed instantiation of
raft::comms::build_comms_nccl_only(rapidsai/raft#2465)