fft.rst 13 KB
Newer Older
root's avatar
root committed
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
Fast Fourier Transform with CuPy
================================

CuPy covers the full Fast Fourier Transform (FFT) functionalities provided in NumPy (:mod:`cupy.fft`) and a
subset in SciPy (:mod:`cupyx.scipy.fft`). In addition to those high-level APIs that can be used
as is, CuPy provides additional features to

1. access advanced routines that `cuFFT`_ offers for NVIDIA GPUs,
2. control better the performance and behavior of the FFT routines.

Some of these features are *experimental* (subject to change, deprecation, or removal, see :doc:`./compatibility`)
or may be absent in `hipFFT`_/`rocFFT`_ targeting AMD GPUs.

.. _cuFFT: https://docs.nvidia.com/cuda/cufft/index.html
.. _hipFFT: https://hipfft.readthedocs.io/en/latest/
.. _rocFFT: https://rocfft.readthedocs.io/en/latest/


.. _scipy_fft_backend:

SciPy FFT backend
-----------------

Since SciPy v1.4 a backend mechanism is provided so that users can register different FFT backends and use SciPy's API to perform the actual transform
with the target backend, such as CuPy's :mod:`cupyx.scipy.fft` module. For a one-time only usage, a context manager :func:`scipy.fft.set_backend` can be used:

.. code-block:: python

    import cupy as cp
    import cupyx.scipy.fft as cufft
    import scipy.fft

    a = cp.random.random(100).astype(cp.complex64)
    with scipy.fft.set_backend(cufft):
        b = scipy.fft.fft(a)  # equivalent to cufft.fft(a)

However, such usage can be tedious. Alternatively, users can register a backend through :func:`scipy.fft.register_backend` or :func:`scipy.fft.set_global_backend`
to avoid using context managers:

.. code-block:: python

    import cupy as cp
    import cupyx.scipy.fft as cufft
    import scipy.fft
    scipy.fft.set_global_backend(cufft)

    a = cp.random.random(100).astype(cp.complex64)
    b = scipy.fft.fft(a)  # equivalent to cufft.fft(a)

.. note::

    Please refer to `SciPy FFT documentation`_ for further information.

.. note::
    To use the backend together with an explicit ``plan`` argument requires SciPy version 1.5.0 or higher.
    See below for how to create FFT plans.

.. _SciPy FFT documentation: https://docs.scipy.org/doc/scipy/reference/fft.html#backend-control


User-managed FFT plans
----------------------

For performance reasons, users may wish to create, reuse, and manage the FFT plans themselves. CuPy provides a high-level *experimental* API :func:`~cupyx.scipy.fftpack.get_fft_plan` for this need. Users specify the transform to be performed as they would with most of the high-level FFT APIs, and a plan will be generated based on the input.

.. code-block:: python

    import cupy as cp
    from cupyx.scipy.fft import get_fft_plan

    a = cp.random.random((4, 64, 64)).astype(cp.complex64)
    plan = get_fft_plan(a, axes=(1, 2), value_type='C2C')  # for batched, C2C, 2D transform

The returned plan can be used either explicitly as an argument with the :mod:`cupyx.scipy.fft` APIs:

.. code-block:: python

    import cupyx.scipy.fft

    # the rest of the arguments must match those used when generating the plan
    out = cupyx.scipy.fft.fft2(a, axes=(1, 2), plan=plan)

or as a context manager for the :mod:`cupy.fft` APIs:

.. code-block:: python

    with plan:
        # the arguments must match those used when generating the plan
        out = cp.fft.fft2(a, axes=(1, 2))


.. _fft_plan_cache:

FFT plan cache
--------------

However, there are occasions when users may *not* want to manage the FFT plans by themselves. Moreover, plans could also be reused internally in CuPy's routines, to which user-managed plans would not be applicable. Therefore, starting CuPy v8 we provide a built-in plan cache, enabled by default. The plan cache is done on a *per device, per thread* basis, and can be retrieved by the :func:`~cupy.fft.config.get_plan_cache` API.

