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

61–70 of 132 posts

Re: VkFFT – Vulkan Fast Fourier Transform Library

#61

Post by ncmncm »

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?

Your code, your license. Nobody else has earned a say.

Ask anybody who actually contributes, usefully, what they think. Their opinion might mean something.

Re: VkFFT – Vulkan Fast Fourier Transform Library

#62

Post by slavik81 »

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.

Re: VkFFT – Vulkan Fast Fourier Transform Library

#63

Post by whateveracct »

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

Yep. I put all my new stuff on GitLab. It's just a better tool. Especially it's issue-tracking and CI (even considering actions)

I just link my GitLab very obviously on my GitHub

Re: VkFFT – Vulkan Fast Fourier Transform Library

#64

Post by fulafel »

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.

Doesn't this mean there is no permission to use it, as that's the default situation?

Re: VkFFT – Vulkan Fast Fourier Transform Library

#65

Post by andi999 »

TomVDB wrote: post #12
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.

One should hope that the non-CUDA GPU compute library ecosystem has already advanced beyond being able to calculate FFTs!

Last time I checked there was no good fft for AMD.

Re: VkFFT – Vulkan Fast Fourier Transform Library

#66

Post by andi999 »

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…

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

Re: VkFFT – Vulkan Fast Fourier Transform Library

#67

Post by andi999 »

meisel wrote: post #33
loa_in_ wrote: post #28

Earlier quoted context omitted.

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.

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.

Because they do not know, and are domain experts, not licence experts: like probably almost everybody else here.

Re: VkFFT – Vulkan Fast Fourier Transform Library

#68

Post by snovv_crash »

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?

Yes, MPLv2 does what you want. Consider that it's also used by Eigen. I strongly advocate for MPLv2 for math style libraries.

Re: VkFFT – Vulkan Fast Fourier Transform Library

#69

Post by FieryTransition »

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

If I ever got minus points for using github rather than gitlab in an interview, I think my opinion of the workplace would be that they would rather focus on minute details rather than actual problem solving and social skills.

Re: VkFFT – Vulkan Fast Fourier Transform Library

#70

Post by drran »

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?

Goal of LGPL is to protect freedom of developers to modify code of a library (e.g. to improve it, fix bugs, fix incompatibilities, port to new hardware, etc.) shipped as part of proprietary application. This freedom is important for developers of niche OS'es. This protection works, because of hard consequences for proprietary code in case of license violation: proprietary code must be released under GPL then.

MPL doesn't protect such developers, but it "forces" contribution of changes back to original code. In reality, it's ignored.

Header-only library cannot be compiled as separate library, so requirements of LGPL cannot be met by proprietary code.

Post reply on HN