Diva and GPU processing

[UltraJv]

There are a few CUDA based reverbs but no synths due to latency issues and parrallel architecture :

http://www.liquidsonics.com/software_reverberate_le.htm


http://www.acustica-audio.com/index.php ... Itemid=228

[xh3rv]

Haven't thought about it much but i'm thinking some sort of producer/consumer queue. Maybe there's pitfalls i haven't thought of (on second though i'm positive there are). I think you would get at least a decent level of concurrency even though not a "perfect" one.

Is it fair to say - relative to per-voice multi-threading, you're thinking of more, per-component or blocks of components? If that's the case, my thinking is whatever overhead is generated by per-voice would be less than per-component since one would have to compute components per voice anyway. For something like ACE or Diva in the familiar PC hard-/soft-ware environment, anyway.

Off on a tangent ... I haven't thought about thread scheduling much recently but as it's bubbling back up I think probably the trickiest thing conceptually is moving from an execution model with deadlines in terms of time, to a model with expectations in terms of algorithmic assumptions from schedulers. I believe this is where dedicated hardware pipelines like a GPU are really nice from a programming perspective, even without considering the extra muscle-power. It makes me wonder if there's something plausible for the context of a multi-core CPU which could be constructed with a very different scheduling scheme in mind, a computational core independent of OS scheduling that apps with strict real-time requirements could gain control of.

[jupiter8]

Haven't thought about it much but i'm thinking some sort of producer/consumer queue. Maybe there's pitfalls i haven't thought of (on second though i'm positive there are). I think you would get at least a decent level of concurrency even though not a "perfect" one.

Is it fair to say - relative to per-voice multi-threading, you're thinking of more, per-component or blocks of components?

Yes. If we take the common OSC->FILTER->VCA configuration,in an ordinary CPU it is preferable to calculate in blocks so you calculate all OSC samples and have the filter work on that and so on like a relay race.

But once the first sample is calculated the filter has something to work on so it could start processing. And once it has calculated it's first sample the VCA can go to work.

You don't want that in an ordinary CPU because of context switching and inter thread synchronization. However on the GPU you have lots (hundreds if not thousands) of processing units and they're essentially free since you don't use them.

So you can split up the work in lots of smaller jobs,i have a feeling a single processing unit isn't fast enough to process a single voice but i don't really know (and it obviously depends on how heavy the synth is and how fast the GPU is).

[xh3rv]

You don't want that in an ordinary CPU because of context switching and inter thread synchronization. However on the GPU you have lots (hundreds if not thousands) of processing units and they're essentially free since you don't use them.

I think there's a bottleneck here for a lot of GPUs, but it occurs to me ... I think video game consoles actually do a lot better than the average PC here for integrating the GPU components' memory back to the CPUs. I don't really keep up on how fast that hardware is relatively but, hmm, there should be *some* application here?

[e] Maybe for video jockeys ... just saw this: