Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

VkFFT – Vulkan Fast Fourier Transform Library

github.com

Post reply on HN
Print view View original

111–120 of 132 posts

Re: VkFFT – Vulkan Fast Fourier Transform Library

#111

Post by DTolm »

datenwolf wrote: post #108
DTolm wrote: post #106

Earlier quoted context omitted.

I use the averaged data of 1000 merged launches and then average the end result over a number of runs. Merging FFT calls is actually the way how I use VkFFT in Vulkan Spirit (with some other shaders between), so this benchmark is fairly close to the real life application use case. My benchmark most likely averages out multimodal distribution effects by design.

The OCT data we process comes in at about 4GSamples/s and my benchmark is for ~5ms of capture data, in the considered dataset 1D-FFT with a length of 2048 points and a block size of 128. It is not a synthetic benchmark, I'm measuring the real life application behavior here (and to eliminate the runtime behavior effects of the other parts I can flip a flag skipping over the DAQ codepath, working on allocated, but unin…

Small FFTs like 2048 only utilize one SM and the way they are given to the GPU may produce some fluctuations. It also depends on the way your code works. Synchronizations are also more impactful in this case. Do you launch a big grid that consists of multiple samples combined in a matrix or you launch each sample separately?

Re: VkFFT – Vulkan Fast Fourier Transform Library

#112

Post by DTolm »

Lichtso wrote: post #110

Very cool! Seems a bit more feature complete than my take on the problem: https://github.com/Lichtso/VulkanFFT Still, to beat CUDA with Vulkan a lot is still missing: Scan, Reduce, Sort, Aggregate, Partition, Select, Binning, etc.

I have some of these routines like Reduce and Scan in my other project https://github.com/DTolm/spirit. It also has implementations of linear algebra solvers like CG, VP, Runge-Kutta and some others. These routines have to be inlined in users shaders in some way to have a good performance. Releasing them as a standalone library will require some thinking due to the fact that some routines have multiple shader dispatches.

Re: VkFFT – Vulkan Fast Fourier Transform Library

#113

Post by pjmlp »

littlestymaar wrote: post #105
pjmlp wrote: post #88

Earlier quoted context omitted.

The video presentation at GTC clearly discusses it. They moved into Optix 7 as backend.

The video being almost two hours long, I'm not surprised I missed it when skimming. Do you know by chance at which point of the video it is discussed?

https://youtu.be/Qfy6CTaSHcc?t=932

Re: VkFFT – Vulkan Fast Fourier Transform Library

#114

Post by littlestymaar »

pjmlp wrote: post #113
littlestymaar wrote: post #105

Earlier quoted context omitted.

The video being almost two hours long, I'm not surprised I missed it when skimming. Do you know by chance at which point of the video it is discussed?

https://youtu.be/Qfy6CTaSHcc?t=932

Thanks. But I don't see how this fits with your previous statement:

> Badly, OctaneRender had moved away from Vulkan into CUDA, because they found out that Vulkan compute wasn't at the level that they wanted.

They mostly talk about Vulkan+Cuda interop which isn't really supported, and they explicitly said they consider rewriting everything using Vulkan to get rid of this issue. So from what I understand, they are still pretty bullish on Vulkan, but it will require a lot of work and it will take some time (“but probably won't be this year”).

Re: VkFFT – Vulkan Fast Fourier Transform Library

#115

Post by pjmlp »

littlestymaar wrote: post #114
pjmlp wrote: post #113

Earlier quoted context omitted.

https://youtu.be/Qfy6CTaSHcc?t=932

Thanks. But I don't see how this fits with your previous statement: > Badly, OctaneRender had moved away from Vulkan into CUDA, because they found out that Vulkan compute wasn't at the level that they wanted. They mostly talk about Vulkan+Cuda interop which isn't really supported, and they explicitly said they consider rewriting everything using Vulkan to get rid of this issue. So from what I understand, they are sti…

Optix doesn't do Vulkan and I doubt that NVidia will ever bother, and OTOY most likely will rather use they resources elsewhere like the new Metal render.

Re: VkFFT – Vulkan Fast Fourier Transform Library

#116

Post by littlestymaar »

pjmlp wrote: post #115
littlestymaar wrote: post #114

Earlier quoted context omitted.

Thanks. But I don't see how this fits with your previous statement: > Badly, OctaneRender had moved away from Vulkan into CUDA, because they found out that Vulkan compute wasn't at the level that they wanted. They mostly talk about Vulkan+Cuda interop which isn't really supported, and they explicitly said they consider rewriting everything using Vulkan to get rid of this issue. So from what I understand, they are sti…

