ACloudViewer  3.9.4
A Modern Library for 3D Data Processing
DLTensor Struct Reference

Plain C Tensor object, does not manage memory. More...

#include <DLPack.h>

Collaboration diagram for DLTensor:

Public Attributes

void * data
 The data pointer points to the allocated data. This will be CUDA device pointer or cl_mem handle in OpenCL. It may be opaque on some device types. This pointer is always aligned to 256 bytes as in CUDA. The byte_offset field should be used to point to the beginning of the data. More...
 
DLDevice device
 The device of the tensor. More...
 
int32_t ndim
 Number of dimensions. More...
 
DLDataType dtype
 The data type of the pointer. More...
 
int64_t * shape
 The shape of the tensor. More...
 
int64_t * strides
 strides of the tensor (in number of elements, not bytes), can not be NULL if ndim != 0, must points to an array of ndim elements that specifies the strides, so consumer can always rely on strides[dim] being valid for 0 <= dim < ndim. More...
 
uint64_t byte_offset
 The offset in bytes to the beginning pointer to data. More...
 

Detailed Description

Plain C Tensor object, does not manage memory.

Definition at line 244 of file DLPack.h.

Member Data Documentation

◆ byte_offset

uint64_t DLTensor::byte_offset

The offset in bytes to the beginning pointer to data.

Definition at line 302 of file DLPack.h.

◆ data

void* DLTensor::data

The data pointer points to the allocated data. This will be CUDA device pointer or cl_mem handle in OpenCL. It may be opaque on some device types. This pointer is always aligned to 256 bytes as in CUDA. The byte_offset field should be used to point to the beginning of the data.

Note that as of Nov 2021, multiple libraries (CuPy, PyTorch, TensorFlow, TVM, perhaps others) do not adhere to this 256 byte alignment requirement on CPU/CUDA/ROCm, and always use byte_offset=0. This must be fixed (after which this note will be updated); at the moment it is recommended to not rely on the data pointer being correctly aligned.

For given DLTensor, the size of memory required to store the contents of data is calculated as follows:

static inline size_t GetDataSize(const DLTensor* t) {
size_t size = 1;
for (tvm_index_t i = 0; i < t->ndim; ++i) {
size *= t->shape[i];
}
size *= (t->dtype.bits * t->dtype.lanes + 7) / 8;
return size;
}
int size
uint16_t lanes
Number of lanes in the type, used for vector types.
Definition: DLPack.h:238
uint8_t bits
Number of bits, common choices are 8, 16, 32.
Definition: DLPack.h:236
Plain C Tensor object, does not manage memory.
Definition: DLPack.h:244
int32_t ndim
Number of dimensions.
Definition: DLPack.h:278
int64_t * shape
The shape of the tensor.
Definition: DLPack.h:286
DLDataType dtype
The data type of the pointer.
Definition: DLPack.h:280

Note that if the tensor is of size zero, then the data pointer should be set to NULL.

Definition at line 274 of file DLPack.h.

◆ device

DLDevice DLTensor::device

The device of the tensor.

Definition at line 276 of file DLPack.h.

◆ dtype

DLDataType DLTensor::dtype

The data type of the pointer.

Definition at line 280 of file DLPack.h.

◆ ndim

int32_t DLTensor::ndim

Number of dimensions.

Definition at line 278 of file DLPack.h.

◆ shape

int64_t* DLTensor::shape

The shape of the tensor.

When ndim == 0, shape can be set to NULL.

Definition at line 286 of file DLPack.h.

◆ strides

int64_t* DLTensor::strides

strides of the tensor (in number of elements, not bytes), can not be NULL if ndim != 0, must points to an array of ndim elements that specifies the strides, so consumer can always rely on strides[dim] being valid for 0 <= dim < ndim.

When ndim == 0, strides can be set to NULL.

Note
Before DLPack v1.2, strides can be NULL to indicate contiguous data. This is not allowed in DLPack v1.2 and later. The rationale is to simplify the consumer handling.

Definition at line 300 of file DLPack.h.


The documentation for this struct was generated from the following file: