On Dec 20, 2008, at 4:03 PM, Claude Heiland-Allen wrote: > John Harrison wrote: > [snip] >> And for me Gem also breaks many coding conventions of Pd. >> >> I'm not trying to trash Gem. I have the utmost respect for its >> developers. I don't doubt it will be phenomenal with time and I >> wish to >> support its continued development. But I am hesitant to recommend it >> while it is in its current, perhaps unfinished, state. Example and >> test >> patches work fine but outside of that realm my experiences have >> not been >> positive. I have plans to document the problems I had and my thoughts >> about the coding conventions. It's possible I'm misunderstanding some >> things and/or maybe my concerns will help for future development. > > I agree - I'd also extend the hesitation to Pd itself but that's > another > matter entirely. I started writing a mail on a tangent to this topic > (mainly sparked due to frustrations that verbose and boring C is nicer > to work with than Gem for a project making heavy use of multipass > rendering with shaders) a day or two ago, I'll just paste it here > in its > current, perhaps unfinished, state: > > Hi all, > > Wondering if there are any plans for dataflow on the GPU in Gem? > > By this I mean that a patch cord would be a representation of pixel > data > transfer paths on the GPU, and objects would process pixel data on > the GPU. > > I also do not mean using depth first message passing as a mechanism to > shoehorn OpenGL state machine into Pd without concern for dataflow > semantics (sorry if that sounds harsh - but it's the most > counterintuitive aspect of Gem imo). > > Mainly I would want Gem to take care of allocating any temporary > textures, binding/unbinding framebuffers + shaders, setting uniforms > from inlets, etc, as it's a pain to do it manually (in any language). > > Would it make sense to make a set of "proof-of-concept" abstractions + > shaders that port some subset of the pix_ objects to the GPU? > > Maybe this is all a bit too vague and I should do some research into > other "dataflow on the GPU" environments, if there are any...
You guys should check out 3dp aka pdp_opengl. I think Tom was trying to make dataflow+OpenGL feel more natural. Or perhaps gridflow does opengl. .hc > > > Claude > -- > http://claudiusmaximus.goto10.org > > _______________________________________________ > Pd-list@iem.at mailing list > UNSUBSCRIBE and account-management -> http://lists.puredata.info/ > listinfo/pd-list ------------------------------------------------------------------------ ---- Access to computers should be unlimited and total. - the hacker ethic _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list