Well, ATI has an ATIX concept where they’ll develop experimental extensions which may simply go away in the next driver revision. They didn’t use this for looping and conditional features though…
Any time you write an extension, it consumes resources. You have to specify it, code it, and test it. Writing the specification in an intelligent way that addresses all the issues of interacting with the rest of the OpenGL system is not easy. Doing all this for throw-away code is a bit wasteful.
If you aren’t writing throw-away functionality, then you also have to add ‘code maintenance for the lifetime of the product’ to resource consumption.
The fun bit is that, even though you went to all this effort, your extension will only see limited use because some people prefer industry-wide standards. And regardless of whether the software developers support your specialized extension or not, any /good/ feature will be standardized by the industry…
So if the feature is valuable, you’ll have to rewrite support for it. If it’s not valuable, why did you bother?
On the ISV side, you have a slew of new extensions coming out. There’s not much point in your product supporting VEND_SPIFFY1 when VEND_SPIFFY2 is coming out in two months time.
Then again, if you software drives the feature set, before it’s in hardware you get problems with the spec not relefcting the way the actual hardware winds up needing to work. You get lots of cards only supporting a feature in software, so it’s too slow to be of general interest. You have a specification without a user base… wasted effort.
In each of these situations, the effort wasted COULD have been spent on coming up with an industry-standard specification with broad IHV and ISV support. One that could be rolled into the core in a future release. One with longevity.
Then again, when you do that, you get complaints about high-end features not being exposed quickly enough 8P It’s a no-win situation, eh?
Have fun,
– Jeff