.. code-block:: python

    >>> import cupy as cp
    >>>
    >>> cache = cp.fft.config.get_plan_cache()
    >>> cache.show_info()
    ------------------- cuFFT plan cache (device 0) -------------------
    cache enabled? True
    current / max size   : 0 / 16 (counts)
    current / max memsize: 0 / (unlimited) (bytes)
    hits / misses: 0 / 0 (counts)
    
    cached plans (most recently used first):
    
    >>> # perform a transform, which would generate a plan and cache it
    >>> a = cp.random.random((4, 64, 64))
    >>> out = cp.fft.fftn(a, axes=(1, 2))
    >>> cache.show_info()  # hit = 0
    ------------------- cuFFT plan cache (device 0) -------------------
    cache enabled? True
    current / max size   : 1 / 16 (counts)
    current / max memsize: 262144 / (unlimited) (bytes)
    hits / misses: 0 / 1 (counts)
    
    cached plans (most recently used first):
    key: ((64, 64), (64, 64), 1, 4096, (64, 64), 1, 4096, 105, 4, 'C', 2, None), plan type: PlanNd, memory usage: 262144
    
    >>> # perform the same transform again, the plan is looked up from cache and reused
    >>> out = cp.fft.fftn(a, axes=(1, 2))
    >>> cache.show_info()  # hit = 1
    ------------------- cuFFT plan cache (device 0) -------------------
    cache enabled? True
    current / max size   : 1 / 16 (counts)
    current / max memsize: 262144 / (unlimited) (bytes)
    hits / misses: 1 / 1 (counts)
    
    cached plans (most recently used first):
    key: ((64, 64), (64, 64), 1, 4096, (64, 64), 1, 4096, 105, 4, 'C', 2, None), plan type: PlanNd, memory usage: 262144
    
    >>> # clear the cache
    >>> cache.clear()
    >>> cp.fft.config.show_plan_cache_info()  # = cache.show_info(), for all devices
    =============== cuFFT plan cache info (all devices) ===============
    ------------------- cuFFT plan cache (device 0) -------------------
    cache enabled? True
    current / max size   : 0 / 16 (counts)
    current / max memsize: 0 / (unlimited) (bytes)
    hits / misses: 0 / 0 (counts)
    
    cached plans (most recently used first):
    

The returned :class:`~cupy.fft._cache.PlanCache` object has other methods for finer control, such as setting the cache size (either by counts or by memory usage). If the size is set to 0, the cache is disabled. Please refer to its documentation for more detail.

.. note::

    As shown above each FFT plan has an associated working area allocated. If an out-of-memory error happens, one may want to inspect, clear, or limit the plan cache.

.. note::

    The plans returned by :func:`~cupyx.scipy.fftpack.get_fft_plan` are not cached.


FFT callbacks
-------------

`cuFFT`_ provides FFT callbacks for merging pre- and/or post- processing kernels with the FFT routines so as to reduce the access to global memory.
This capability is supported *experimentally* by CuPy. Users need to supply custom load and/or store kernels as strings, and set up a context manager
via :func:`~cupy.fft.config.set_cufft_callbacks`. Note that the load (store) kernel pointer has to be named as ``d_loadCallbackPtr`` (``d_storeCallbackPtr``).

.. code-block:: python

    import cupy as cp

    # a load callback that overwrites the input array to 1
    code = r'''
    __device__ cufftComplex CB_ConvertInputC(
        void *dataIn,
        size_t offset,
        void *callerInfo,
        void *sharedPtr)
    {
        cufftComplex x;
        x.x = 1.;
        x.y = 0.;
        return x;
    }
    __device__ cufftCallbackLoadC d_loadCallbackPtr = CB_ConvertInputC;
    '''

    a = cp.random.random((64, 128, 128)).astype(cp.complex64)

    # this fftn call uses callback
    with cp.fft.config.set_cufft_callbacks(cb_load=code):
        b = cp.fft.fftn(a, axes=(1,2))

    # this does not use
    c = cp.fft.fftn(cp.ones(shape=a.shape, dtype=cp.complex64), axes=(1,2))

    # result agrees
    assert cp.allclose(b, c)

    # "static" plans are also cached, but are distinct from their no-callback counterparts
    cp.fft.config.get_plan_cache().show_info()


.. note::

    Internally, this feature requires recompiling a Python module *for each distinct pair* of load and store kernels. Therefore, the first invocation will be very slow, and this cost is amortized if the callbacks can be reused in the subsequent calculations. The compiled modules are cached on disk, with a default position ``$HOME/.cupy/callback_cache`` that can be changed by the environment variable ``CUPY_CACHE_DIR``.


Multi-GPU FFT
-------------

CuPy currently provides two kinds of *experimental* support for multi-GPU FFT.

.. warning::

    Using multiple GPUs to perform FFT is not guaranteed to be more performant. The rule of thumb is if the transform fits in 1 GPU, you should avoid using multiple.

The first kind of support is with the high-level :func:`~cupy.fft.fft` and :func:`~cupy.fft.ifft` APIs, which requires the input array to reside on one of the participating GPUs. The multi-GPU calculation is done under the hood, and by the end of the calculation the result again resides on the device where it started. Currently only 1D complex-to-complex (C2C) transform is supported; complex-to-real (C2R) or real-to-complex (R2C) transforms (such as :func:`~cupy.fft.rfft` and friends) are not. The transform can be either batched (batch size > 1) or not (batch size = 1).

