Official feedback on OpenGL 4.2 thread

The Khronos™ Group today announced the immediate release of the OpenGL® 4.2 specification, bringing the very latest graphics functionality to the most advanced and widely adopted cross-platform 2D and 3D graphics API (application programming interface). OpenGL 4.2 integrates developer feedback and continues the rapid evolution of this royalty-free specification while maintaining full backwards compatibility - enabling applications to incrementally use new features, while portably accessing state-of-the-art graphics processing unit (GPU) functionality across diverse operating systems and platforms.

The OpenGL 4.2 specification has been defined by the OpenGL ARB (Architecture Review Board) working group at Khronos, and includes the GLSL 4.20 update to the OpenGL Shading Language. The OpenGL 4.2 specification contains new features that extend functionality available to developers and enables increased application performance. The full specification is available for immediate download at http://www.opengl.org/registry.

New functionality in the OpenGL 4.2 specification includes:

  • [li]ARB_shader_atomic_counters[LIST][]GLSL built-in functions to query and increment/decrement atomic counters[]Counters stored in buffer objects[/ul][]ARB_shader_image_load_store[ul][]allow shaders to load from, store to, and perform atomic read-modify-write operations to a single level of a texture[/ul][]ARB_texture_storage[ul][]Immutable textures[/ul][]ARB_transform_feedback_instanced[ul][]Draw multiple instances of the result of a transform feedback[]Without query and sync needed for DrawArraysInstanced()[/ul][]ARB_shading_language_420pack[ul][]Collection of new GLSL features[/ul][]ARB_texture_compression_BPTC[ul][]ARB extension since January 2010, promoted to core now[]Same formats as BC6H/BC7 in DirectX 11[/ul][]ARB_base_instance[ul][]Specify offset within buffer object for instanced drawing[/ul][]ARB_internalformat_query[ul][]Find out supported number of samples per internal format[/ul][]ARB_compressed_texture_pixel_storage[ul][]Modify an arbitrary subset of a compressed texture[/ul][]ARB_shading_language_packing[ul][]allows GLSL shaders to read and write 16-bit floating-point encodings[]Pack small data types into one larger one[/ul][]ARB_map_buffer_alignment[ul][]Pointer returned is aligned for SSE/AVX CPU instructions[/ul][]ARB_conservative_depth[ul][*]Shader constructs that help enable depth testing before fragment processing

Lastly, Khronos has simultaneously released a set of ARB extensions to enable as much OpenGL 4.2 core functionality as possible on previous generation GPU hardware; providing maximum flexibility and platform coverage for application developers.

Learn more about what is new in OpenGL 4.2 at the BOF at Siggraph, Wed, Aug 10th from 4- 6PM in the Pan Pacific Hotel, Crystal Ballroom B&C. http://www.khronos.org/news/events/siggraph-vancouver-2011

Joy!

And reviewed

there should be a gl_arb_ray_tracing in the traditional path :stuck_out_tongue:

I have a quick question about the swizzle operators (Section 5.5 in the GLSL spec):

The individual components can be selected by following the variable name with period ( . ) and then the component name.

I always assumed that the swizzle operators can be used with any vector expression, not just variables (e.g. function results etc).

If this is the case, can the swizzle operators now be used on constants too, e.g. (1.0).xxx or 1.0.xxx ?

In review:

ARB_base_instance

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 :wink:

ARB_transform_feedback_instanced

Just a fix for lacking needed functionality.

ARB_compressed_texture_pixel_storage

I’m sure this is useful to someone. Just not me.

ARB_conservative_depth

I’m actually surprised that this one made it into the spec. It seems really low-level, but it has its place.

ARB_internalformat_query

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.

ARB_map_buffer_alignment

Simple. Direct. To-the-point. Does an important job.

Good.

ARB_shader_atomic_counters

Didn’t see this coming. After a cursory glance, the API seems reasonably well-specified and the functionality decent overall.

ARB_shader_image_load_store

Something so obvious that even I predicted it.

ARB_shading_language_packing

Meh. The functionality is fine and all, but it’s not exactly blowing my skirt up.

ARB_texture_storage

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.

