CUFFT moving from 3.0 to 3.2


I’m working on a Windows 7 64bit + GTX 460 with Visual Studio 2010, C# project, Dot.Net framework 4.0.

I worked with CUDA 3.0 and upgraded to 3.2 (32bit)

I tried to do a simple FFT test with the new framework and while it worked under 3.0, under 3.2 there seems to be some problems already in the plan creation stage.

This is how I import the function:


public static extern CUFFTResult cufftPlanMany(ref cufftHandle plan, int rank, [In, Out] int[] n, IntPtr inembed, int istride, int idist, IntPtr onembed, int ostride, int odist, CUFFTType type, int batch);

And this is how I try to generate a plan:

int[] R = new int[1];

R[0] = 128;	

this.LastError = CUFFTDriver.cufftPlanMany(ref plan,



 	IntPtr.Zero, 1, 0,

 	IntPtr.Zero, 1, 0,



This is cufftHandle:


public struct cufftHandle


public uint handle;


The above code worked fine under CUDA 3.0 but doesn’t work under CUDA 3.2. No exceptions are thrown and the system just gets stuck when executing cufftPlanMany.

All the functions under nvcuda32 seems to work fine…

Any help would be appreciated.



Are you using CUDA.NET? I’m pretty sure the last CUDA.NET version (3.0.0) only supports cuda 3.0 API. (and not 3.2)

good luck,


Hi Eldad,

No, I have my own implementation (as posted above…). I checked CUDA.NET and it is true that there is no version that support 3.2 (mostly as the pointers in 3.2 are 64bit instead of 32bit)

I was able to work with 3.2 under C# but for some reason I still can’t get the FFT library to work.



I was wondering, did you eventually managed to run the fft?

I also moved to 3.2 a while ago and found some very strange “features” in the new version…

  1. first time exceptions are thrown when cufft.dll is loaded (they are cought - but the exceptions were not thrown in 3.0, and it’s not clear why they are thrown now)

  2. Plans take much more memory. (this could have something to do with your problem… maybe you are running out of memory)

  3. the first valid plan is 0 (and not 1 - like in 3.0) so basically there is a null pointer that you need to actually use …


I am not very familiar with CUFFT, but regarding item (3), the plan creation via cufftPlan1D(), cufftPlan2D() returns a cufftHandle, not a pointer. By definition, handles are opaque objects, and their encoding should not matter to the calling application.