The Third Annual Unofficial OpenGL Feature Awards!
And you thought I’d forgotten about you 
On to the awards!
We Did What We Said We Were Gonna Award:
ARB_direct_state_access
I’m not talking about the meat of the extension. I’m talking about the part of it that’s actually new: the fact that we finally get a function that merges name creation and object creation. One of the sillier bits of OpenGL was making these separate, but that was as a consequence of an even sillier bit of OpenGL: giving users the ability to decide what names were for themselves.
Long’s Peak promised a new object creation paradigm. And while LP was going to make virtually every object immutable, ARB_DSA builds a new object creation system that makes name and object creation synonymous. Just like sampler objects.
Which means that we finally have what Long’s Peak promised us (well, most of it). Now, isn’t OpenGL 4.5 such a much cleaner API for it? With our glorious Long’s Peak API, there are only two ways to do the same thing now. That’s progress.
And it only took them 8 years from the initial Long’s Peak announcement for us to get it
[STRIKE]One[/STRIKE]Two Little Mistakes Award:
ARB_direct_state_access
I hate to quibble about naming conventions and the like. But it truly amazes me how the ARB could debate the naming issue as extensively as it appears they did from the issues section. And with all of that debate and all of the possibilities before them, they still choose the worst possible alternative.
Couldn’t you guys have just agreed to flip a coin, one naming convention or the other? Sure, some APIs would have unwieldy names. I certainly don’t care much for the idea of having [var]glNamedCompressedTexSubImage1D[/var] or [var]glRenderbufferObjectStorageMultisample[/var]. But at least it would have been a convention; the unwieldyness of some function names would have been defensible by convention. With your way, not only do you have unwieldy names ([var]glInvalidateNamedFramebufferSubData[/var]), you can’t even justify it by citing a convention.
Also, the difference between “Named” and “Object” is exactly one character. The difference between “Named” and “exture” is exactly one character. The difference between “Named” and “Array” is zero characters.
So yeah, I don’t see how the non-“Named” APIs are so much better than the “Named” ones that they had to break convention.
Also: [var]glNamedBufferData[/var]. What were you thinking with that one? [var]glBufferStorage[/var] made [var]glBufferData[/var] completely obsolete. Everyone should always be creating immutable storage buffers. And you did it right for textures; you didn’t allow people to use the new API to create non-immutable textures. So why did you think this was a good idea?
Tail Wagging The Dog Award:
ARB_ES3_1_Compatibility
OpenGL ES exposed hardware, legitimate hardware, features that GL 4.4 did not. That’s something of an indictment of the ARB, that they somehow missed having imageAtomicExchange work on single-channel f32 images since 4.2. Which was in fact three years ago.
Well, hindsight is always 20/20. Then again, very few people know that Prometheus, the Greek Titan of foresight, had a brother named Epimetheus, the Titan of hindsight. There’s a reason there aren’t great tales of his exploits.
Let’s Make Geometry Shaders Even More Useless Award:
ARB_cull_distance
GS’s were a terrible idea. Originally envisioned as a means of tessellation, it turns out that they were terrible at that. So terrible in fact that they had to create two entirely new programmable stages and a fixed-function stage specifically to make tessellation worthwhile.
But that was OK, because GS’s gave developers the ability to write arbitrary data to buffer objects via transform feedback. So you could issue “rendering commands” that didn’t render, but were used to do things like frustum culling and the like. Oh but wait, 4.2 gave us compute shaders to make that completely irrelevant. CS’s can do all of that, and without the nonsensical faux rendering command.
But even that was OK. Because GS’s could still do something that no other shader stage could: cull triangles. Yes, the TCS could cull patches (little known fact: if any outer tessellation level used by the TES is zero, then the patch is culled), but it could only cull whole patches at a time. It took a GS to cull things at the triangle level.
No longer.
ARB, if you’re going to kill off GS’s, just do it already. Give us AMD_vertex_shader_layer/viewport_index (obviously with the ability to set them from the TES too). That would completely nullify any point to that worthless, poorly-named, Microsoftian addition to the rendering pipeline. Or if we can’t have that, at least give us NV_geometry_shader_passthrough, so that GS’s can be focused on the one useful thing they can still do.
Where’s The Beef Award:
OpenGL 4.5
Did ARB_DSA really deserve having a full point-release for it? Because the features exposed in 4.5 are pretty scant. That’s not to say that nothing of substance was released. I’m sure that people will find uses for primitive culling and ES 3.1 compatibility is important (particularly since it had more features than GL 4.4, and we can’t have that). But very little of substance was actually standardized. Especially considering that there is much functionality that is available, across hardware vendors, which is worth standardizing.
Like sparse_textures/buffers. And so forth.
I understand that you kinda want GL 4.x to be implementable on all D3D 11-class hardware. But why exactly is that so important? Especially now.
4.5’s features compared to 4.4 were minor, bordering on non-existent. Plus, 4.4 was quite complete in terms of D3D 11.2-level features; there wasn’t much we were missing. So why not simply let the “backwards compatibility extensions” (the ones without ARB suffixes) allow hardware that couldn’t do sparse stuff to implement what they could, and give us a 4.5 with some real meat?
We Need More Ways To Do Things Award:
Let’s Rewrite Our API And Still Leave The Original Award:
ARB_direct_state_access
Because that’s what OpenGL needs more of: ways to do something we can already do.
But at least it shows that the ARB understands timing. They know that the best time to introduce a feature that renders a healthy portion of the existing API superfluous… is right before you replace it all with an entirely new API.
That’s the kind of timing that has placed the OpenGL API in the marketplace position it currently enjoys