The Siggraph 2014 slides have been released; pdf here

Of particular note is page 72;

- compatibility break with OpenGL
- start from first principles

- clean modern arch
- multi-thread/core friendly
- greatly reduced cpu overhead
- arch neutral - support for tile-based as well as direct renderers
- predictable performance
- improved reliability and consistency between implementations

- explicit control - app tells driver what it wants

The first point is the most important for me; breaking GL compat means it won't be dragged down by legacy so yay!

I don't really understand this point of view. Who/what is being dragged down in what way? If the old functionality isn't good enough for you then just don't use it?

I don't really understand this point of view. Who/what is being dragged down in what way? If the old functionality isn't good enough for you then just don't use it?

In an ideal world this would be enough.

It's not an ideal world. This isn't about the old functionality, it's about the old driver overhead, the old lack of threading support, the old "6 different ways to do the same thing and the fast path is different for each vendor" crap, the old GL extension hell, the old GLSL version hell. Unfortunately we don't have a choice to not use these - current OpenGL forces them on us.

Despite the lack of confidence resulting from previous failures to deliver Long Peaks, this time looks like it will happen.

There is great people behind the GL (like Graham Sellersfrom AMD & Christophe Riccio). There is Mantle that can serve as a baseline (honestly if the just Find & Replace 'gr' for 'gl' we all would be happy!) GL has been adding a lot of so-much-needed functionality recently at an increasing rate (the Board used to be an insanely slow turtle!!!). They've added Johan Andersson who is very experienced and more importantly, results oriented.

Furthermore, there is a strong need for GL to move forward: 5 years ago everything was Windows and DirectX.

