1D Real FFT Issue on MIC

[Aljosa_V_]

I am compiling code included below into a native MIC application.  The executable is deployed via Windows COI API.  If I put a break point after the DftiComputeForward() call and display memory contents of x & y, I see that the input data has been clobbered by the call and y is unchanged (or has been overwritten with the identical values of 0).  I looked over the documentation and would expect MKL to use y as an output instead of performing FFT in place since DFTI_REAL has been specified as the forward domain in the DftiCreateDescriptor() call.

Is this a BUG or am I using the MKL API wrong.

Host OS: Windows 7

MKL version: 11.1.2.176 (w_mkl_11.1.2.176.exe)

Cheers,

Al

    float x[512];
    float y[512];

    MKL_LONG status;

    for(int_t i=0; i<64; i++) {
        x = (float)i;
        y = 0;
    }
    DFTI_DESCRIPTOR_HANDLE dscHnd;
    status = DftiCreateDescriptor(&dscHnd, DFTI_SINGLE, DFTI_REAL, 1, 8);
    if(status != 0) {
        goto _err;
    }
    status = DftiCommitDescriptor(dscHnd);
    if(status != 0) {
        goto _err;
    }
    status = DftiComputeForward(dscHnd, (float *)x, (float *)y);
    if(status != 0) {
        goto _err;
    }
    DftiFreeDescriptor(&dscHnd);

[Evgueni_P_Intel]

Dear Aljosa,

By default, MKL FFTs are in-place.

To do an out-of-place transform, please add the following line before DftiCommitDescriptor.

DftiSetValue(DFTI_PLACEMENT, DFTI_NOT_IN_PLACE);

I also recommend reading the section about the DFTI_PACKED_FORMAT value in the MKL Reference Manual.

Thank you.

Evgueni.

[Aljosa_V_]

Thanks Evgueni,

That explains it.  I expected the MKL to automatically assume I am interested in a not-in-place case since I used function call that provides both x & y as opposed to the one that only supplies x_inout.  

Regards,

Al