Originally posted by vs:
Sorry, but I have to disagree.
Fair enough. If ya gotta disagree, ya gotta disagree.
Still not convinced though.
Current consumer architectures typically bottleneck on bus bandwidth, not CPU speed. If you have to transfer a float*, then the float itself, you’re potentially doubling your bandwidth requirement. Things are definitely moving in the direction of having GPUs pull large stretches of vertex data directly (e.g. from AGP), without any intervention from the CPU. This proposal - constantly switching backwards and forwards between the app and GL - is going in the opposite direction.
My main gripe, though, was that you seem to be sacrificing render performance for geometry update performance. This would be fine if you were talking about ROAM landscapes or skinned character animation, but for bunches of axis-aligned cubes it just doesn’t seem like such a good tradeoff.
Wanting a simpler solution is fine, but if that’s your only motivation - if you aren’t pushing performance or spangliness envelopes - a simple helper function would give you the same convenience and memory-saving benefits. Either by constructing vertex arrays on the stack, or just tweaking the modelview matrix and calling a dlist.
I just don’t see it happening. If you look at the ARB members, they’re mostly interested in gaming, CAD and vis-sim; from that perspective, this is an obscure corner case. Not to denigrate business gfx in any way, but most of the ARB are ultimately out to sell stuff, and people don’t buy geForce3 cards to display bar charts.
There can be nothing wrong with a bit of choice.
I’m not so sure. A huge amount on traffic on this board is already taken up with questions on the relative performance of different approaches, or dealing with odd combinations of features. Once you step outside the cosy you-know-it’s-going-to-be-optimized world of “what Quake does”, the existing GL feature set is already a minefield. Driver writers only have a finite amount of time; in many ways I’d prefer it if we could standardize on a few very general approaches. Adding special-case code paths all over the place just makes things worse.