Batched FFT with varying input distance

[henricryden]

Hi

I'm switching my fft implementation from fftw to MKL and I'm having trouble setting up batched FFT's with varying input distance. For instance, lets say I have a float array of size [32, 320, 12], strides [1, 32, 10240] and I want to perform 1D FFT along the second dimension. Then this would be my descriptor:

DftiCreateDescriptor(&plan, DFTI_SINGLE, DFTI_COMPLEX, 1, 320);
std::vector<MKL_LONG> input_strides(4);
input_strides[0] = 0; // MKL convention
input_strides[1] = 1;
input_strides[2] = 32;
input_strides[3] = 10240;
plan_, DFTI_INPUT_STRIDES, input_strides.data());

The number of transforms (or batches) is 32*12 = 382:

DftiSetValue(plan, DFTI_NUMBER_OF_TRANSFORMS,  382);

How do I set DFTI_INPUT_DISTANCE (as required when DFTI_NUMBER_OF_TRANSFORMS > 1)?

In fftw , you specify the size and strides of all batched dimensions (howmany_dims), but MKL seems to only support a scalar distance?

In the example above, the distance varies (12 sub-batches 10240 elements apart, each with 32 FFT's of unit distance 1).

Any help is appreciated

[Mahan]

Hi Henric,

In MKL, when you have multiple batches of FFTs with varying input distances, you need to set the DFTI_INPUT_DISTANCE configuration parameter to the maximum distance between the start of consecutive input data sets.

In your case, where you have a float array of size [32, 320, 12] with strides [1, 32, 10240], and you want to perform 1D FFTs along the second dimension (size 320) with 32*12 = 384 batches, the maximum input distance would be 10240.

Here's how you can set it up:

DftiCreateDescriptor(&plan, DFTI_SINGLE, DFTI_COMPLEX, 1, 320);

std::vector<MKL_LONG> input_strides(4);

input_strides[0] = 0; // MKL convention

input_strides[1] = 1;

input_strides[2] = 32;

input_strides[3] = 10240;

DftiSetValue(plan, DFTI_INPUT_STRIDES, input_strides.data());

DftiSetValue(plan, DFTI_NUMBER_OF_TRANSFORMS, 384);

DftiSetValue(plan, DFTI_INPUT_DISTANCE, 10240);

By setting DFTI_INPUT_DISTANCE to 10240, you're telling MKL that the maximum distance between the start of consecutive input data sets is 10240. This way, MKL can correctly handle the varying input distances for each batch of FFTs.

Note that you don't need to specify the strides or distances for the batched dimensions explicitly, as MKL will automatically compute them based on the DFTI_INPUT_DISTANCE and DFTI_NUMBER_OF_TRANSFORMS values.

Also, make sure to call DftiCommitDescriptor after setting all the required configuration parameters before computing the FFTs.

[henricryden]

Thanks for the attempt; I suppose I did say any help is appreciated, but it's clear your solution wasn't tested. Setting DFTI_INPUT_DISTANCE to 10240 assumes all transforms are equally spaced by that amount. My case involves varying distances.

You're suggesting that MKL automatically computes the strides and distances for batched dimensions, but if that's the case, how can MKL differentiate between a request for 384 transforms each spaced 10240 apart, and the scenario where input distances vary?

If you had actually tried running this instead of just posting what seems like a response from ChatGPT (which, incidentally, is nearly identical to what you wrote), you would have realized it causes a segmentation fault.

[Mahan]

Hi Henric,

Sorry for the late reply.

I understand the complexity of the issue you mentioned.

I am raising a feature request for this.

If we want to perform batched 1D FFTs in the first or third direction, we can modify stride and distance to run just one batched FFT to get it done. The tricky problem is doing such FFTs in the second direction.

It would be either

1. 12 sub-batches, each with 32 FFTs of distance 3840 and each 1D FFT with stride 12 or
2. 32 sub-batches, each with 12 FFTs of distance 1 and each 1d FFT with stride 12

Currently, oneMKL FFT doesn't have the feature to have one batched FFT in the second direction with variable/constant input distances.

[Mahan]

Hi Henric,

The feature request has been communicated with the development team, and the feasibility of whether it's going to be implemented or not is under consideration. Once I have a clearer picture, I will let you know.

[henricryden]

Thank you for considering implementing this feature

[Mahan]

Henric,

The feasibility of this feature is under consideration. As of now, there is now specific ETA on this.

[Mahan]

Henric,

The feasibility of this feature is under consideration. As of now, there is no specific ETA on this.