Re: [PD-dev] canvas class polymorphism
On Wed, Mar 23, 2011 at 4:40 PM, Hans-Christoph Steiner h...@at.or.atwrote: 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. That's given me something to think about. How it might be done: functions need to be declared __device__ to run as serial processes on the GPU. There's no loss of what you can do in C on the GPU--it's just a lot slower clock and threading is different. Then, all the dynamic memory allocation routines would need to be changed. The functions to be called from the host would be declared __global__. It sounds cumbersome, but possible. Perhaps, it could be done for libpd--but then I know there's still ~10,000s of lines of code in libpd. I'm not a libpd user, so I don't know how I'd test it without the gui/editor. That's just conjecture, but I can't see a good way to simplify it yet. I think it's better to only apply CUDA to the major vectorizable operations, which is just signal operations, but also--I couldn't just apply it to *all* signal operations. So, I'd try to add the basic compatibility stuff for managing signals allocated on GPU... and then go back and try to incrementally add new signal externals from the Pd math tilde objects. For examples of reimplmentations of Pd, check out ZenGarden (C++) and Webpd (Javascript) http://mccormick.cx/projects/WebPd/ .hc I've been having fun playing with WebPd--but I'm not needing that tool just yet. Soon... soon... 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.atwrote: 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
Re: [PD-dev] canvas class polymorphism
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. ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] canvas class polymorphism
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.atwrote: 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. ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] canvas class polymorphism
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
[PD-dev] canvas class polymorphism
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
