[PD-dev] canvas class polymorphism

[Hans-Christoph Steiner]

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  
> <hans at 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 at 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20110323/f480c6e1/attachment-0001.htm>