[PD-dev] gem & 3dp/pf/pdp/pidip

[chris clepper]

On Sep 8, 2004, at 3:08 PM, Tom Schouten wrote:

> ok. of course. i was thinking about an internal gem object.
> i plan to use yves' object as a template because it already solves
> most gem<->pdp interface and build problems.

Yes, I was referring to those existing bridge objects from Yves.

> yes. and the gem2pdp bridge uses glReadPixels, which is i think
> slow for almost all video cards/drivers..

glReadPixels has gotten better on the Mac recently, but it is still at 
the mercy of the AGP design which is optimized for uploads to the card 
and not reads from it.  Even AGP 8X still only has a 1X 233 MB/sec read 
rate - and that defers to any and all uploads.

>> something I've been meaning to look into would be adding
>> support for just planar YUV to YUV 4:2:2, or also allowing straight
>> planar YUV copies (there's recently been a planar YUV quicktime codec
>> released 3rd party, IIRC)...
>>
>
> you mean as a pix buffer, or a texture?

I would suggest having the pix_ buffer in RAM as one very easy set of 
bridges to make, since those are fairly easily done.  Any and all 
conversions have a pretty decent chance of hot-rodding through 
Altivec/SSE.

The texture part is quite another story as it could tie into the 
discussion about multiple render targets.  Having GEM and PDP share 
contexts and textures then one could render part of the chain in one 
and switch it to the other for further processing.

> so, basicly, if i wrap the gemstate object, i should be able to get
> to everything. i think this might be what i'm looking for.

Yep.  Adding the GemState to all of the PDP 3D objects  would pretty 
much allow any objects in PDP to work in a GEM render chain.

>>> so if the 3dp object would echo anything that comes in,
>>> but use the message just as a synchronization for when to
>>> execute the GL code, would this work?

It would be interesting to actually have the PDP objects manipulate the 
data passed with the GemState.  For example, you could write some 
texture coordinate manipulations, add a display list or detect lighting 
changes.  At some point the vertex arrays will stabilize and that will 
offer more fun as well.

> hmm. maybe it's a better idea if i use the stable version of GEM,
> (which is 0.90, right?)

I believe v_090 is the tag to check out.

> so it can be tested by more people. i don't think i can get this right 
> and
> forget about it in a couple of hours, so it would be best to aim at
> easy testability instead of hot features for now.

0.90 should provide you with a stable base to work from, and right now 
the only major changes I know about to GemState is the addition of the 
vertex_array data.  That addition is only a few flags and four 
pointers, which do not change the way any of the other state data 
works.

Make sure you are on the gem-dev list as well!

cgc