Charles Henry wrote:
b) how to do it right.
I did have an idea that went something like this:
[snip]
Okay, you've gone way beyond my area of knowledge already :)
Well, it's just ideation so far - no code written, nor enough knowledge gained to even start writing the code...
[snip]
Probably, if we come up with anything in the way of top-down design, we should be able to apply the same framework to different platforms and make comparisons.
My initial thoughts on top down design, having read only the OpenCL intro slides and not written any code:
It will be difficult to get a "OpenCL API as Pd objects" approach to be efficient, there are too many timing/asynchrony issues as far as I can tell so far. It would also be undesireable to have to expect all users to know how OpenCL works in detail, as it's quite tricky...
An alternative idea is to have an [opencl~] object that sits in a subpatch like [switch~] or [block~] does, that analyses the DSP sub-graph for that subpatch and "lifts" the whole dsp part of the subpatch to the GPU. Probably it would require some magic to get [+~] etc to work directly, so maybe a compromise would be [cl/+~] etc, then the [opencl~] object would "compile" these objects into a kernel at "; pd dsp 1" time. Then [inlet~] and [outlet~] would do the transfer to/from GPU (if the containing patch isn't on GPU, otherwise it would just pass a pointer to GPU memory...).
And if [import] or whatever works to a sufficient extent(*), it should be possible to go back to using [+~] and [import cl], with a backend switchable so you could [import simd] instead to use regular SIMD-optimized dsp objects, or [import vanilla] to use the normal unoptimized Pd objects, etc...
The first idea is simpler to implement but is horrible for users, the second idea is simpler for users but requires horrible knowledge of Pd internals to implement. The goal of libraries is to make life better for library users, I think - so that makes the second idea more attractive.
(*) by which I mean [import] or other similar object works on a subpatch basis, or at least on a .pd file basis, so abstractions can have different libraries to their containing patches if they desire without clobbering anything globally, and imported objects can override global objects with the same name, etc...