The nomenclature used by CUFFT for the dimensions is consistent with FFTW:
“…nx and ny in fftw2d_create_plan are positive integers specifying the dimensions of the rank 2 array to be transformed. i.e. they specify that the transform will operate on nx x ny arrays in row-major order, where nx is the number of rows and ny is the number of columns.”
I am not familiar with the convolutionFFT2D example (I assume it’s from the CUDA SDK). If it does not work correctly as shipped with CUDA 4.1 RC1, I would suggest filing a bug.
I see, maybe you could add this explanation to the docs somewhere - they shouldn’t assume that someone is already familiar with FFTW, and this convention is very counter-intuitive to anyone with a graphics background.
The SDK sample works fine as it already inputs the dimensions correctly - it was just to illustrate the strange x/y ordering.
Best I can tell the CUFFT documentation describes the behavior correctly and cleary, so I see no need to augment it. I mentioned FFTW as another data point that shows that the naming convention used by CUFFT is not unusual in the context of FFTs. Why FFT folks prefer that convention, I do not know.
I see you are correct - I missed this in the docs (from “CUFFT Transform Types”):
“For higherâ€dimensional transforms (2D and 3D), CUFFT performs FFTs in rowâ€major or C order. For example, if the user requests a 3D transform plan for sizes X, Y, and Z, CUFFT transforms along Z, Y, and then X. The user can configure columnâ€major FFTs by simply changing the order of the size parameters to the plan creation API functions.”