Today we have Google pushing GL into Android (and a countermeasure against Apple's Metal API) with a huge market share, Qualcomm also wants to push GL in mobile; GL still being the only choice to target China's huge WinXP user base with DX10 & 11 GPUs; Valve wants to push GL in their SteamOS, and MS still pushing their latest DX updates tied to OS (not to mention that they fell asleep to develop DX12)

Basically, we are like in 2006 situation with DX10+Vista vs Long Peaks. Except this time there is more incentive, a Board that is actually acomplishing things, and a Mantle proof of concept.

I hope this time they make it.

I don't really understand this point of view. Who/what is being dragged down in what way? If the old functionality isn't good enough for you then just don't use it?

In an ideal world this would be enough.

It's not an ideal world. This isn't about the old functionality, it's about the old driver overhead, the old lack of threading support, the old "6 different ways to do the same thing and the fast path is different for each vendor" crap, the old GL extension hell, the old GLSL version hell. Unfortunately we don't have a choice to not use these - current OpenGL forces them on us.

Well, you'll likely only get rid of the old stuff in theory anyways. All the vendors will need to provide drivers for older versions of OpenGL, otherwise people will be pissed that their favorite games and apps stopped working. They will most likely provide these in the same driver as the new stuff. They will most likely yet again introduce an official "compatibility" extension that implements all the old functionality and is optional in theory, but in practice will be implemented by all, since they have to ship it with their driver anyways.

edit: The point being that if you are finding this difficult today, it's about to get even more difficult.

Well, you'll likely only get rid of the old stuff in theory anyways. All the vendors will need to provide drivers for older versions of OpenGL, otherwise people will be pissed that their favorite games and apps stopped working. They will most likely provide these in the same driver as the new stuff. They will most likely yet again introduce an official "compatibility" extension that implements all the old functionality and is optional in theory, but in practice will be implemented by all, since they have to ship it with their driver anyways.

edit: The point being that if you are finding this difficult today, it's about to get even more difficult.

Fortunately in this case we are in an ideal world.

Something like Mesa, for example, can be taken and rewritten as an emulation layer that converts oldGL calls into newGL calls. That's option 1 and it can be carried out by the ARB, by a consortium of vendors and/or other interested parties, or even by an open source community.

Option 2 is that oldGL is feature-frozen at version 4.5, vendors continue to ship their current GL drivers, and they also ship newGL drivers. They're currently shipping both GL and D3D drivers so shipping multiple drivers is a solved problem.

This isn't a binary case of "don't do it at all" versus "do it and completely wreck compatibility, throwing away 20+ years of software heritage". These are all problems that can and will be solved.

What's more, we're going to be in a much better position going forward too. Wouldn't it be great if option 1 was chosen and we ended up with a really really nice and robust oldGL emulation layer that also enabled the likes of AMD to ship a non-buggy newGL driver? Or that enabled certain oldGL 4.x+ features on older hardware that can support them but for which the vendors no longer ship drivers? That's an "everybody wins" scenario.

I wouldn't have any issues with it happening as either of those two, but the ARB has done it the way I described in the past. All of the fixed function stuff was removed from OpenGL 3.1. There is an optional extension that includes all the old stuff. Which is supported by all hardware vendors that I know of, so in practice it meant nothing.

I find it hard to belive that the ARB would take the time to create an emulation layer. They can't even get their reference GLSL compiler straight. A lot of it I belive was written by Valve because they had a dire need for the functionality it does have. So who in the ARB would have a dire need to help write a compatibility layer? The most probable candidates would be the vendors themselves. However, already having the code in their existing driver, it would surprise me if they bother.

Nobody thinks it's sexy to fiddle with the old stuff, so my bet is that they'll chose the path of least resistance and implement compatibility the same way as they did in 3.1.

Well, you'll likely only get rid of the old stuff in theory anyways. All the vendors will need to provide drivers for older versions of OpenGL, otherwise people will be pissed that their favorite games and apps stopped working. They will most likely provide these in the same driver as the new stuff. They will most likely yet again introduce an official "compatibility" extension that implements all the old functionality and is optional in theory, but in practice will be implemented by all, since they have to ship it with their driver anyways.

Except there is no reason for that to be the case.

OpenGL up to 4.5 and beyond using the old model can live in it's own code path, as it currently does (note the separate GL dlls which come with your driver - it is already split up) and in it's current state could live on forever, heck if they wanted to layer it on top of GL:TNG they can as long as the functionality remains the same.

GL:TNG however can be, and will be, a new software stack. There is no need for any of the old functionalty/extensions/programming model to exist because it simply won't be there or needed. This is a DX9 to DX10 breaking change; the API changes, the rules change AND with NO EXISTING SOFTWARE using this API they are free to do what they want.

And that has been GL's problem ever since OpenGL3.0's failure to redesign the API; the API remained the same and so people using it would just layer on top of it which is why you couldn't remove the functionality. Heck, there was no push to remove it because it would be so entwined in the existing code base it would probably be more work to pull it out and separate into a new 'new only' code path that keeping it makes more sense.

GL:TNG doesn't have that problem.
No one is using it.
There is no compatibility to maintain.
This is Version 1.0 of a brand new API, folded under the banner of OpenGL but as distinct as D3D9 is to D3D11.

And with all that stuff removed,
Without the need to deal with multiple extensions influencing the state,
With a more explicate model where the application drives the functionality,
Without all that the driver itself becomes simpler, does less work, has less overhead and is faster.

OpenGL4.5 won't suddenly go away and stop working, it'll stick around for a while in the same way that D3D9 based games still work but if you are coding OpenGL4.5 then you won't interact with this new model at all because it is a different API.

So there is no worry about interactions, no worry about compatibility layers and other things gumming up the GL:TNG because it isn't needed.

You might think 'well, its dumb to throw all that compatibility away' but the truth is professional developers are use to working with multiple APIs, we've done a D3D9 to D3D11 transition, we've dropped the PS3 rendering code in favour of the new API for the PS4, teams right now have, or are, jumping on Mantle and implementing it in a matter of months. We deal with multiple incarnations of the GL|ES runtime. Apple's Metal is a welcomed thing in the industry.

You might say 'what about the hobbyists?' and to that I say 'what about them?'.
OpenGL is not "the people's API" - if it wants to stay relevant it needs to be driven by the needs of the big AAA studios (who are the ones who sell gfx cards too).
Hobbyists still get OpenGL as it stands now.
Those wanting to enter the industry will be wanting to use the newest API.
And those not wanting to care will pick an engine like UE4.

And this is the best future.
It's a way of working we are use to.
It's a way of working which will get the best results.
It's a way that MS has successfully used for a few versions now.

Compatibility with 'now' isn't a problem.
And this is a good thing.

I wouldn't have any issues with it happening as either of those two, but the ARB has done it the way I described in the past. All of the fixed function stuff was removed from OpenGL 3.1. There is an optional extension that includes all the old stuff. Which is supported by all hardware vendors that I know of, so in practice it meant nothing.

This is really misrepresenting what happened with 3.1.

First of all you didn't have to throw out your old code. Old code still worked.

Secondly, new code could still be written to target 3.0 or below and you could pretend that the whole compatibility/core thing never even existed.

Thirdly if you wanted to access higher features, you could still create a 3.0 or lower context and in many cases they'd be available as extensions.

Nobody forced you to stop using the fixed function stuff. It's still there and the number of programs that use it mean that it will always be there. Even dear old Quake still works on a modern GPU.

I encourage you to read Phantom's post above mine, in particular where he notes that this is already a solved problem for the hardware vendors with D3D. D3D10 threw out all the old fixed functionality stuff. Guess what? You can still write a D3D 7, 8 or 9 program that uses it if you wish.

There's no need for you to make such an issue out of this. Seriously, it's already a solved problem and has been for the 20-odd years that D3D has been in existence. Granted, it's understandable that you'd be concerned if this mode of API evolution is new to you, but the answer is simple. Don't want to use the new API? Then just don't use it. Continue using the old headers, link to the old libs, download a driver from your hardware vendor and it's as if nothing has changed.

The only difference is that you'll be feature-frozen (although I predict that NV at least will continue shipping new features as vendor extensions for some time), but again that's something that people have also happily just gotten on with in D3D-land for 20-odd years.

What it comes down to is that this is a very pragmatic move from Khronos. The current state of GL is that one needs to spend far too much time struggling with crap instead of being productive (today's story: trying to get GL_ARB_explicit_attrib_location working on an Intel HD 2000) and it can't keep evolving that way.

I'm gonna call the redesign as NextGL or NGL

Something that might be worth saying, a NextGL API that is low level means that it is perfectly possible to provide an efficient OpenGL 4.x (and older) implementation working on top of NextGL (i.e. a GL to NextGL wrapper).

Such implementation could be done by anyone (i.e. open source). No need for the driver developer to ever care about it again.

The same could be said about an OGL to DX12 wrapper; however NGL will be cross plattform too, and thus a GL to NGL wrapper can be much more reusable (i.e. Android, Linux & SteamOS, Windows; and if Apple joins; the iOS family too).

Despite the lack of confidence resulting from previous failures to deliver Long Peaks, this time looks like it will happen.

There is great people behind the GL (like Graham Sellersfrom AMD & Christophe Riccio). There is Mantle that can serve as a baseline (honestly if the just Find & Replace 'gr' for 'gl' we all would be happy!) GL has been adding a lot of so-much-needed functionality recently at an increasing rate (the Board used to be an insanely slow turtle!!!). They've added Johan Andersson who is very experienced and more importantly, results oriented.

Furthermore, there is a strong need for GL to move forward: 5 years ago everything was Windows and DirectX.

Today we have Google pushing GL into Android (and a countermeasure against Apple's Metal API) with a huge market share, Qualcomm also wants to push GL in mobile; GL still being the only choice to target China's huge WinXP user base with DX10 & 11 GPUs; Valve wants to push GL in their SteamOS, and MS still pushing their latest DX updates tied to OS (not to mention that they fell asleep to develop DX12)

Basically, we are like in 2006 situation with DX10+Vista vs Long Peaks. Except this time there is more incentive, a Board that is actually acomplishing things, and a Mantle proof of concept.

I hope this time they make it.

You forget one issue: it's still a comittee...