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