I think its going to be quite difficult to have a single object
running in the CUDA/GPU while the rest of the patch runs on the CPU in
regular Pd. My guess is that the best first step would be to
implement a basic Pd in CUDA, then work from there about integrating
it. Perhaps then you could use the [pd~] model.
For examples of reimplmentations of Pd, check out ZenGarden (C++) and
Webpd (Javascript) http://mccormick.cx/projects/WebPd/
.hc
On Mar 23, 2011, at 5:20 PM, Charles Henry wrote:
Hi, hc
Let me explain a little further here. The end goal is to have an
external library that allows one to create externals that use memory
on GPUs. Big idea here is that once you've got a system for
handling the memory allocation and dsp sorting in *exactly* the same
way as Pd, then you can write externals for CUDA or CL in a way
that's consistent with existing externals.
With Pd handling the signal memory allocation inside of d_ugen.c and
called from canvas_dodsp, I wanted for my external library to have
its own canvas class and different methods for handling the memory
allocation differently. In fact, I think of that as being the key
class to create the library.
I worked through it for a while, and I think it's just plain
impossible to have another canvas class in an external library,
unless there's something good I don't understand. And I really want
to understand :)
So, since then, I've been thinking that I'd have to modify the pd-
vanilla source code. I've got something that loads a CUDA device
and gets me to run code during canvas_new, canvas_free, and
canvas_dsp. I'm still trying to organize around the idea of having
an external library to load and make as few changes directly in the
vanilla source code.
Chuck
On Wed, Mar 23, 2011 at 1:51 PM, Hans-Christoph Steiner
<h...@at.or.at> wrote:
What's the end goal here? You want an object that acts like a
t_canvas/t_glist?
.hc
On Mar 13, 2011, at 3:31 PM, Charles Henry wrote:
I've been working through my CUDA Pd project, and I ran into the
problem of making externals that copy the canvas class.
My first idea was that I wanted a completely separate class with
different methods using glist. Calls from Pd looking for t_canvas
work just fine, but functions like pd_findbyclass that look for
canvas_class fail. I started mucking around in the pd src, and I
think it's just too difficult and would make onerous changes that I
don't like.
Is there something I'm not getting about canvas classes and externals?
My second approach to creating an external library is to modify
glist by adding an "unsigned int gl_hascuda" variable. I'd still
prefer solutions that make use of entirely external libraries over
modifying src, but this small change gets me half the way there.
Then, I just need to write the creator functions and the class works.
Chuck
_______________________________________________
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev
----------------------------------------------------------------------------
"[T]he greatest purveyor of violence in the world today [is] my own
government." - Martin Luther King, Jr.
----------------------------------------------------------------------------
"A cellphone to me is just an opportunity to be irritated wherever you
are." - Linus Torvalds
_______________________________________________
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev
