A vertex program is limited to the number of registers in the hardware. I don’t imagine it’s possible for a VP to randomly access AGP or video memory (although it doesn’t seem too unreasonable as an automatic pre-step to a vertex state program to fetch and load some data to registers…). But here’s a sceheme I can almost imagine working:
Take an AGP/VideoMem/VBO array with one or more matrices up front and then the usual vertex data. Assume this will only work with a VP, where the matrices or arbitrary small data are [somehow] automatically loaded into specified VP registers. This would allow very fast matrix switching and VP vertex blending and all sorts of things I’m working on (like parametric object construction, needing more data). The API overhead to fill those registers is relatively heavy and forces me into a synchronous rendering model.
So what needs to happen to make this work? I’d imagine the matrices in the buffer would get loaded to VP registers (via something like the MatrixTracking [ARB?] API) and the AGP vertex-data pointers would be advanced by the appropriate amount before the VP begins to iterate over the buffer.
Could this be done with some combination of a vertex state program and some driver-side cleverness to advance the pointers?
Can the MatrixTracking API take AGP data already? Can it be modified to take AGP data specified as an offset into the currently bound client-array data?
Or does this mean we’d need another client-array set of API for such register-bound data?