The problem with this though, is if vendor X has some new feature which their hardware supports, then how can that be exposed?

ie, if you let the hardware vendor travel its way for a while, down the road it will cost you more to try bring it back to the main path.

Allowing vendor extensions is great, as long as the committee has the discipline to maintain everyone playing for the same team. Apparently it wasn't the case back in OpenGL 2, neither was in Longs Peak.

Keep in mind what happened in D3D9 where there was no extension mechanism -- there's still vendor-specific extensions!

You ended up doing things like device->SetRenderState( 'AMD!', 'COOL' ) to activate driver-specific magic hidden features...

https://www.khronos.org/files/opengl45-quick-reference-card.pdf

Can you really call it a "reference card" if it's 13 pages long?

The CAD crowd weren't too interested in the suggested new features that made OpenGL more suitable for game developers and maintaining backward compatibility for them caused many of the problems in the Longs Peak era.

Word is that - despite what was put-out at the time - Longs Peak wasn't actually killed by the CAD crew.

My suspicion had been that it was NVIDIA killed it, primarily because they had the best OpenGL implementation in consumer-land and may have been disinclined to throw it out and start again. It also seems consistent with their attitude towards GL3.x+ deprecation.

We should hear more tomorrow:

https://www.khronos.org/news/events/siggraph-vancouver-2014

And that's probably on top of my personal wish-list for Next Gen GL: kill off vendor-specific extensions. If we're going to have extensions at all, start them at EXT and require two or more vendors to implement them before shipping in public drivers; promote to ARB at the appropriate time.

That's kind of like putting the cart before the horse; it's not the features of OpenGL that moves hardware forward, it's the hardware that moves OpenGL forward. For this to be possible, those who are interested in the new features need to be able to try them out. That there is an established extension mechanism instead of everyone doing it in an ad-hoc way is good.

I'm not sure what you would supposedly gain by dropping vendor extensions? It's not like they can be used by mistake. Just pretend they don't exist and you already have the top of your wish list settled.

That's kind of like putting the cart before the horse; it's not the features of OpenGL that moves hardware forward, it's the hardware that moves OpenGL forward. For this to be possible, those who are interested in the new features need to be able to try them out. That there is an established extension mechanism instead of everyone doing it in an ad-hoc way is good.

That's the ideal world scenario.

The real world scenario - and we just need to look back at OpenGL history with buffer objects and low-level shading - is that vendor extensions just mean that each vendor ends up implementing it's own extension that's not necessarily compatible with, or even remotely similar to, other vendors'. I.e. in practical terms it's effectively identical to "everyone doing it in an ad-hoc way".

I think the point is that allowing vendor specific extensions allows for vendors to go "out in a tangent" too much, which could hamper standardization of such extensions in the future.

Yes, this, but also the fact that these tangents are not necessarily even the same. Vendor A may go off on tangent X, meanwhile vendor B goes off on tangent Y, and when time comes to pull X and Y back into a standardized ARB extension it just hampers the whole standardization process and we get two+ years of a committee doing what committees do best.

In practical terms, vendor extensions are really good for one target audience only: those who want to write techdemos that target one hardware generation from one vendor only. In a shipping application that is going to be used by real end-users with a variety of different hardware, you almost certainly want a single standardized code-path to take, and you almost certainly prefer that vendors invest time and effort in making that code-path as robust and efficient as possible.

The recent OpenGL evolution of a new minor version each year with a major version bump reflecting (roughly) a new generation of hardware is a good move in the right direction but I don't think the minor version bump is happening often enough. Every 6 months would be more like it, especially given the pace at which hardware evolves these days.

In practical terms, vendor extensions are really good for one target audience only: those who want to write techdemos that target one hardware generation from one vendor only. In a shipping application that is going to be used by real end-users with a variety of different hardware, you almost certainly want a single standardized code-path to take, and you almost certainly prefer that vendors invest time and effort in making that code-path as robust and efficient as possible.

They are mostly just good for tech demos and people who can afford the luxury of / have no option but targeting specific hardware, yes. And you want to take this away from these people why again?

Just pretend they don't exist and you have the same result as if your wish came true.

The recent OpenGL evolution of a new minor version each year with a major version bump reflecting (roughly) a new generation of hardware is a good move in the right direction but I don't think the minor version bump is happening often enough. Every 6 months would be more like it, especially given the pace at which hardware evolves these days.