VkFFT: Vulkan/CUDA/Hip/OpenCL/Level Zero/Metal Fast Fourier Transform Library

I propose Fastest Fourier Transform in the South by Southwest (FFTSXSW).

I had this complaint myself not long ago, but Vulkan isn't targeted at new computer graphics programmers just learning about the graphics pipeline, or vertex and fragment shaders. It's certainly not optimised for the 'hello triangle' use case—your complaint is equivalent to someone saying 'why do I need #include <cstdio>, and a main() just to print "hello world"?' A lot of that boilerplate is write-once, meaning it's first-time setup that will never have to be done again after actually initialising the GPU. You'll find that extending that example to include texture mapping, mipmapping, supersampling, and even GPU compute will be a lot easier than the initial code.

Vulkan is targeted at graphics and game engine developers who want to extract the maximum possible performance from their GPUs and know the limitations of a global-state API like OpenGL. Vulkan allows extremely fine-grained pipeline management and synchronisation primitives, and adds in hardware ray-tracing support natively without having to uncannily bolt it on.

If all you want is to draw a three-coloured triangle, you can do that easier and faster with ShaderToy instead of fudging with Vulkan. If you want to write a fast, powerful, modern graphics engine, then you use Vulkan or D3D12.

People forget that GPUs are now massive slices of silicon with memory and power subsystems in their own right, and are obviously extremely powerful hardware. At some point, OpenGL itself becomes a bottleneck, or is difficult enough to program with that Vulkan becomes easier, and that's when the true utility and power of its extreme verbosity is displayed.

For the record, the boilerplate isn't '921 lines of nothing'—it's effectively setting the GPU up from scratch, similar to bootstrapping a CPU from 16-bit real mode.

At least DirectX comes with better tooling and documentation.

Other option is Tinygrad [1] that has a WEBGPU backend and it works very for my case (Unet 3D).

[1] - https://tinygrad.org/

getiin' old, it's the second time today I miss the obvious, clearly visible, information :-(

Did NVIDIA's ascent to a 1T company result primarily from their substantial software investments, or is there another element that AMD needs to focus on to achieve similar recognition and adoption in the realm of GPU compute?

Right, I know, but what's the advantage of gpu vs cpu for fft, considering cpu-s support some vectorization and you need to format the data and send it to the gpu and back.

Nvidia has something they call cuFFTW. Its basically a drop-in replacement for FFTW.

That's the kind of stuff Nvidia has offered for the last decade while AMD did god knows what.

https://docs.nvidia.com/cuda/cufft/index.html

That tut only shows you how to remix existing operators. That obviously won't work here (not what's required). You need to do this

https://pytorch.org/tutorials/advanced/dispatcher.html

More complex but still not that hard.

But not backed by VkFFT. The implication of the comment is that it would make FFTs on various backends easier if it was implemented on VkFFT in the first place. Not sure that's true though, as I don't know how much code the various backends share.

Edit: as an example that I experienced first-hand, coremltools, which converts PyTorch to CoreML models, only gained FFT support very recently. It's also not really a PyTorch backend but a PyTorch code converter, though, so wouldn't benefit at all from PyTorch's FFT being backed by VkFFT. Still, good example that one shouldn't take FFTs for granted.

Of course, but CuFFT is half the speed of VkFFT.