.. code-block:: python

    import cupy as cp

    cp.fft.config.use_multi_gpus = True
    cp.fft.config.set_cufft_gpus([0, 1])  # use GPU 0 & 1

    shape = (64, 64)  # batch size = 64
    dtype = cp.complex64
    a = cp.random.random(shape).astype(dtype)  # reside on GPU 0

    b = cp.fft.fft(a)  # computed on GPU 0 & 1, reside on GPU 0

If you need to perform 2D/3D transforms (ex: :func:`~cupy.fft.fftn`) instead of 1D (ex: :func:`~cupy.fft.fft`), it would likely still work, but in this particular use case it loops over the transformed axes under the hood (which is exactly what is done in NumPy too), which could lead to suboptimal performance.

The second kind of usage is to use the low-level, *private* CuPy APIs. You need to construct a :class:`~cupy.cuda.cufft.Plan1d` object and use it as if you are programming in C/C++ with `cuFFT`_. Using this approach, your input array can reside on the host as a :class:`numpy.ndarray` so that its size can be much larger than what a single GPU can accommodate, which is one of the main reasons to run multi-GPU FFT.

.. code-block:: python

    import numpy as np
    import cupy as cp

    # no need to touch cp.fft.config, as we are using low-level API

    shape = (64, 64)
    dtype = np.complex64
    a = np.random.random(shape).astype(dtype)  # reside on CPU

    if len(shape) == 1:
        batch = 1
        nx = shape[0]
    elif len(shape) == 2:
        batch = shape[0]
        nx = shape[1]

    # compute via cuFFT
    cufft_type = cp.cuda.cufft.CUFFT_C2C  # single-precision c2c
    plan = cp.cuda.cufft.Plan1d(nx, cufft_type, batch, devices=[0,1])
    out_cp = np.empty_like(a)  # output on CPU
    plan.fft(a, out_cp, cufft.CUFFT_FORWARD)

    out_np = numpy.fft.fft(a)  # use NumPy's fft
    # np.fft.fft alway returns np.complex128
    if dtype is numpy.complex64:
        out_np = out_np.astype(dtype)

    # check result
    assert np.allclose(out_cp, out_np, rtol=1e-4, atol=1e-7)

For this use case, please consult the `cuFFT`_ documentation on multi-GPU transform for further detail.

.. note::

    The multi-GPU plans are cached if auto-generated via the high-level APIs, but not if manually generated via the low-level APIs.


Half-precision FFT
------------------

`cuFFT`_ provides ``cufftXtMakePlanMany`` and ``cufftXtExec`` routines to support a wide range of FFT needs, including 64-bit indexing and half-precision FFT. CuPy provides an *experimental* support for this capability via the new (though *private*) :class:`~cupy.cuda.cufft.XtPlanNd` API. For half-precision FFT, on supported hardware it can be twice as fast than its single-precision counterpart. NumPy does not yet provide the necessary infrastructure for half-precision complex numbers (i.e., ``numpy.complex32``), though, so the steps for this feature is currently a bit more involved than common cases.

.. code-block:: python

    import cupy as cp
    import numpy as np


    shape = (1024, 256, 256)  # input array shape
    idtype = odtype = edtype = 'E'  # = numpy.complex32 in the future

    # store the input/output arrays as fp16 arrays twice as long, as complex32 is not yet available
    a = cp.random.random((shape[0], shape[1], 2*shape[2])).astype(cp.float16)
    out = cp.empty_like(a)

    # FFT with cuFFT
    plan = cp.cuda.cufft.XtPlanNd(shape[1:],
                                  shape[1:], 1, shape[1]*shape[2], idtype,
                                  shape[1:], 1, shape[1]*shape[2], odtype,
                                  shape[0], edtype,
                                  order='C', last_axis=-1, last_size=None)

    plan.fft(a, out, cp.cuda.cufft.CUFFT_FORWARD)

    # FFT with NumPy
    a_np = cp.asnumpy(a).astype(np.float32)  # upcast
    a_np = a_np.view(np.complex64)
    out_np = np.fft.fftn(a_np, axes=(-2,-1))
    out_np = np.ascontiguousarray(out_np).astype(np.complex64)  # downcast
    out_np = out_np.view(np.float32)
    out_np = out_np.astype(np.float16)

    # don't worry about accruacy for now, as we probably lost a lot during casting
    print('ok' if cp.mean(cp.abs(out - cp.asarray(out_np))) < 0.1 else 'not ok')

The 64-bit indexing support for all high-level FFT APIs is planned for a future CuPy release.