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

81–90 of 132 posts

Re: VkFFT – Vulkan Fast Fourier Transform Library

#81

Post by viraptor »

andi999 wrote: post #78
krzepah wrote: post #77

Earlier quoted context omitted.

What are you talking about ? Most people working with sound today do so by using a DAW like Ableton, QBase or Fruity Loop that work on Windows or sometimes Mac Os

Comment before was saying you cannot miss a deadline; i didnt know this was possible with windows or macos.

They're not hard-realtime, so they definitely can miss a few samples. You can workaround that by reconfiguring an external device rather than generating the samples locally, but that's not what Ableton or FL do.

Win and Mac have soft-realtime scheduling and the mentioned software does what it can without guarantees https://help.ableton.com/hc/en-us/articles/209072289-How-to-... I've been to a live gig before where the performance was paused a few times because artist's mac was misbehaving.

Re: VkFFT – Vulkan Fast Fourier Transform Library

#82

Post by viraptor »

necubi wrote: post #52
viraptor wrote: post #32

Earlier quoted context omitted.

Why do you think it's not going to happen? And for which use case? The time budget to refresh a video frame is 8ms on 120HZ if everything else came free. In practice closer to <4ms. So even looking at the close to worst conditions, that's about the delay of the sound traveling a meter - should be fine for a lot of real life applications.

Audio processing is real-time, which means that you cannot miss your deadline. If you do miss you get audible glitches, whereas in graphics you just get a slowdown. For that reason, audio code is written in a very particular, real-time safe style that avoids locks, allocations, syscalls, and anything else that is not guaranteed to return within a bounded amount time. How long the deadline is depends on your buffer si…

But let's keep some realistic context. The audio output is under 1 MBps. You can push that much over original PCI (not express) and ~1ms delay on PCI was "everything must be broken, reset the whole bus". Pushing audio samples both ways on PCIe will not be an issue.

https://www.cycfi.com/2019/04/gpu-dsp-latency/

> PCI-E 3.0 standard guarantees data transfer for 4 kb data with 1-2 μsec (3-10 round trip).

Copying CPU-GPU-CPU:

> size: 8192 bytes, time: 4.72 us,

This should not be a meaningful impact in any audio workflow.

Re: VkFFT – Vulkan Fast Fourier Transform Library

#83

Post by littlestymaar »

pjmlp wrote: post #73
p1mrx wrote: post #9

How does using Vulkan for computation fit into the OpenCL/CUDA landscape? Is CUDA's proprietary nature doing meaningful harm, and does Vulkan help?

Badly, OctaneRender had moved away from Vulkan into CUDA, because they found out that Vulkan compute wasn't at the level that they wanted. https://home.otoy.com/octane2020-rndr-released/ "OTOY | GTC 2020: Real-Time Raytracing, Holographic Displays, Light Field Media and RNDR Network" https://www.youtube.com/watch?v=Qfy6CTaSHcc

I couldn't find any details about the migration on either links but it looks like they make massive use of Nvidia-specific features, so even with exactly the same performances it would make total sense to use Cuda just because the tooling is more mature.

Re: VkFFT – Vulkan Fast Fourier Transform Library

#84

Post by [deleted] »

ncmncm wrote: post #60
solipsism wrote: post #46

Earlier quoted context omitted.

Getting downvoted, but this is no more arbitrary, myopic, and unfair to the applicant than the parent.

The Microsoft Defense Force has been activated. Despite it, my statement remains true: I do, in fact, adjudge candidates the more favorably for a Gitlab account than a Github account. It demonstrates conscious choice in a knee-jerk world. (Microsoft doesn't need your assistance, boiz.)

[deleted]

Re: VkFFT – Vulkan Fast Fourier Transform Library

#85

Post by HelloNurse »

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.

The same as any FFT, but accelerated; with the tradeoff that the cost of moving data from and to the GPU needs to be amortized. It's also a good proof of concept for other kinds of GPU computations.

Re: VkFFT – Vulkan Fast Fourier Transform Library

#86

Post by formerly_proven »

bialpio wrote: post #14
microcolonel wrote: post #3

Earlier quoted context omitted.

> Does it produce a library? It is a library.

A _header-only_ library. Not sure how LGPL works for those - not much to avoid linking against... Throw it in your own .dll / .so and use that in your closed-source projects? Standard disclosure: IANAL.

Uh, no, it's not. The shaders are clearly part of the work, so you need to make sure that the shaders are "dynamically linked"; i.e. can be replaced by the end user with their own version in order to comply with the terms of the LGPL.

Re: VkFFT – Vulkan Fast Fourier Transform Library

#88

Post by pjmlp »

littlestymaar wrote: post #83
pjmlp wrote: post #73

Earlier quoted context omitted.

Badly, OctaneRender had moved away from Vulkan into CUDA, because they found out that Vulkan compute wasn't at the level that they wanted. https://home.otoy.com/octane2020-rndr-released/ "OTOY | GTC 2020: Real-Time Raytracing, Holographic Displays, Light Field Media and RNDR Network" https://www.youtube.com/watch?v=Qfy6CTaSHcc

I couldn't find any details about the migration on either links but it looks like they make massive use of Nvidia-specific features, so even with exactly the same performances it would make total sense to use Cuda just because the tooling is more mature.

The video presentation at GTC clearly discusses it.

They moved into Optix 7 as backend.

Re: VkFFT – Vulkan Fast Fourier Transform Library

#89

Post by Reelin »

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.

Likely any HPC application that has an FFT somewhere in its pipeline and is otherwise amenable to being run on a GPU.

Fluid flow, heat transfer, and other such physical phenomena that you might want to simulate.

Phase correlation in image processing is another example. (https://en.wikipedia.org/wiki/Phase_correlation)

MD simulations rely on FFT but I'm not sure how much is typically (or can be) done on the GPU. For example, NAMD employs cuFFT on the GPU in some cases. (https://aip.scitation.org/doi/10.1063/5.0014475)

Re: VkFFT – Vulkan Fast Fourier Transform Library

#90

Post by hadeson »

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.

It could be used to accelerate Convolutional Neural Nets training [0]

[0] https://arxiv.org/abs/1312.5851

Post reply on HN