Optix doesn't do Vulkan and I doubt that NVidia will ever bother, and OTOY most likely will rather use they resources elsewhere like the new Metal render.

> and OTOY most likely will rather use they resources elsewhere like the new Metal render.

Maybe you're right, and this guy is wrong. But you gotta admit that contradicting the speaker of the video you're using as a source is unusual to say the least.

Re: VkFFT – Vulkan Fast Fourier Transform Library

#117

Post by gorkish »

slavik81 wrote: post #62

What are the common applications for these sorts of GPU-accelerated FFTs? We mostly just solved problems analytically in undergrad, and the little bit of naive coding we did seemed pretty fast. I feel like this must be used for problems I would have learned about in grad school, if I had continued in electrical engineering.

Software defined radio / RF DSP is another area where FFT and IFFT performance and accuracy are critical.

Re: VkFFT – Vulkan Fast Fourier Transform Library

#118

Post by llukas »

datenwolf wrote: post #108
DTolm wrote: post #106

Earlier quoted context omitted.

I use the averaged data of 1000 merged launches and then average the end result over a number of runs. Merging FFT calls is actually the way how I use VkFFT in Vulkan Spirit (with some other shaders between), so this benchmark is fairly close to the real life application use case. My benchmark most likely averages out multimodal distribution effects by design.

The OCT data we process comes in at about 4GSamples/s and my benchmark is for ~5ms of capture data, in the considered dataset 1D-FFT with a length of 2048 points and a block size of 128. It is not a synthetic benchmark, I'm measuring the real life application behavior here (and to eliminate the runtime behavior effects of the other parts I can flip a flag skipping over the DAQ codepath, working on allocated, but unin…

Please check out cuFFTDx - you may be able to fuse parts of your pipeline on-chip.

Re: VkFFT – Vulkan Fast Fourier Transform Library

#119

Post by datenwolf »

DTolm wrote: post #111
datenwolf wrote: post #108

Earlier quoted context omitted.

The OCT data we process comes in at about 4GSamples/s and my benchmark is for ~5ms of capture data, in the considered dataset 1D-FFT with a length of 2048 points and a block size of 128. It is not a synthetic benchmark, I'm measuring the real life application behavior here (and to eliminate the runtime behavior effects of the other parts I can flip a flag skipping over the DAQ codepath, working on allocated, but unin…

Small FFTs like 2048 only utilize one SM and the way they are given to the GPU may produce some fluctuations. It also depends on the way your code works. Synchronizations are also more impactful in this case. Do you launch a big grid that consists of multiple samples combined in a matrix or you launch each sample separately?

I'm aware of all of that. And yes, we're very synchronization dependent. However we also spent a lot of time tinkering with the launch parameter and properly interleaving all synchronization events and fences due to our demands on achieving low latency.

Find our original publication here: https://doi.org/10.1364/BOE.5.002963

Since then we improved on that. For the resampling and complex tonemapping we determined empirically that a grid of 128 threads, each processing a whole line achieves the best throughput; there's a 2D parameter space of possible launch configurations and we brute force the whole thing (so far I didn't benchmark the RTX20xx and RTX30xx GPUs, but it was consistent between the GTX690 to GTX1080). The FFT plan is what cufftPlan1d is producing for a single axis transform over a 2D array, usually 2048 point FFT, but with up to 4096 lines (well, technically whatever the maximum dimension for 3D textures is).

> Do you launch a big grid that consists of multiple samples combined in a matrix

Of course!

> or you launch each sample separately?

Of course not, that'd be stupid.

Re: VkFFT – Vulkan Fast Fourier Transform Library

#120

Post by DTolm »

datenwolf wrote: post #119
DTolm wrote: post #111

Earlier quoted context omitted.

Small FFTs like 2048 only utilize one SM and the way they are given to the GPU may produce some fluctuations. It also depends on the way your code works. Synchronizations are also more impactful in this case. Do you launch a big grid that consists of multiple samples combined in a matrix or you launch each sample separately?

I'm aware of all of that. And yes, we're very synchronization dependent. However we also spent a lot of time tinkering with the launch parameter and properly interleaving all synchronization events and fences due to our demands on achieving low latency. Find our original publication here: https://doi.org/10.1364/BOE.5.002963 Since then we improved on that. For the resampling and complex tonemapping we determined empi…

Well, most likely I won't be able to help explaining the fluctuation easily then, as you have spent a lot of time on it already. It would be cool to try VkFFT in this usage scenario at some pont in the future though - it also can do 1D FFTs of grouped in matrix sequences.
Post reply on HN