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