Continuing this increasingly inaccurately christened thread .. On Tue, 2009-08-11 at 11:26 +0100, Steve Harris wrote:
> It's not ideal, but assembling all the jack buffers into one big one > is not going to be that much load on the CPU. > OK .. Adrian Knoth showed some interest and says he knows his way around in jackd as well as a colleague involved with CUDA. If the idea after evaluation does not appear to be worth the effort, then we'll just drop it by then. > Another tack would be to provide a library that could execute LV2 > plugins (with CUDA versions of the code in the bundle). It would > presumably need a daemon or such, but would be more generally useful > than a hacked jackd. > That would have to be a collection of generally useful plugins, at least 32 channels wide to be worth it. A mega plugin so to say. This ain't no lawn-mover you can turn around on a platter. Doing little things here and there /only/ would be very difficult in general. The thing to notice is that, although several kernels can be launched the one after the other, at any given time there is only one running which will have to be aware of which codepath to take depending on what processor it is running on. Or else you'll end up with 640 identical channel-strips rather than something like a synth-collection, 64 fully equipped channel-strips + a few reverb units as well as an autocomposer based on neural networks (Well OK, that last one might be a bit over the top... :) As long as you only have a single 8 core multiprocessor, the GPU can be utilized fully by a single somewhat demanding project. It is when there are dozens of cores to feed that the need for cooperation arises, and this is as far as I can see where things are heading, also over in Intel/Larrabee land. > The whole point of > jack is that it lets you combine bits of software in different ways, > this would take that away to some extent. > To some extent, yes. But provided that the host isn't spending much time on moving buffers around, you'll still have all of your (much more flexible) CPU left to use for additional processing. Having this much processing power available in a way also eliminates /the need/ for carefully selecting what channels should be processed by what plugin. Just do everything for all, possibly with all settings turned down to zero or bypassed on some, even most channels. Some effects will still be optional - like say time stretching, which might not be a natural choice for the basic bread-and-butter setup, no matter how much icing you put on it. Or maybe it is? Some people will most likely disagree with me here .. To put things in some economical perspective, I am talking about upgrading this tiny desktop-machine to having bandwidth and processing power twice that of a current top-of-the-line Intel Nehalem for less than $200, maybe around Christmas. Inexpensive (!Apple) laptops with GPU's like that are hitting the channel as we speak. /jma > - Steve _______________________________________________ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev