[FEA]: Add a runtime-width group merge-sort primitive for segmented sort #10944

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

CUB

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

Fine-grained segmented sort may assign a configurable group of cooperating threads to each segment. The same group merge-sort building block applies whether that group contains fewer than one warp, exactly one warp, or multiple warps; the cases differ only in the number of threads cooperating on a segment.

Treating multi-warp sorting as a separate primitive would duplicate the underlying building block and would not match the runtime-width selection already expressed by call_group_merge_runtime.

The primitive should therefore take threads_per_segment at runtime and use the same group merge-sort implementation for all supported widths.

Describe the solution you'd like

Add a reusable runtime-width group merge-sort primitive based on the building block used by call_group_merge_runtime that:

• Accepts the supported cooperating-group width at runtime.
• Uses the same interface and implementation structure for sub-warp (threads_per_segment < 32), warp (threads_per_segment == 32), and multi-warp (threads_per_segment > 32) groups.
• Sorts within independent groups of consecutive threads.
• Supports a runtime valid-item count for partially filled groups.
• Prevents synchronization and shared-memory state from crossing group boundaries.
• Supports keys in the initial implementation and provides a path to key-value pairs.
• Supports ascending and descending order.
• Provides correctness coverage across supported sub-warp, warp, and multi-warp widths, including partial groups, duplicate keys, and multiple independent groups in one CTA.

This issue can be closed once the runtime-width primitive is integrated into CUB with tests and an interface suitable for use by specialized segmented-sort kernels. A separate compile-time-width variant is not required to close this issue and is out of scope.

Describe alternatives you've considered

A compile-time threads_per_segment variant was considered. For the current contribution, the runtime-width primitive covers the required sub-warp, warp, and multi-warp cases, so a compile-time variant will not be implemented as part of this issue.

Additional context

Runtime group-width selection is part of the primitive delivered by this issue rather than a later optimization.