Quote:Original post by gold
The plan is backward compatibility, hence a transition from old interfaces to new rather than a sudden shift. As such the new capabilities will be introduced as extensions initially. Some already exist, e.g. vertex and fragment shaders as a replacement for fixed function T&L and texenv, respectively. When the legacy functionality officially becomes deprectated and/or layered remains to be seen.
While new functionality (geometry shaders, texture arrays, render to vbo etc) should definitely be exposed through extensions, won't a slow transition to new interfaces be cumbersome, changes one after the other, all the while the interactions between the new features ?
Why not make a software rasterizer to test and prototype all the interfaces for exposing functionality and release it so that developers do get access to new interfaces and functionality without it being wedged in the current clutter of the API?
Would people react better to:
A) Here is a new way to manage Texture objects, a month later a new way to specify and use constant buffers, another month later geometry shaders...
OR
B) Here is the new api and a refrast so you can play with it before the hardware is available, to manage different buffers, to convert between them, different shader types etc. let us know what else you would like to see?
I feel B would be a more successful release strategy. Note that I don't think this makes much difference to the experienced 3d guru, but for intermediate GL programmers it would.
