Skip to main content

cutensorCreateBlockSparseTensorDescriptor

Function cutensorCreateBlockSparseTensorDescriptor 

Source
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_t
Expand 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 24 x 7
2 x 3
3 x 33 x 7
4 x 2
5 x 35 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 not sorted in ascending order, this is not allowed.

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 size numModes).
  • 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 size numModes x numNonZeroBlocks Blocks 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 size numModes x numNonZeroBlocks). 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 are cudaDataType_t::CUDA_C_64F, cudaDataType_t::CUDA_C_32F, cudaDataType_t::CUDA_R_64F, and cudaDataType_t::CUDA_R_32F.