Dynamic size FFTs or cuFFT built FFT plans with cuFFTDx?

Hi everybody! I am working on making a program that requires many FFT transforms in both C2R and R2C directions from within a kernel. To that end I already found the cuFFTDx library. However, one of the first lines in the documentation is the following:

The correctness of this type is evaluated at compile time. A well-defined FFT must include the problem size, the precision used (float, double, etc.), the type of operation (complex-to-complex, real-to-complex, etc.), and its direction (forward, or inverse).

Unfortunately the FFTs I am dealing with will not be of a size that will be known at compile time. Is there some way to maybe define an FFT at runtime or perhaps use an FFT as defined by the standard cuFFT library?

(1) How many different sizes do you expect to handle?
(2) Have you considered zero-padding the FFT?

The sizes will be provided by users so they could really be anything (within some range of course, but too big to make for instance a big group of presets. I assume by zero padding you mean making the FFT as big as possible and then just not using the numbers beyond the given size?

I am not an FFT expert. As far as I know using zero-padding to adjust the length of an FFT to, say, the next power of 2, to achieve higher performance is fairly common.

What my questions were driving at: Is there a suitable way to map FFTs of arbitrary size down to a smallish number of fixed-length FFTs, in which case one could use a template, instantiate it for those sizes, and invoke the appropriate instance at runtime.

The sizes will be provided by users so they could really be anything

You’re going to be better off using cuFFT.