[GEM-dev] Re: [PD-dev] pdp2gem question

[james tittle]

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