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
-
james tittle -
Johannes M Zmoelnig