pub unsafe extern "C" fn cutensorCreateBlockSparseTensorDescriptor(
handle: cutensorHandle_t,
desc: *mut cutensorBlockSparseTensorDescriptor_t,
numModes: u32,
numNonZeroBlocks: u64,
numSectionsPerMode: *const u32,
extent: *const i64,
nonZeroCoordinates: *const i32,
stride: *const i64,
dataType: cudaDataType_t,
) -> cutensorStatus_tExpand description
Create a block-sparse tensor descriptor.
A block-sparse tensor descriptor fully specifies the data layout of a block-sparse tensor (currently limited to up to 8 modes).
Let us consider an example for a block-sparse tensor of order 2, i.e., a block-sparse matrix A. Its first mode (rows) is subdivided into 5 sections (with extents 4, 2, 3, 4, 5, respectively), and its second mode (columns) is subdivided into 3 sections (with extents 2, 3, 7). The matrix has 8 non-zero blocks:
| 4 x 2 | 4 x 7 | |
| 2 x 3 | ||
| 3 x 3 | 3 x 7 | |
| 4 x 2 | ||
| 5 x 3 | 5 x 7 |
Notice that we require the same extent of each sub section across the entire mode, i.e., every block within the same section of a mode has the same extent. For example, in the above picture every block on the right has 7 colums, and all blocks on the bottom have 5 rows.
Moreover, we only store the non-zero blocks (blocks that are zero are left blank in the above representation).
To be precise, the above block-sparse tensor could be created via:
As an example:
-
strides of block #0: 5, 1, 10, 20. Sorted strides would be: 1, 5, 10, 20. The permutation to sort the strides in this case is to swap the first two elements.
-
strides of block #1: 10, 1, 30, 60. Applying the permutation would result in: 1, 10, 30, 60. The result is sorted in ascending order, this is allowed.
-
strides of block #2: 1, 5, 50, 100. Applying permuation would result in: 5, 1, 50, 100. The result is
notsorted in ascending order, this isnotallowed.Remark
non-blocking, no reentrant, and thread-safe.
ยงParameters
handle: The library handle.desc: The resulting block-sparse tensor descriptor.numModes: The number of modes. Currently, a maximum of 8 modes is supported.numNonZeroBlocks: The number of non-zero blocks in the block-sparse tensor.numSectionsPerMode: The number of sections of each mode (host array of sizenumModes).extent: The extents of the sections of each mode (host array of size\sum_i^numModes(numSectionsPerMode\[i\])). First come the extents of the sections of the first mode, then the extents of the sections of the second mode, and so forth.nonZeroCoordinates: Block-coordinates of each non-zero block (host array of sizenumModesxnumNonZeroBlocksBlocks can be specified in any order, however, that order must be consistent with stride and alignmentRequirement arrays.stride: The strides of each dense block (either nullptr or a host array of sizenumModesxnumNonZeroBlocks). First the strides of the first block, then the strides of the second block, with the blocks in the same order as in nonZeroCoordinates. Passing nullptr means contiguous column-major order for each block. Moreover, the strides need to be compatible in the following sense: Suppose you sort the strides of the first block, such that they are ascending; this sorting results in a permutation. If you apply this permutation to the strides of any other block, the result needs to be sorted as well.dataType: Data type of the stored entries. We assume the same datatype for each block. Currently, the only supported values arecudaDataType_t::CUDA_C_64F,cudaDataType_t::CUDA_C_32F,cudaDataType_t::CUDA_R_64F, andcudaDataType_t::CUDA_R_32F.