21–30 of 132 posts
I'm very eager to see GPU acceleration make its way into audio production, which is all still heavily CPU bound. A Free GPUFFT implementation will certainly help! Great work.
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.
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!
I'm very eager to see GPU acceleration make its way into audio production, which is all still heavily CPU bound. A Free GPUFFT implementation will certainly help! Great work.
It's not gonna happen, audio is much less throughput intensive but a lot more latency sensitive.
I'm very eager to see GPU acceleration make its way into audio production, which is all still heavily CPU bound. A Free GPUFFT implementation will certainly help! Great work.
It's not gonna happen, audio is much less throughput intensive but a lot more latency sensitive.
But even if that is not the case, machine learning is making its way into music production tools more and more. No doubt a beefy GPU will be useful to a lot of music production professionals in the future at least, as the tools they are using begin to leverage ML more and more.
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.
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.
Earlier quoted context omitted.
... 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...
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.
Earlier quoted context omitted.
It's not gonna happen, audio is much less throughput intensive but a lot more latency sensitive.
I've heard credible claims that GPUs these days (esp. TPUs) have lower latency for big models than CPUs. I haven't really investigated, but I could see it happening if you give the TPU a huge L1 cache or something.
I'm very eager to see GPU acceleration make its way into audio production, which is all still heavily CPU bound. A Free GPUFFT implementation will certainly help! Great work.
It's not gonna happen, audio is much less throughput intensive but a lot more latency sensitive.