ARB_shading_language_420pack

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:

  • [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

As they say in the StarCraft community: “It’s about time.”

ARB_faster_vertex_submission

No, that’s not a real extension. It’s just a place to register my disappointment that nothing has been done on this front.

ARB_separate_shader_objects

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?

Overall

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?

Actually, I’m bumping that score up to A-. The quick reference card is very nice this time around. It even has a pipeline reference.

Though I’m not sure if you can call it a “quick” reference if it has to have an index :wink:

Idea for the ARB:

Many people would like a copy of the OpenGL specification in book form. Granted, I don’t expect it to be a big seller, but there are some people who would certainly pay money for it. Just not enough to publish it.

At least, not through a traditional publisher. But a less traditional publisher like Lulu Press would actually be a pretty decent idea. The PDF would always be available for free, and it doesn’t cost much of anything to just make a “book” available through them. You could sell it for something like $20.00 or so.

Everyone wins. The ARB gets a little extra pocket money. The users get to have the spec in book form reasonably inexpensively.

Hi Alfonse,

i guess you did’t see this paragraph of ARB_texture_storage:

Dependencies on EXT_direct_state_access

If EXT_direct_state_access is not present, references to TextureStorage* should be ignored.

So the old-style TexStorage* functions are needed when you have no DSA extension.

More OpenGL goodness. Very nice!

No direct state access?
What does Khronos has against that?
Just add DSA counterparts of the non DSA stuff.

And seriously why do they even continue to make this a minor version bump? The changes seem to better reflect a OpenGL 4.1.1 instead of OpenGL 4.2.

This really hints at using the minor version number for big hardware generation changes and a third number after that for this kind of stuff. And you could use the major version number to change the api and the context creation calls while avoid breaking old software.

And something about the following:

ARB_shading_language_420pack

I’m assuming the 420 stands for the shading language version 4.2.0 please use separators.

Such as underscore (using underscores is the most consistent way I think) e.g.: ARB_shading_language_4_2_0_pack

This way you won’t have a problem when one of the numbers reaches 10 or higher. Which has been a big problem for at least one project a while back. (Don’t remember what it exactly was. Just that they had problems with versions above 9.)

This really hints at using the minor version number for big hardware generation changes and a third number after that for this kind of stuff. And you could use the major version number to change the api and the context creation calls while avoid breaking old software.

Well, the ARB has been consistent about using the major version for hardware generations since OpenGL 3.0. And they have been consistent about not doing API changes since OpenGL 1.0. So really, there’s no point to doing it this way.

This way you won’t have a problem when one of the numbers reaches 10 or higher.

It’s just a string. There’s no problem because it’s only an identifier. Oh, and it’s not 4.2.0; it’s 4.20. GLSL versions use 2 digits for the minor version. For some reason.

“glDrawElementsInstancedBaseVertexBaseInstance” - Just Wow.

Nice to see that OpenGL is still updated regularly and more and more details are fleshed out to make ones lives easier. But that’s basically it - details. I don’t see anything that interests me enough to actually read the specification in more detail. I assume that’s a good thing, though.

However, I’m disappointed that DSA is still not there yet. It’s IMO the most important “feature” for future OpenGL, because writing a good / modern rendering engine with OpenGLs current bind/modify method is just inefficient, awkward and error-prone.

I hope it’s in the pipeline and we’ll see it soon.

Jan.

I wish we could get a “clean” version of the spec - one with all deprecated functionality removed.

Philipp

Deprecation has been deprecated.

We now have Core and Compatibility profiles. The core spec is here: http://www.opengl.org/registry/doc/glspec42.core.20110808.pdf

I also like the new Spec very much, despite the very obvious missing parts with direct state access and shader includes…

Great Work!
-chris

Ok, I didn’t notice how few deprecated features there are in the spec (I found only line width and some queries).

Philipp

P.S.: Why is COMPRESSED_TEXTURE_FORMATS not included in the list of deprecated features in E2.1, but mentioned as deprecated in L4.2?

so Nvidia has an implmentation NOW. AMD will have one soon. Now let’s guess on how long it will take Apple to work with both of them to incorporate changes onto their systems.

Correction: AMD also have an implementation NOW :slight_smile: .

thats nice to know. Not good though if you are wanting to try out things on the mac. I wonder if OpenGL ES 2.0 has more functionality(shader) on the iOS side than the desktop drivers.

I wonder if OpenGL ES 2.0 has more functionality(shader) on the iOS side than the desktop drivers.

No, it doesn’t. Even the Mac’s 2.1 implementation has access to EXT_gemoetry_shader4.