[GEM-dev] Re: [PD-dev] pdp2gem question
tigital at mac.com
Mon Dec 13 16:23:09 CET 2004
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
> 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 ;-)
More information about the Pd-dev