4 ms·

> but a standards body is not the place to do those things. Whose job it would be then? There is AMD's Mantle and Apple's Metal as well as Google's somewhat r

by exDM69 12y ago

> but a standards body is not the place to do those things. Whose job it would be then? There is AMD's Mantle and Apple's Metal as well as Google's somewhat related RenderScript. As long as they're going to remain a single vendor API, they will be adapted as an universal new API. But hopefully the work by these vendors (all of which are Khronos members) will serve as a basis for a future standard API. Longs peak was a failure and the API was very complicated. It was definitely a failure due to design by commitee. But in the end, there has to be an industry consortium to standardize on a new API. When we're talking about an API that is closely tied to the hardware it runs on (which is a lot more expensive to develop than APIs and software), there's no other option than to get all the big players around the same table. Right now, Khronos is the most likely candidate since all the key players are members in that group. At some point there has to be a new API. OpenGL isn't just an API with some warts in it, it's getting more and more in the way of new development.

modeless 12y ago
Focusing on reducing driver overhead is the right way forward. 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. Then, if someone writes a popular API wrapper, Khronos can take that API and standardize it as the next version of OpenGL, no design-by-committee required.
- fzltrp 12y ago
  > Then, if someone writes a popular API wrapper, Khronos can take that API and standardize it as the next version of OpenGL, no design-by-committee required. If that wrapper actually supports all the features evenly, and doesn't favor a particular implementation. Is that possible outside a design by committee?
- 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 ago
      I hope that someone is either Facebook/Occulus or Google.

by exDM69 12y ago

modeless 12y ago

Focusing on reducing driver overhead is the right way forward. 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. Then, if someone writes a popular API wrapper, Khronos can take that API and standardize it as the next version of OpenGL, no design-by-committee required.

fzltrp 12y ago
> Then, if someone writes a popular API wrapper, Khronos can take that API and standardize it as the next version of OpenGL, no design-by-committee required. If that wrapper actually supports all the features evenly, and doesn't favor a particular implementation. Is that possible outside a design by committee?
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 ago
    I hope that someone is either Facebook/Occulus or Google.