Struct CudaHandle 

pub struct CudaHandle { /* private fields */ }

CUDA registration for a GPU-backed tensor. Held as Option on the tensor.

Implementations

impl CudaHandle

pub fn new_gl( resource: *mut c_void, size: usize, ops: Arc<dyn CudaGlOps>, ) -> Self

Construct a GL-buffer-backed CUDA handle. resource is the cudaGraphicsResource_t returned by gl_register_buffer; ops routes map/unmap/unregister back to the GL-context thread.

pub fn map(&self) -> Option<CudaMap<'_>>

Map to a device pointer. GlBuffer routes to the GL worker; ExternalMem is persistent (no per-call map/unmap); D3d11 copies the texture’s array into its linear buffer, after waiting for the newest fence value recorded on the tensor.

The D3d11 mapping is the texture’s tight rows: len() is width * bytes_per_texel * height and row n starts at n * width * bytes_per_texel, whatever the tensor’s row_stride reports – that is the D3D11 staging pitch a CPU map sees, a different number on a padded backing. A consumer that strides the device pointer by row_stride() walks off the end of the mapping.

Semi-planar textures (NV12, NV16, NV24) are the exception: the texture is as wide as its pitch by construction, so the mapping equals row_stride() x combined_height bytes and striding by row_stride() is exactly right.

One D3d11 handle has one linear buffer, so two live maps of the same tensor hand out the same device pointer and the second map’s copy refreshes what the first is reading. That is the same aliasing the GL and external-memory backings have always had – one buffer per handle, not one per map. A map() taken while a map_mut guard is live is the case that also loses data: it refreshes the buffer under the writer, and the writer’s release then publishes the array’s pre-write contents back into the texture. Callers serialise the two.

pub fn map_mut(&self) -> Option<CudaMap<'_>>

Map to a device pointer for writing.

The GL and external-memory backings alias the same device memory for reads and writes – a GL buffer’s CUDA mapping and an imported external-memory allocation are each one address the caller may write through – so for them this is map. A D3d11 texture is the backing that does distinguish the two: its linear buffer is a copy of an opaque array, so the map’s release copies it back into the texture and synchronises, and later D3D11 and GL work on the immediate context is ordered after that write.

The D3d11 mapping is the texture’s tight rows: len() is width * bytes_per_texel * height and row n starts at n * width * bytes_per_texel, whatever the tensor’s row_stride reports – that is the D3D11 staging pitch a CPU map sees, a different number on a padded backing. A consumer that strides the device pointer by row_stride() walks off the end of the mapping.

Semi-planar textures (NV12, NV16, NV24) are the exception: the texture is as wide as its pitch by construction, so the mapping equals row_stride() x combined_height bytes and striding by row_stride() is exactly right.

Trait Implementations

impl Debug for CudaHandle

fn fmt(&self, f: &mut Formatter<'_>) -> Result

Formats the value using the given formatter.

impl Drop for CudaHandle

fn drop(&mut self)

Executes the destructor for this type.

fn pin_drop(self: Pin<&mut Self>)

🔬This is a nightly-only experimental API. (pin_ergonomics)

Execute the destructor for this type, but different to Drop::drop, it requires self to be pinned.