VkFFT – Vulkan Fast Fourier Transform Library • Hacker News Board

Re: VkFFT – Vulkan Fast Fourier Transform Library

#51

Post by pabs3 » Mon, Sep 28, 2020, 3:27 AM UTC

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.

The program seems like it would contain inlined code from the header though right?

Re: VkFFT – Vulkan Fast Fourier Transform Library

#52

Post by necubi » Mon, Sep 28, 2020, 3:27 AM UTC

viraptor wrote: post #32

adamnemecek wrote: post #21

Earlier quoted context omitted.

It's not gonna happen, audio is much less throughput intensive but a lot more latency sensitive.

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 size and sample rate. To my ear, buffer sizes of >128 samples (at a sample rate of 44.1 KHz) have detectable latency (although the amount of latency will depend also on how many applications are in your signal chain). At 128 samples you have just under 3ms to do your processing.

Also note that for graphics, the output is the GPU itself. So you don't need to wait for the output to move back to the CPU, it's already where it needs to be.

Re: VkFFT – Vulkan Fast Fourier Transform Library

#53

Post by pabs3 » Mon, Sep 28, 2020, 3:28 AM UTC

loa_in_ wrote: post #27

bialpio wrote: post #14

Earlier quoted context omitted.

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.

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.

The program seems like it would contain inlined code from the header though right?

Re: VkFFT – Vulkan Fast Fourier Transform Library

#54

Post by DTolm » Mon, Sep 28, 2020, 3:30 AM UTC

kbumsik wrote: post #37

meisel wrote: post #33

Earlier quoted context omitted.

In that case, if header-only is outside the scope of the license, it begs the question why they would pick that license in the first place. But anyways, it doesn't seem clear from the passage how headers fit in, considering that these headers are not just APIs, they contain the implementation themselves.

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?

Re: VkFFT – Vulkan Fast Fourier Transform Library

#55

Post by DTolm » Mon, Sep 28, 2020, 3:32 AM UTC

cycloptic wrote: post #49

rjeli wrote: post #47

Earlier quoted context omitted.

IIRC it’s unclear if static linking LGPL is okay, so most people steer clear

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?

Re: VkFFT – Vulkan Fast Fourier Transform Library

#56

Post by DTolm » Mon, Sep 28, 2020, 3:37 AM UTC

gct wrote: post #7

oxxoxoxooo wrote: post #6

What is "Native zero padding to model open systems"? And how come it is "up to 2x faster than simply padding input array with zeros"?

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.

Re: VkFFT – Vulkan Fast Fourier Transform Library

#57

Post by cma » Mon, Sep 28, 2020, 3:43 AM UTC

reitzensteinm wrote: post #35

adamnemecek wrote: post #21

Earlier quoted context omitted.

It's not gonna happen, audio is much less throughput intensive but a lot more latency sensitive.

You can read off a GPU in 10us, which is just a single sample at 96khz. If your entire stack lived in the GPU, and you're just reading out the result, this is trivial. If you're constantly copying buffers back and forth because some effects are implemented in the CPU and some in the GPU, not so much! It's probably the case that a full stack GPU implementation would blow what we have out of the water, but you'd lose y…

Sony is trying some stuff along those lines with the PS5. They have one compute unit on the GPU with a few features fused off that is dedicated to audio.

Re: VkFFT – Vulkan Fast Fourier Transform Library

#58

Post by cycloptic » Mon, Sep 28, 2020, 3:46 AM UTC

kbumsik wrote: post #50

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…

So then the OP is a LGPL header-only library, which is always statically compiled in every source. Do we need to do the same thing, and if yes, how we provide an application to allow recompiling?

If you can't use the object files to rebuild another version of the program with a modifier version of the library then no that probably wouldn't be compliant. In that case you would probably have to modify the library so it's not inlining every function. (Disclaimer: IANAL)

Re: VkFFT – Vulkan Fast Fourier Transform Library

#59

Post by cycloptic » Mon, Sep 28, 2020, 3:47 AM UTC

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?

That would probably do what you want because it applies on a per-file basis and not to the entire program, but make sure you read the MPL FAQ and the fine print before making such a change: https://www.mozilla.org/en-US/MPL/2.0/FAQ/

Re: VkFFT – Vulkan Fast Fourier Transform Library

#60

Post by ncmncm » Mon, Sep 28, 2020, 4:11 AM UTC

solipsism wrote: post #46

ncmncm wrote: post #17

Earlier quoted context omitted.

To me a Gitlab account, instead, would signify superior judgment.

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.)