Skip to content

feat(cuda-device): support u64 reductions and scans in cooperative_groups #1497

Closed

Description

@pedrozaz

What problem does this solve?

warp_reduce, warp_scan, block_reduce, and block_scan do not accept u64 directly. Built-in support would simplify aggregating 64-bit counters with these APIs, without requiring callers to define a scalar wrapper and its operations.

Proposed API / behavior

Implement WarpShuffle for u64 and ReduceOp<u64> for the existing Sum, Min, Max, BitAnd, BitOr, and BitXor operations. Preserve group masks, tile boundaries, and wrapping integer-sum semantics.

The following should compile using the existing API:

use cuda_device::cooperative_groups::{WarpTile, ops::Sum, warp_reduce};

pub fn total(tile: &WarpTile<32>, value: u64) -> u64 {
    warp_reduce::<u64, Sum, 32>(tile, value)
}

It currently produces E0277 for both u64: WarpShuffle and Sum: ReduceOp<u64>. The same bounds prevent using u64 with the other three functions.

Tests should compare GPU results against a CPU oracle, including tiles of 1/2/4/8/16/32 lanes, multiple tiles, high-word values, wrapping overflow, and block operations with partial final warps.

Alternatives considered

A local Copy newtype around u64 could implement WarpShuffle using two 32-bit exchanges through WarpCollective, alongside local reduction operations. This is a viable extension point; the proposal moves that boilerplate and its tests into the library. Such a wrapper was not implemented or GPU-tested during this investigation.

The low-level warp::shuffle_*_u64 functions also allow custom algorithms. Defining only a local ReduceOp<u64> is insufficient: u64: WarpShuffle is still missing, and downstream crates cannot implement that external trait for the primitive type.

Additional context

Validated against upstream commit d141118c05f705fcf932a8e9077dc714477edc4d, using nightly-2026-10-11:

  • cargo check accepted all four functions with u32; equivalent u64 probes failed with the bounds above. A local sum operation removed only the ReduceOp<u64> error.
  • The existing shuffle_64 example passed its CPU comparisons on an RTX 5060 Ti (sm_120); Compute Sanitizer memcheck and synccheck both reported zero errors. This validates the existing low-level shuffles, not the proposed collective implementations.
  • PR #278 supplied the low-level 64-bit shuffles. PR #1305 addresses the u32/i32 redux fast path in the same file, without adding u64 support.

Activity

  1. added
    enhancementNew feature or request
    TBDNot yet triaged; scope or disposition undecided
    on Oct 11, 2026
  2. pedrozaz commented on Oct 11, 2026

    @pedrozaz
    ContributorAuthor

    I’d be happy to work on this if there’s interest. I’ve already sketched out a development and testing plan. Let me know what you think before I get started.

  3. pedrozaz commented on Oct 21, 2026

    @pedrozaz
    ContributorAuthor

    Oh...

  4. praveenperera commented on Oct 21, 2026

    @praveenperera
    Contributor

    sorry about that @pedrozaz, thanks for the review

  5. added
    cuda-oxideSIMT programming model: rustc backend, cargo oxide, cuda-device, cuda-host, book
    on Oct 29, 2026
  6. added a commit that references this issue on Oct 29, 2026
    3f1f432
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    TBDNot yet triaged; scope or disposition undecidedcuda-oxideSIMT programming model: rustc backend, cargo oxide, cuda-device, cuda-host, bookenhancementNew feature or request

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions