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

71–80 of 132 posts

Re: VkFFT – Vulkan Fast Fourier Transform Library

#71

Post by Seirdy »

DTolm wrote: post #55
cycloptic wrote: post #49

Earlier quoted context omitted.

Static linking is okay and is allowed as a derivative work, but you need to ship object files. https://www.gnu.org/licenses/gpl-faq.en.html#LGPLStaticVsDyn... >(1) If you statically link against an LGPLed library, you must also provide your application in an object (not necessarily source) format, so that a user has the opportunity to modify the library and relink the application. This is covered in sections 6 and 6a…

Hello, I am the author of VkFFT. When I made VkFFT I wanted license to be like this: your project doesn't have to be open-source, but please share your modifications to VkFFT. I think about switching it to MPL 2.0, is this one better for everybody?

It might be better to simply switch to the LGPL v3 or later, since that explicitly addresses header libs.

Re: VkFFT – Vulkan Fast Fourier Transform Library

#73

Post by pjmlp »

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

Re: VkFFT – Vulkan Fast Fourier Transform Library

#74

Post by Reelin »

loa_in_ wrote: post #28
detaro wrote: post #19

Earlier quoted context omitted.

I don't think it's that easy? LGPLv3 has an explicit carve-out for headers which makes that scenario easy, but this is 2.1...

Paragraph 5 of the LGPL version 2.1 states: A program that contains no derivative of any portion of the Library, but is designed to work with the Library by being compiled or linked with it, is called a "work that uses the Library". Such a work, in isolation, is not a derivative work of the Library, and therefore falls outside the scope of this License.

I think there's a misunderstanding here.

By falling outside the scope of the license, the LGPL isn't viral in the way the GPL is. Code you write can use an LGPL licensed library but be licensed differently itself.

However, you (the developer) are still subject to various legal requirements if you make use of an LGPL licensed library! If you fail to meet those requirements (basically, allow relinking against a modified version of the library) then you are in violation of the license and (in most jurisdictions) subject to penalty under copyright law.

Re: VkFFT – Vulkan Fast Fourier Transform Library

#75

Post by oxxoxoxooo »

DTolm wrote: post #56
gct wrote: post #7

Earlier quoted context omitted.

So you can pad your input array with zeros, but the algorithm doesn't know that it's padded, and will just compute with those zeros like any other value. If you could tell it that they were zeros it could take advantage of x*0=0 and x+0=x to significantly reduce computation. That's what I think that is.

That is almost the correct answer. To go even further, there are sequences that are completely full of zeros in the padded case of multidimensional FFTs and we can omit their FFTs entirely.

Thank you for the reply! Could you be more specific? In the case of 1D FFT, the right half (possibly zero-padded) of the signal is completely mixed up with the left half after the first pass [of breath-first FFT]. If the right half was all zeros, would it still be twice as fast in 1D case? Do you have any pointers to literature which discusses this?

Re: VkFFT – Vulkan Fast Fourier Transform Library

#76

Post by qppo »

jjeaff wrote: post #5
zdw wrote: post #4

If I were a hiring person at AMD or Intel, I'd shortlist this guy for a job, as they need help competing against the headstart CUDA has in the GPU-base compute space.

Ya, but the important question is can they invert a binary tree on a whiteboard?

"Write an FFT" is the DSP engineer interview question that's analogous to tree traversal algorithm whiteboarding. The hard part is remembering how a butterfly computation works, and you'll almost never need to implement it.

Re: VkFFT – Vulkan Fast Fourier Transform Library

#77

Post by krzepah »

andi999 wrote: post #66
necubi wrote: post #52

Earlier quoted context omitted.

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…

What OS are we talking? It sounds like you need a real time os.

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

Re: VkFFT – Vulkan Fast Fourier Transform Library

#78

Post by andi999 »

krzepah wrote: post #77
andi999 wrote: post #66

Earlier quoted context omitted.

What OS are we talking? It sounds like you need a real time os.

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.

Re: VkFFT – Vulkan Fast Fourier Transform Library

#79

Post by Reelin »

DTolm wrote: post #54
kbumsik wrote: post #37

Earlier quoted context omitted.

In this case I interpret LGPL as "Please don't maintain your own fork (with bugfixs) in your company internally, contribute to my repo directly", which make sense.

This was indeed what I was thinking in the first place, when I made VkFFT - your project doesn't have to be open-source, but please share your modifications to VkFFT. I think about switching it to MPL 2.0, is this one better for everybody?

Yes, I believe the MPL fits the usecase you describe.

As far as I understand it, proprietary code using an LGPL licensed library is more or less incompatible with templates in header files (!!!) since there's no way (AFAIK?) to relink against a modified version without providing your full source code. Supposedly the LGPLv3 provides an exception for header files but personally I wouldn't go anywhere near it because it seems quite vague - "small" macros, templates that are less than 10 lines (what constitutes a line?) etc.

So as currently licensed (LGPL), I don't think your library is usable as part of a proprietary project.

The MPL, in contrast, places no relinking requirements on the developer. You only have to share any changes you happen to make to the MPL licensed code.

Re: VkFFT – Vulkan Fast Fourier Transform Library

#80

Post by DTolm »

oxxoxoxooo wrote: post #75
DTolm wrote: post #56

Earlier quoted context omitted.

That is almost the correct answer. To go even further, there are sequences that are completely full of zeros in the padded case of multidimensional FFTs and we can omit their FFTs entirely.

Thank you for the reply! Could you be more specific? In the case of 1D FFT, the right half (possibly zero-padded) of the signal is completely mixed up with the left half after the first pass [of breath-first FFT]. If the right half was all zeros, would it still be twice as fast in 1D case? Do you have any pointers to literature which discusses this?

No, the 1D case will mostly save on the fact that it transfers 2x times less data from the vram to the chip. The up to 2x times increase in performance was mainly related to 2D and 3D cases, where only 1/4 or 1/8 of the data is nonzero. In 2D, when doing 1D FFTs over x-axis, we omit sequences after Ny/2 because we know they are full of 0 and thus their result will be 0. So we do 0.5Ny x-axis ffts and full Nx y-axis ffts. For a square system this will mean a drop from 2N to 1.5N sequences. In 3D the drop will be even bigger, from 3N^2 to (1/4+1/2+1)=1.75N^2 sequences (almost 2x).
Post reply on HN