Offloading plugin load

Ideas & suggestions
1

Hi everyone,

I’m new here and although I’ve had a quick look for similar suggestions, I’ve not seen anything so apologies if this has already been discussed on another thread

I was thinking about CPU load when running plugins and had two ideas

Idea 1: I have dual AMD R9 GFX cards in my system and wondered how easy it would be to offload plugin processing to one or both of these cards. I know these are less flexible than the CPU but wondered if their superior ability to do maths might be useful for reducing load on the main CPU?

Idea 2: I’d like to be able to setup another computer on my network which would act as a plugin server and do the same kind of thing as idea 1, ie, take CPU load off of my main machine by processing plugins seamlessly across the network

Just a couple of ideas anyway, would be interested to see if anyone thinks these are doable

2

@idea 1
That would require special programming, e.g. Using opencl. So far not a single plug-in vendor offers such a plug-in (except uad of course in a custom way). U-he is researching in this topic. There are example plug in sources on github. This topic has huge potential, since audio processing just like gfx would totally benefit from using the gpu.

3

idea 1 would need the original developers of each plugin completely recode its core to run on gpu processors. Involves lots of substantial work and big redesign/recoding work. I think this will in future kick in, right now I guess it just makes everything too complicated for the plugin manufacturers. Like there are so many different apis, drivers, generations of gpus with different capabilities, it makes it very hard and require lots of tedious work to produce something that will work equally stable on a broad range of GPUs without having to support angry customers day and night because they have a freak gfx card installed that doesn’t make things shine like expected. GPU’s aren’t really fast, they just can calculate lots of slow simple things at the same time. Ideal for blowing many 3d triangles on the screen, but not so for serial dsp processing. But I guess soon there will be kick ass realistic gpu reverb plugins or shit like this.

idea 2 why not, just do it, load a plugin host into computer, find and install a driver lib that will allow realtime streaming audio/midi via network, wire up with your workstation via ethernet, treat the computer like a midi synth or multieffects box.

4

This master’s thesis has a few interesting points http://www.inf.ufrgs.br/~oliveira/students_dissertations/Masters/Fernando_Trebien_Masters_thesis_UFRGS_2009.pdf

"[…] communications between the CPU and the GPU have a considerable time de-

lay. This can be observed both when launching GPU programs or when moving memory

between video memory and main memory. When developing a complex audio processing

application, one will likely desire to do the entire audio processing either on the CPU or

the GPU in order to minimize the number of memory transfers between CPU and GPU."

" ImplementationsoftheFFTarealreadyavailableinsoftwarelibrariesforboththeCPU(FRIGO;

JOHNSON, 2005) and GPUs (GOVINDARAJU; MANOCHA, 2007)."

"Most of the works on GPU-based audio processing do not present a real-time application, and most also report little advantage of

GPU-based audio processing over a corresponding CPU-based one."

" Compared to the equivalent CPU-based technique using the same FFT op-

erations, this approach supports real-time processing of 2 to 4× more coefficients than it

was previously possible"

"Since larger speedups were expected, I have concluded that FFT algorithms, which are

frequently used for signal processing, benefit little of the GPU computing power, being

restricted by memory bandwidth and access patterns. It still makes sense, however, to im-

plement FFT-based processes on the GPU if they are combined with other processes that

do explore the GPU computational power, such as mixing, synthesis and non-recursive

filtering."

"Using the FFT makes the method scale optimally for large recursive filters. However,

this kind of filter is very uncommon (the order of the recursive section is almost never

larger than 32 in typical audio applications). At such sizes, performing this filter on a

GPU is often slower than on a CPU"

It also cites a number of related articles if you want to read more about the topic.

My best guess is that we won’t see this kind of thing in the near future, although I think dedicated DSP hardware has been sold in the past, right? I’m just not sure who would be buying it.

5

The concept is already “proven” by Universal Audio/UAD. The latency will be likely the doubled normal latency (hopefully lower), because round trip or something. OpenCL was made for such thing. There are working example plugins on GitHub.

6

Thanks for all your replies,

I now realise I underestimated how complex the GPU question was - I was thinking that using OPENGL or OPENCL it would be fairly easy to build something which would ‘translate’ any plugin from running on the CPU to the GPU without recompiling etc… but hadn’t considered all the other issues such as time taken to shunt data from RAM to GFX memory and back or that the GPU might not even support the opcodes needed by the plugin (and therefore not be ‘translatable’ by the API) - Not to mention the questionable performance gains

I am pleased to read that idea2 might work though - I’ll read up on OSC now and see if I can make any sense of it

Thanks again and happy tracking!

7

you might find the “netjack” option from the “jack connection kit” software interesting for option 2. Don’t know, but I guess there’s also other software around capable of this.

Going via ethernet should be better than via soundcards (and cheaper…) in regards of latency, but you will have to live with some extra latency/overhead in the whole system because of the netlink.

8

So far not a single plug-in vendor offers such a plug-in…

Liquidsonics has a NVIDIA Cuda Edition of their small convolver at least.

https://www.liquidsonics.com/software/reverberate-le/

9

Liquidsonics has a NVIDIA Cuda Edition of their small convolver at least.

That’s pretty neat, is there something about reverb that makes using the GPU attractive?

I suppose it’s likelier to be on the master or on a send channel. My assumption is that for most other cases freezing a track would usually be the preferred way to deal with CPU load.

I think in most of the cases where you could tolerate the latency of GPU or netjack you’d probably prefer freezing tracks, really.