On Dec 9, 2004, at 6:33 PM, Yves Degoyon wrote:
congatulations, amigo.
...just glad to be able to move forward with what we talked about in bergen!
you find the answer to something we've been searching for months.. well, not so much, each time i could get hold of a mac.
...well, it's only one blockage removed: it's still crashing immediately at the beginning of processing :-(
...looking back at mail archives, I see that I'm also getting this weird behavior: when it's loaded, the intro message is doubled in the console:
pdp2gem : a bridge between PDP/PiDiP and GEM v0.5 (ydegoyon@free.fr) pdp2gem : a bridge between PDP/PiDiP and GEM v0.5 (ydegoyon@free.fr)
...and then when I look at the backtrace on crashing, I see that we've entered the pdp/render loop twice?
any ideas?
jamie
james tittle wrote:
On Dec 9, 2004, at 6:33 PM, Yves Degoyon wrote:
congatulations, amigo.
...just glad to be able to move forward with what we talked about in bergen!
you find the answer to something we've been searching for months.. well, not so much, each time i could get hold of a mac.
...well, it's only one blockage removed: it's still crashing immediately at the beginning of processing :-(
...looking back at mail archives, I see that I'm also getting this weird behavior: when it's loaded, the intro message is doubled in the console:
pdp2gem : a bridge between PDP/PiDiP and GEM v0.5 (ydegoyon@free.fr) pdp2gem : a bridge between PDP/PiDiP and GEM v0.5 (ydegoyon@free.fr)
...and then when I look at the backtrace on crashing, I see that we've entered the pdp/render loop twice?
mm, not really. is it my version or a version you modified? in the second case, could you send me the code?
cheers, sevy
any ideas?
jamie
PD-dev mailing list PD-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-dev
On Dec 10, 2004, at 10:27 AM, Yves Degoyon wrote:
pdp2gem : a bridge between PDP/PiDiP and GEM v0.5 (ydegoyon@free.fr) pdp2gem : a bridge between PDP/PiDiP and GEM v0.5 (ydegoyon@free.fr)
...and then when I look at the backtrace on crashing, I see that we've entered the pdp/render loop twice?
mm, not really. is it my version or a version you modified? in the second case, could you send me the code?
...I'm just using the code in the puredata externals cvs: should I try something else?
jamie
james tittle wrote:
On Dec 10, 2004, at 10:27 AM, Yves Degoyon wrote:
pdp2gem : a bridge between PDP/PiDiP and GEM v0.5 (ydegoyon@free.fr) pdp2gem : a bridge between PDP/PiDiP and GEM v0.5 (ydegoyon@free.fr)
...and then when I look at the backtrace on crashing, I see that we've entered the pdp/render loop twice?
mm, not really. is it my version or a version you modified? in the second case, could you send me the code?
...I'm just using the code in the puredata externals cvs: should I try something else?
this code runs ok on linux, never been tested on OSX.
cheers, sevy
jamie
james tittle wrote:
On Dec 9, 2004, at 6:33 PM, Yves Degoyon wrote:
congatulations, amigo.
...just glad to be able to move forward with what we talked about in bergen!
hi all. sorry for cross-posting....
just for me to get an idea: what have you talked about in bergen ?
just a summary about the gem/pdp-bridge (most is just guessing) [gem2pdp] and [pdp2gem] are there for quite some time (thanks yves) [gem2pdp] is slow (as it needs to grab the render-buffer) [gem2pdp] is somewhat clumsy as you need a gem-window even though you want to produce something in a pdp-window. (this is a problem of Gem)
the "other" idea (tom's) was, to be able to build include pdp-chains within gem-chains; this is: one library would be master, the other one would be slave, as opposed to the egaliterian "bridge"-solution. it might be easier to code if Gem was master (as a first step).
now how to avoid doubling of efforts ?
mfg.a.sdr IOhannes
On Dec 13, 2004, at 5:41 AM, Johannes M Zmoelnig wrote:
james tittle wrote:
On Dec 9, 2004, at 6:33 PM, Yves Degoyon wrote:
congatulations, amigo.
...just glad to be able to move forward with what we talked about in bergen!
hi all. sorry for cross-posting....
...not a problem!
just for me to get an idea: what have you talked about in bergen
just a summary about the gem/pdp-bridge (most is just guessing) [gem2pdp] and [pdp2gem] are there for quite some time (thanks yves) [gem2pdp] is slow (as it needs to grab the render-buffer)
...this is what we talked about: speed issues. It's long been on my to-do list, and for some reason I found myself seriously looking at it last week...So I started to look at it and quickly found that on OSX, they won't even load because of an os-specific flag that prevent externals from seeing other external's symbols! Luckily there's a way around this, which I submitted as a patch to pd cvs...
...so then I started working on [pdp2gem], and now have it working with different colorspaces: I've made it default to converting to uyvy...it was really slow originally because it converted to RGB, and then the example patch had the [pix_RGBA] inline, which we don't need anymore...my next step here would be to altivec the rearrangement: as it is now, a quick comparison showed that before, with a 320x240 movie, it was using 50+% just to play a movie...with the yuv swapping, it only takes about 6-10%, which is what pd usually produces on osx when just sitting there (and audio on)...
...[gem2pdp] is another story because it's trying to do something different than [pdp2gem], which just does a buffer copy in cpu memory...this of course means that, atm, 3dp output can't be transferred into gem...so, it wouldn't be hard to make [gem2pdp] more similar, and just copy the cpu side buffer into a YV12 buffer...
...otoh, this obviously reduces the utility of the bridge, but there is a possible speed up without using glReadPixels()...apparently the same method (client_storage hints)we use to speed up texture uploads via AGP can be used in the other direction: just found out about this, so I haven't tested it...
[gem2pdp] is somewhat clumsy as you need a gem-window even though you want to produce something in a pdp-window. (this is a problem of Gem)
...yeh, this is of course necessary because we need a window & context to render to, but this could go away perhaps with the new multiple_window code: just render to an offscreen window...
the "other" idea (tom's) was, to be able to build include pdp-chains within gem-chains; this is: one library would be master, the other one would be slave, as opposed to the egaliterian "bridge"-solution. it might be easier to code if Gem was master (as a first step).
...I think this is more for libpdp and such: my target atm is pdp-0.12-4, because that's in wider use atm...so I don't think there'd be much duplication, as I'm just doing the dirty work of optimizing yv12 to/from other pixel formats ;-)
l8r, jamie
james tittle wrote:
On Dec 13, 2004, at 5:41 AM, Johannes M Zmoelnig wrote:
the "other" idea (tom's) was, to be able to build include pdp-chains within gem-chains; this is: one library would be master, the other one would be slave, as opposed to the egaliterian "bridge"-solution. it might be easier to code if Gem was master (as a first step).
...I think this is more for libpdp and such: my target atm is pdp-0.12-4, because that's in wider use atm...so I don't think there'd
i am not really sure about this (so that is why tom is in the explicite receivers' list of the thread tooo...)
[gem_pdp.out] would just emit normal pdp-packets, so i think these would be understood by older pdp objects too. i am not completely sure, what would be the content of these packages: probably just the pixel-stuff (in case someone wants a Gem-pixel-source) and the knowledge, that there is a valid openGL-context right now (which would even allow to use (unthreaded) 3dp)
btw i guess this would also allow the usage of pdp on windows, as the only non-portable things are (i think) input and output (which would be handled by Gem)
be much duplication, as I'm just doing the dirty work of optimizing yv12 to/from other pixel formats ;-)
so this means, you are hacking GemPixUtils ? good!
mfg.a.dr IOhannes