Hey,
Some brief initial thoughts:
http://en.wikipedia.org/wiki/CUDA pro: better than OpenGL GPGPU hackery pro: API/ABI-stable for foreseeable future con: only one hardware vendor
-vs-
http://en.wikipedia.org/wiki/OpenCL pro: royalty free standard with several vendors pro: works on cpus as well as gpus con: newer, may be API/ABI-unstable
-vs-
http://faust.grame.fr/catalog.php pro: dataflow language optimized for DSP pro: has backend for Pd already con: works by translation via C++
Any project worth doing is worth doing right. So, I want to figure out if: a) it's worth doing
Sufficiently-parallel DSP on GPU is probably worth doing, but only benchmarks will tell. Parallel DSP could either be multichannel or blocky (no data dependencies between samples in the same block) or a mixture of both at different parts of the graph.
b) how to do it right.
I did have an idea that went something like this:
1. write ugens in Faust, compile them into dsp objects, link, load 2. write a transaction-based patcher environment (or dataflow language) wherein transactions (such as multiple object creation deletion connection etc) can be committed atomically (with OSC-style bundle time tags etc) 3. translate the generated networks of dsp objects back to Faust code 4. compile that Faust code into a new dsp object, link, load, run 5. rinse, repeat
So, an OpenCL backend (instead of C++ backend) for Faust is the missing link...
Claude