31–40 of 132 posts
Earlier quoted context omitted.
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.
Perhaps for large calculations? Otherwise the PCI transfer delay would be a big latency hit?
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.
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.
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.
Earlier quoted context omitted.
It's not gonna happen, audio is much less throughput intensive but a lot more latency sensitive.
Could it be possible to “prerender” the audio on the GPU when it’s not being worked on (say, a track not being edited)? Then just play that track if it’s not edited before the user hits play?
There are some methods of synthesis which rely on FFT which can't really be done well in real-time with the CPU (PadSynth, PaulStretch) that I'm hoping this will help with.
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.
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 your entire ecosystem in the process, so it's probably never going to happen.
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?
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.
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…
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.
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.