Not the sexiest of extensions. And “DrawElementsInstancedBaseVertexBaseInstance”… really? There was no better alternative than that name?
Man, that one giant glDraw function from Longs Peak with 20 parameters is starting to sound better and better
Just a fix for lacking needed functionality.
I’m sure this is useful to someone. Just not me.
I’m actually surprised that this one made it into the spec. It seems really low-level, but it has its place.
I can’t say I saw this coming. Though I have to say, it seems oddly named. It’s more about multisample than internal formats. Though I suppose it could be extended later for other things, like asking if something is color-renderable.
Though that begs the question as to why that wasn’t added into this extension.
Simple. Direct. To-the-point. Does an important job.
Didn’t see this coming. After a cursory glance, the API seems reasonably well-specified and the functionality decent overall.
Something so obvious that even I predicted it.
Meh. The functionality is fine and all, but it’s not exactly blowing my skirt up.
Now we enter the realm of the bizarre.
Immutable textures have been something the ARB has wanted for years. Yet it’s taken them this long to get it.
The behavior is very good, but I take some issue with how it’s specified. It an API inconsistency.
It’s obvious at this point that the ARB does not want to just add direct state access. They only provide DSA-style functions when they add new functionality, as they did here.
The problems are these. First, they provided old-style storage functions too. Why? I didn’t see a big rush to provide old-style Sampler Object support. Yes, that’s a new object type, rather than a modification of an older one. But it still feels inconsistent with the push towards DSA-style functions.
More importantly is this. If you create a texture object with this extension, you are almost guaranteed to later make a SubImage call. It’s the only way to upload data; that’s part of the purpose of this extension, right?
So… where is glTextureSubImage? You know, the DSA-style function that takes a texture object, not a type. If you call glTextureStorage2D, you have almost certainly not bound that texture to the context. So, you don’t have to bind the texture to create the storage, but you have to bind the texture to upload to it? Doesn’t that kinda defeat the purpose? Yes, I know you can use EXT_DSA, but if you don’t want to (or the unlikely event that it’s unavailable), what then?
It just seems inconsistent that they would add a function that strongly suggests using another function, but then not make that function available. And it’s not like the ARB didn’t use ARB_separate_shader_objects to add in the DSA version of program uniform setting. So this wouldn’t be the first time the ARB added convenience functions to the language.
I do like the fact that you can specify compressed images without using different functions for them.
AKA: ARB_glsl_doesnt_suck. Or ARB_glsl_is_cool_now.
I’ve never been a fan of these sorts of “bag of stuff” extensions, where they just bundle a bunch of functionality together. This is mostly due to fears about what hardware they will be implemented on. For something like ARB_gpu_shader5, it’s obvious what hardware it’ll show up on. But for something like this, which is mostly hardware agnostic, it seems weird. Indeed, according to the revision history, this is a Frankenextension, formed from the bones of many extensions and animated with lightning.
Fortunately, the extension’s functionality seems to fit on GL 3.3-class hardware (though I wouldn’t mind seeing a GL 3.4 that bundles this into core). A quick rundown of the bag of tricks:
[ul][li]Line continuation: Meh. Useful for #defines, but it doesn’t exactly blow my skirt up.UTF-8 encoding: Sure why not.Implicit return value conversion: More banishing of stupid 3D Labs ideas. What hatred did those people have for implicit conversions anyway?Local ‘const’ variables with non-compile-time ‘const’ expressions: What took you so long?Qualifier ordering: Again, what took so long? GLSL has been accruing qualifiers like some kind of plague, but it’s taken 9 revisions of the language to fix this?Uniform block
binding location: Of course!Sampler unit
binding location: See my comment on qualifier ordering.Initializer list: Somebody’s read the C++11 specification. Good for you.Vector-type
.length: Meh. If GLSL had templates or something, this might be useful, but I’m not sure I understand the purpose. Maybe for #define gimmickry.Scalar swizzles: Again, what kept you?Texel offset constants: Good[/ul][/li]
As they say in the StarCraft community: “It’s about time.”
No, that’s not a real extension. It’s just a place to register my disappointment that nothing has been done on this front.
I honestly can’t believe the ARB didn’t fix ARB_separate_shader_objects. It’s not like there weren’t four bugs filed on this extension.
Yes, the last two are more “wish-list” than bugs (though I would say that they’re more “this functionality is inconsistent with itself and poorly specified”, which should count as a bug). And the ARB did fix the state tables in the 4.2 spec. But there is no excuse for GL_PROGRAM_SEPARABLE still not being listed in the program object state table.
Why bother advertising the Bugzilla database if they’re just going to ignore it? The ARB has plenty of ways to ignore commentary; did they really need another?
A solid block of functionality (though little hardware-based). Some really good things, some really odd things, but overall, it was good. But I’ve only had a cursory glance at the extensions. And ARB_separate_shader_objects has shown that the devil is in the details.
So consider this a provisional grade of B+. Points were deducted for expecting me to type “DrawElementsInstancedBaseVertexBaseInstance”, failure to address the vertex transfer issue, failure to bother to take an hour to read your bug list, and for not providing DSA-style texture uploading.
Oh, and when are we getting deferred contexts?