Configuring data layouts
This page describes how to configure a descriptor object for a specific data layout. When non-native, all the relevant types and enumerations mentioned below belong to the oneapi::mkl::dft namespace and are declared in oneapi/mkl/dft.hpp (file to be included). The usage of prepended namespace specifiers oneapi::mkl::dft is omitted below for conciseness.
The DPC++ interface provides the configuration parameter config_param::FWD_STRIDES (resp. config_param::BWD_STRIDES) to define the data layout locating entries (or parts thereof) of relevant data sequences in the forward (resp. backward) domain. In case of batched transforms, i.e., if the configuration value for config_param::NUMBER_OF_TRANSFORMS is set to an integer 
larger than 
, the value set for configuration parameter config_param::FWD_DISTANCE (resp. config_param::BWD_DISTANCE) completes the description of the data layout by specifying the distances between successive data sequences in the forward (resp. backward) domain.
This topic leverages the general notations from the introduction, and uses the superscript 
(resp. 
) for data sequences in forward (resp. backward) domain. A placeholder label 
is also used to capture a possible distinction between the real (if is 
) and imaginary (if is 
) parts of a complex data entry; naturally, that placeholder label is relevant only for data layouts that distinguish real and imaginary parts of complex data entries.
A non-redundant entry 
(or its real or imaginary part, if relevant) is stored at index 
of the appropriate data container (sycl::buffer object or device-accessible USM allocation) provided to a compute function, the base data type of which is (possibly implicitly re-interpreted as) documented in the table below. That index value is defined as
wherein
, 
represents the offset and generalized strides defining the locations of relevant values within each 
-dimensional data sequence in the forward (resp. backward) domain if 
(resp. if 
), counted in number of elements of the relevant implicitly-assumed elementary data type;
represents the distance between successive -dimensional data sequences in the forward (resp. backward) domain if (resp. if ), counted in number of elements of the relevant implicitly-assumed elementary data type;the relation
simplifies into the identity 
in all recommended use cases or if , i.e., is either irrelevant or unused in such cases.
In this page, it is assumed that only non-redundant data sequence entries are of interest, i.e., that 
, 
and that 
(resp. 
) for entries that do (resp. do not) belong the backward domain of a real DFT.
Note that all elements accessed as a value stored at index of a given user-provided data container must belong to the same block allocation.
Implicitly-assumed elementary data type
When reading or writing an element at index of any user-provided data container used at compute time, a descriptor object may first re-interpret the base data type of that data container into an implicitly-assumed elementary data type. That implicitly-assumed data type depends on the object type; that is, on the specialization values used for the template parameters when instantiating the descriptor class, and on other configuration value(s). The table below lists the implicitly-assumed data type in either domain (last 2 columns) based on the object type and its configuration value(s).
Type of descriptor and relevant configuration values |
Implicitly-assumed elementary data type in forward domain |
Implicitly-assumed elementary data type in backward domain |
|---|---|---|
Complex descriptor with config_value::COMPLEX_COMPLEX set for config_param::COMPLEX_STORAGE |
std::complex<fp_type> |
std::complex<fp_type> |
Complex descriptor with config_value::REAL_REAL set for config_param::COMPLEX_STORAGE |
fp_type |
fp_type |
Real descriptor |
fp_type |
std::complex<fp_type>` |
Descriptors that implicitly assume an elementary data type of float or double (resp. std::complex<float> or std::complex<double>) in a domain are referred to as “descriptors expecting real (resp. complex) data” in that domain.
Configuring strides in forward and backward domains
The values 
defining are to be communicated as elements (in that order) of a std::vector<std::int64_t> object of size 
, passed as the configuration value for config_param::FWD_STRIDES if (resp. config_param::BWD_STRIDES if ) using the relevant configuration-setting member function. The element 
represents an absolute offset (or “displacement”) in the data sets while the subsequent elements 
are generalized strides to be considered along dimensions 
.
When created, the descriptors are default-configured for unbatched, in-place transforms using a unit stride along the last dimension, no offset and the default configuration settings documented in the above table. For real descriptors, minimal padding is used in forward domain, aligning with the data layout requirements for in-place transforms.
In other words, the default stride values are 
, 
and, for -dimensional transforms with 
,
for complex descriptors;
, and 
for real descriptors;if
, 
for 
(for and ).
The usage of these default strides for unbatched, in-place transforms is illustrated in the usage examples.
Configuring batched transforms
The value completing the definition of is to be set as an std::int64_t configuration value for config_param::FWD_DISTANCE if (resp. config_param::BWD_DISTANCE if ) using the relevant configuration-setting member function. This value is irrelevant for unbatched transforms, i.e., for descriptors set to handle a number of transforms equal to (default behavior).
In case of batched transforms, the desired number of DFTs must be set explicitly as an std::int64_t configuration value config_param::NUMBER_OF_TRANSFORMS using the relevant configuration-setting member function. In that case, config_param::FWD_DISTANCE and config_param::BWD_DISTANCEmust also be set explicitly since their default configuration values of 
would break the data layout requirements for any 
.
The configuration of batched transforms is illustrated in the usage examples.
Data layout requirements
In general, the distances and strides must be set so that
values of
are non-negative for all -tuples 
within relevant ranges;every value of
corresponds to a unique value relevant to the data sequences under consideration. In other words, there must not be one value of corresponding to two different -tuples that would both be within relevant ranges.
Additionally, for in-place transforms (configuration value config_value::INPLACE set for config_param::PLACEMENT), the following “consistency requirements” apply:
descriptors expecting the same data type in either domain (e.g., complex descriptors) must use the same offset, stride(s), and distance values in forward and backward domains;
for real descriptors expecting complex data in backward domain (default behavior for real descriptors), the memory address(es) of leading entry(ies) along the last dimension must be identical in forward and backward domains. Specifically, that requirement translates into the conditions
as well as, if , 
. Note that this requirement leads to some data padding to be used in forward domain if unit strides are used along dimension in forward and backward domains (recommended usage, as set by default).
- Support for negative strides with a sufficiently large (positive) offset index guaranteeing non-negativeness of all is not enabled yet (unimplemented);
Supported layouts on GPU devices
On GPU devices, oneMKL requires
the rank
of the transform to be no greater than 
;the offset values
and 
to be ;either
or 
for batched, two-dimensional real transforms (for and);either
(along with if ) or 
(along with if ) for three-dimensional real transforms (for and);real descriptors require real data in the forward domain and complex data(non-redundant entries) in the backward domain.