Live data from Hacker News

VkFFT – Vulkan Fast Fourier Transform Library

github.com

11–20 of 132 posts

Re: VkFFT – Vulkan Fast Fourier Transform Library

#12
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!

Re: VkFFT – Vulkan Fast Fourier Transform Library

#13
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?

You can run OpenCL kernels on Vulkan at least in theory: SPIR-V supports OpenCL memory model. CUDA might be machine translatable if you can compile into LLVM target (clang seems to have experimental support developed outside of Nvidia) which you then retarget into SPIR-V using a cross-compiler. The LLVM to SPIR-V cross-compiler however is limited in its translation for the time being.

In general, Vulkan is a thing which commands the GPU, but is not opinionated on what the language used to represent the kernel is as long as it compiles to SPIR-V. SPIR-V in itself is like parallel LLVM IR. If you look into the project source, the shaders are in GLSL which have been pre-compiled using a cross-compiler into SPIR-V. The C file you find on the project root constitutes as the loader program for the SPIR-V files.

Futhark project did some initial benchmarks on translating OpenCL to Vulkan. The results were mainly slowdowns. You can read about it in here: https://futhark-lang.org/student-projects/steffen-msc-projec...

Re: VkFFT – Vulkan Fast Fourier Transform Library

#14
post #2

Isn't LGPL 2.1 is an odd license for something like this? Does it produce a library?

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

Re: VkFFT – Vulkan Fast Fourier Transform Library

#15
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.

The AMD Math Libraries team is hiring [1], and one of the libraries they develop is rocFFT [2]. Disclosure: I work at AMD, though not on rocFFT.

[1]: https://jobs.amd.com/job/Calgary-GPU-Libraries-Software-Deve... [2]: https://github.com/ROCmSoftwarePlatform/rocFFT

Re: VkFFT – Vulkan Fast Fourier Transform Library

#16
post #13
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?

You can run OpenCL kernels on Vulkan at least in theory: SPIR-V supports OpenCL memory model. CUDA might be machine translatable if you can compile into LLVM target (clang seems to have experimental support developed outside of Nvidia) which you then retarget into SPIR-V using a cross-compiler. The LLVM to SPIR-V cross-compiler however is limited in its translation for the time being. In general, Vulkan is a thing wh…

We run OpenCL on top of Vulkan in a production application on Android, thanks to a project from Google / Codeplay and other contributors https://github.com/google/clspv. SPIR-V can't represent all of OpenCL, but maybe enough for most people's use cases.

Re: VkFFT – Vulkan Fast Fourier Transform Library

#17
post #8

I think this guy will have no problem getting hired. Being conscious enough to push code online works so much better than the CV preparation courses. You know you're on the right path when you are asked to play up your CV abstract than to downplay it. Personally, I would have a hard time hiring anyone without a Github account and less so working in a place where nobody has one.

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

Re: VkFFT – Vulkan Fast Fourier Transform Library

#19
post #18
post #11

Warning: LGPL license

... which, being a header-only library, happens to place no restrictions or requirements of any kind on the calling program.

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...
Post reply on HN