3 ms·
I think your idea is completely crazy. Feel free to disagree. I think the only realistic way forward without breaking backwards compatibility is to build a new
by exDM69 12y ago
I think your idea is completely crazy. Feel free to disagree.
I think the only realistic way forward without breaking backwards compatibility is to build a new low overhead close to the metal API and implement OpenGL on top of that (e.g. adding a new MESA backend). Doing a new API on top of OpenGL first is quite impossible.
But I wouldn't mind breaking backwards compatibility either. I think D3D does the right thing here and every major version is incompatible with the previous version. Porting to the next version isn't too difficult (mostly a search and replace job) but it's still not source or binary compatible. I think this is the major reason why D3D is a cleaner API.
> If driver overhead is minimized, so that OpenGL is as thin a layer as possible over the real hardware, then changing the API becomes trivial: you can just wrap OpenGL and expose any API you want on top.
Given the convoluted mess that OpenGL drivers are (I work on one), it is very unlikely that such things will happen. We can't reduce driver overhead by adding new stuff. Some parts we can help (see the "Approaching Zero Driver Overhead" talks) but there's still an inherent overhead from all the state validation and other complexities.
Also, wrapping OpenGL into anything nicer isn't really possible. Otherwise there would be lots of neat 3D APIs implemented on top of OpenGL and you could choose whichever you like. But it's impossible to work around the idiosyncrasies of OpenGL.
And writing wrappers is fundamentally incompatible with low overhead anyway.
> Then, if someone writes a popular API wrapper, Khronos can take that API and standardize it as the next version of OpenGL
That "someone" would need to be a major established player and the API must be something that actually catches on. It must be complete and functional.
Khronos isn't just going to fork a random dude's GitHub project and go from there. There are practical reasons but let's not forget the legal issues either.
This scenario isn't just gonna happen.
- modeless 12y ago>build a new low overhead close to the metal API and implement OpenGL on top of that This is a great idea and it should happen, but a Khronos committee is not the right place to do it. The only way it could end well is if the API is first designed and implemented outside of Khronos and Khronos's only role is to standardize it with minimal changes. For example, if Khronos decides to adopt Mantle as the basis for this new API, with a few changes to make it generalize better to all vendors' hardware, then that would be a good outcome. I fear that politics may not allow something like that to happen, and that's why I think a more incremental approach is better, but perhaps I'm too pessimistic.
- exDM69 12y ago> This is a great idea and it should happen, but a Khronos committee is not the right place to do it I'm afraid that Khronos is the only entity that can possibly do something like this. However, as you suggest it might be possible that the basis of a new API is one of the new proprietary APIs like Mantle or Metal. You seem to have some kind of dislike for Khronos but I don't think there is any better entity out there. The problem with Khronos is that it's understaffed and underfunded and for many of the people doing the hard work it's their secondary job.
- iandanforth 12y agoI hope that someone is either Facebook/Occulus or Google.