[PD] [PD-dev] CUDA discussion

[Claude Heiland-Allen]

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...


Claude
-- 
http://claudiusmaximus.goto10.org