You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
CUDA 13.3 introduces logical endpoints
(driver docs):
ID-addressed endpoints that memory allocations are bound to, in two flavors:
unicast — single-device endpoint; a designated owner device manages the binding
multicast — a team of devices shares the bound allocation
Endpoints are created on reserved ID ranges, constructed asynchronously (completion polled via cuLogicalEndpointQuery), and shareable across processes via fabric IPC handles. A CU_LOGICAL_ENDPOINT_FLAG_COUNTED_OPS flag declares intent to use counted operations. Four new
device attributes advertise support. cuda.bindings 13.3.x exposes all of it; cuda.core uses
none of it.
Structurally this generalizes the cuMulticast* flow (add-device / bind-mem / bind-addr /
unbind) that #2057 proposes to wrap. The driver docs do not state a formal relationship between
the two API families, but the two designs should be settled together — e.g. build MulticastObject on logical endpoints when available (driver ≥ 13.3), with classic cuMulticast* as fallback.
New device attributes (also listed in the separate device-attributes catch-up item): CU_DEVICE_ATTRIBUTE_LOGICAL_ENDPOINT_{UNICAST,MULTICAST,COUNTED_OPS,UNICAST_ACCESS_ON_OWNER_DEVICE}_SUPPORTED.
Starting point only, not a settled design — to be reviewed in the cuda.core design
meeting, together with #2057.
ep=LogicalEndpoint( # all names TBD; reserves an ID + createssize=nbytes,
kind="multicast", # or "unicast"devices=[dev0, dev1], # multicast team (unicast: the owner device)counted_ops=False,
)
ep.bind(vmm_buffer, endpoint_offset=0) # BindMem vs BindAddr chosen from input typehandle=ep.export() # fabric handle (bytes-like)peer_ep=LogicalEndpoint.from_handle(handle) # import in another process
Open questions for the meeting:
ID-range reservation: hide it (one ID per object) or expose batch reserve+create for
scale-out patterns (cuLogicalEndpointQuery polls a whole range at once)?
Async construction: block in the constructor, or expose an is_ready-style waiter?
bind() inputs: Buffer backed by VirtualMemoryResource (owns the CUmemGenericAllocationHandle) vs. raw pointers — support both?
Summary
CUDA 13.3 introduces logical endpoints
(driver docs):
ID-addressed endpoints that memory allocations are bound to, in two flavors:
Endpoints are created on reserved ID ranges, constructed asynchronously (completion polled via
cuLogicalEndpointQuery), and shareable across processes via fabric IPC handles. ACU_LOGICAL_ENDPOINT_FLAG_COUNTED_OPSflag declares intent to use counted operations. Four newdevice attributes advertise support.
cuda.bindings13.3.x exposes all of it;cuda.coreusesnone of it.
Structurally this generalizes the
cuMulticast*flow (add-device / bind-mem / bind-addr /unbind) that #2057 proposes to wrap. The driver docs do not state a formal relationship between
the two API families, but the two designs should be settled together — e.g. build
MulticastObjecton logical endpoints when available (driver ≥ 13.3), with classiccuMulticast*as fallback.Underlying C APIs to cover
cuLogicalEndpointIdReserve(CUlogicalEndpointId* baseLeId, cuuint32_t count)/cuLogicalEndpointIdRelease(baseLeId, count)cuLogicalEndpointCreate(CUlogicalEndpointId leId, const CUlogicalEndpointProp* prop)/cuLogicalEndpointDestroy(leId)cuLogicalEndpointAddDevice(leId, CUdevice dev)cuLogicalEndpointBindMem(leId, dev, offset, CUmemGenericAllocationHandle memHandle, memOffset, size, flags)cuLogicalEndpointBindAddr(leId, dev, offset, void* ptr, size, flags)cuLogicalEndpointUnbind(leId, dev, offset, size)cuLogicalEndpointExport(void* handle, leId, CUlogicalEndpointIpcHandleType)/cuLogicalEndpointImport(leId, handle, handleType)..._IPC_HANDLE_TYPE_FABRIC)cuLogicalEndpointQuery(leId, cuuint32_t count, int* queryStatus)cuLogicalEndpointGetLimits(cuuint64_t* bindAlignment, cuuint64_t* maxSize, const CUlogicalEndpointProp*)Supporting types:
CUlogicalEndpointId,CUlogicalEndpointProp(type,unicast.device/multicast.numDevices,size,ipcHandleTypes,flags),CUlogicalEndpointFabricHandle;enums
CUlogicalEndpointType,CUlogicalEndpointFlag,CUlogicalEndpointIpcHandleType.New device attributes (also listed in the separate device-attributes catch-up item):
CU_DEVICE_ATTRIBUTE_LOGICAL_ENDPOINT_{UNICAST,MULTICAST,COUNTED_OPS,UNICAST_ACCESS_ON_OWNER_DEVICE}_SUPPORTED.Design sketch (draft — needs design-meeting review)
Important
Starting point only, not a settled design — to be reviewed in the cuda.core design
meeting, together with #2057.
Open questions for the meeting:
scale-out patterns (
cuLogicalEndpointQuerypolls a whole range at once)?is_ready-style waiter?bind()inputs:Bufferbacked byVirtualMemoryResource(owns theCUmemGenericAllocationHandle) vs. raw pointers — support both?References
-- Leo's bot