[FEA] cuda.core: expose device atomic-operation capability queries (CUDA 13.0)

Summary

CUDA 13.0 makes atomic-operation support queryable per device and per peer path:

• cuDeviceGetHostAtomicCapabilities(unsigned int* capabilities, const CUatomicOperation* operations, unsigned int count, CUdevice dev)
  — batch query: array of operations in, per-operation capability bitmask out (host↔device scope);
• cuDeviceGetP2PAtomicCapabilities(unsigned int* capabilities, const CUatomicOperation* operations, unsigned int count, CUdevice srcDevice, CUdevice dstDevice)
  — same, for a peer-to-peer path.

Supporting enums: CUatomicOperation (integer add/min/max/increment/decrement/and/or/xor,
exchange, CAS, float add/min/max — 14 values) and CUatomicOperationCapability
(SCALAR_32/64/128, VECTOR_32x4, SIGNED, UNSIGNED, REDUCTION). Related additions:
CU_DEVICE_P2P_ATTRIBUTE_ONLY_PARTIAL_NATIVE_ATOMIC_SUPPORTED (13.0) and
CU_DEVICE_ATTRIBUTE_ATOMIC_REDUCTION_SUPPORTED (13.1).

The plain 13.0 device attributes for partial host atomics are already exposed via
DeviceProperties; the capability-query APIs and their enums are not exposed anywhere in
cuda.core. Natural consumers are dispatch layers (numba-cuda, cuda.compute, cuda.cccl)
choosing between native atomics, CAS loops, or host fallbacks.

Underlying C APIs to cover

cuDeviceGetHostAtomicCapabilities, cuDeviceGetP2PAtomicCapabilities,
CUatomicOperation, CUatomicOperationCapability,
CU_DEVICE_P2P_ATTRIBUTE_ONLY_PARTIAL_NATIVE_ATOMIC_SUPPORTED,
CU_DEVICE_ATTRIBUTE_ATOMIC_REDUCTION_SUPPORTED.

Design sketch (draft — needs design-meeting review)

[!IMPORTANT]
Starting point only, not a settled design — review in the cuda.core design meeting.

caps = dev.atomic_capabilities(                       # names TBD
    [AtomicOperation.FLOAT_ADD, AtomicOperation.CAS],
    peer=None,                                        # or another Device -> P2P query
)
# -> {AtomicOperation.FLOAT_ADD: frozenset({AtomicCapability.SCALAR_32, ...}), ...}

StrEnum wrappers + mapping dicts following the cuda.core.typing conventions; batch-in /
batch-out mirroring the C API so N operations cost one driver call.

Open questions for the meeting:

1. Result shape: dict of frozensets (above) vs. an IntFlag-style value per operation.
2. Home: Device method vs. a property namespace (dev.properties-adjacent)?
3. Scope naming: peer= kwarg vs. separate host/p2p methods.
4. Version gating: 13.0+ (13.1 for the reduction attribute).

References

• Driver docs: https://docs.nvidia.com/cuda/cuda-driver-api/
• Found during the CUDA 12.8 → 13.3 bindings vs. cuda.core gap sweep (2026-07-14)

-- Leo's bot