Quote Originally Posted by allquixotic View Post
This is such a great idea. We should be able to use the low-level hardware access provided by Gallium3d to build a reference implementation of this nebulous new API as a G3D state tracker! Ideally the state tracker should be written with as little hardware-specific binding as possible, and version 1.0 should have the ability to reliably report on hardware capabilities, software emulated capabilities, and completely unsupported capabilities, with a well-defined interface that doesn't involve any guesswork or string parsing, and uses an easy-to-understand object model with predictable semantics, common computing terminology used as much as possible (avoiding graphics domain-specific technical terms unless they are completely unavoidable), and with a design goal of minimizing the amount of work that would be required of an engine author. Almost to the point that actually "writing" a 3d engine on top of this API would be a mimicry of the API itself. Basically, you'd get a low-level 3d engine as a Gallium3d state tracker, but still with enough flexibility to do crazy things like portal effects and non-3d geometries.

The gallium3d infrastructure may not be the end-all of APIs, but it is the best hardware-independent 3d graphics API we have in the free world right now. And it's only on version 0.4; I am sure it will improve. But what's the use of improving it if the end-user API on top of it is the culprit of most of the semantic mismatch you see?
If this was done, wouldn't that mean that application developers would have to target the code for it and that the OpenGL apps not work with such drivers? Also, apps that use such graphics wouldn't work with OpenGL drivers, right?