[BUG]: FFT sample launches `Batch` blocks that each process the full batch

Version

1.5.0

Version

13.3

Describe the bug.

In samples/FFT.py, cutile_fft() sets the kernel constant BS to the full batch size (BS = x.shape[0], line 274) and also launches grid = (BS, 1, 1) (line 315). Inside fft_kernel every block loads a (BS, N*2//D, D) tile at index (bid, 0, 0) — i.e. every block loads and transforms the entire batch, then writes it out. The result is numerically correct, but the work is O(Batch²) instead of O(Batch), and the kernel spills registers / shared memory at modest batch sizes.

Expected: one block per batch item (or per fixed-size minibatch), with the grid sized Batch // BS, so cost scales linearly with batch.

Measured on a DGX Spark, N=512, batch=64, factors=(8,8,8), twiddles precomputed: kernel time 2376 µs -> 12 µs (~200x) after fixing the grid/BS relationship.

Contributing Guidelines

• I agree to follow cuTile Python's contributing guidelines
• I have searched the open bugs and have found no duplicates for this bug report

Inizia in samples/FFT.py, in cutile_fft(), intorno all’assegnazione di BS alla riga 274 e al lancio di grid alla riga 315, quindi leggi fft_kernel per tracciare come bid seleziona il proprio tile. Esegui l’esempio FFT con la configurazione indicata N=512 e batch=64 e verifica che l’output rimanga numericamente corretto mentre il lavoro del kernel e il tempo di esecuzione scalano linearmente con batch.