[PD-dev] gem & 3dp/pf/pdp/pidip
chris clepper
cgc at humboldtblvd.com
Thu Sep 9 00:31:01 CEST 2004
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
More information about the Pd-dev
mailing list