[FEA]: Make cooperative groups a part of CCCL

[mpayrits]

Is this a duplicate?

• I confirmed there appear to be no duplicate issues for this request and that I agree to the Code of Conduct

Area

General CCCL

Is your feature request related to a problem? Please describe.

I would like the cooperative_groups.h header and the cooperative_groups/ subfolder of the CUDA toolkit's include/ folder to be maintained as part of CCCL.

Describe the solution you'd like

Provide the cooperative groups headers either as part of one of the three libraries comprising CCCL, as a fourth library, or as part of a "miscellaneous" component of CCCL.

Describe alternatives you've considered

No response

Additional context

As documented in this exchange between Mats, I've been playing around with getting cooperative groups to work with nvc++. In the process, I realized that the CG library is essentially header-only, apart from a few clearly separated functions in cuda_device_runtime.h starting with cudaCG related to multi-grid groups. I was able to come up with a patch (attached to the aforementioned forum thread) that improved nvc++/CG interoperability that I have been using for personal projects since then.
This experience gives me a strong impression that cooperative groups would benefit from being maintained as proper open-source software. If that had been the case, I would have certainly submitted a pull request instead of engaging in the prehistoric practice of distributing patches.
I'm bothering you here because CCCL feels like a clean slate and a great opportunity to squeeze CG into an open-source repository. This argument could extend to other parts of the CUDA toolkit include folder, but having searched through it, I think cooperative groups really stand out in this regard as they're self-contained, widely applicable, and basically completely header-only (i.e., with all implementations fully visible).
One of the difficulties I see is deciding where exactly to put CG headers in the CCCL repository. While that would certainly be the maintainers' call, here's a few options to illustrate the idea. Personally, I would argue for the inclusion of CG in libcu++, which references it in its documentation and provides other non-stdlib extensions, such as cuda::pipeline (I think, despite a strange statement in the docs that the "pipeline library is not part of the open-source libcu++ distribution"). CG could also be considered a fourth CCCL library besides CUB, Thrust, and libcu++, but that might be less convincing as it's significantly smaller in scope than those libraries. Finally, CG could be tucked away into a "misc" folder (or "core", or "toolkit_support", or something like that), which would be useful but avoid the fanfare of a fourth library.
Thank you very much for your consideration.

Best,
Matjaž

[github-actions]

Hi @mpayrits!

Thanks for submitting this issue - the CCCL team has been notified and we'll get back to you as soon as we can!
In the mean time, feel free to add any relevant information to this issue.

[jrhemstad]

Hey @mpayrits! Thanks for taking the time to reach out and write this up! It's certainly helpful to know that people are interested in making Cooperative Groups part of CCCL.

I can't comment on any definitive plans right now, but lets just say that we're definitely on the same wavelength 🙂.