Official feedback on OpenGL 4.2 thread

[Don't Disturb]

ARB_shader_image_load_store is a really big deal! Shaders can scatter as well as gather which is going to enable some interesting techniques.
I'm just wondering how it will perform - has anyone given it a try yet?

[Ilian Dinev]

ARB_shader_image_load_store ...
- has anyone given it a try yet?

OIT stuff,
and http://www.opengl.org/discussion_boa...393#Post296393

[aqnuep]

Wow, I'm just back from holiday and here we have GL 4.2.

Very nice update with a lot of useful features, even though only about half of the features I wanted to see in GL 4.2 were actually added.

[Rob Barris]

Very nice update with a lot of useful features, even though only about half of the features I wanted to see in GL 4.2 were actually added.

By repeating this process over time, the feature set will asymptotically approach your needs!

[aqnuep]

I know that. Obviously they had some real tough extensions to discuss this time (I mean here especially the ARB_shader_image_load_store and ARB_shader_atomic_counters, even though the later was already almost complete a half year ago).

Anyway, what maybe we can say at least now with confidence is that GL 4.2 achieved feature parity with DX11 (at least from point of view of exposed hardware capabilities).

[Alfonse Reinheart]

Obviously they had some real tough extensions to discuss this time (I mean here especially the ARB_shader_image_load_store and ARB_shader_atomic_counters, even though the later was already almost complete a half year ago).

Actually, I'd guess that most of the discussion was around ARB_shading_language_420pack and ARB_texture_storage. The former is really a merger of what seems like a half-dozen extensions, which much have been in development.

And ARB_texture_storage introduces functionality that I'm sure some in the ARB saw as superfluous. After all, there's nothing you can do with ARB_texture_storage that you can't with regular texture creation. And the immutability must have rubbed some of the more conservative elements the wrong way.

Anyway, what maybe we can say at least now with confidence is that GL 4.2 achieved feature parity with DX11 (at least from point of view of exposed hardware capabilities).

Honestly, it's not "feature parity" that interests me so much as "niceness parity". And 420pack really, really helps. Shaders are much more robust and stand-alone. And the last of the horrible 3D Labs-based nonsense is finally expunged from GLSL. It only took 10 revisions of the language and 6 years.

Also, I've come to appreciate why it's one extension instead of a half-dozen. If it were many extensions, then those using GL 3.3 would have to have a giant list of #extension enable lines at the top of every shader. That would be pretty terrible. This way, you just have one extension (or two if you're using pack) and that's it.

[aqnuep]

Actually, I'd guess that most of the discussion was around ARB_shading_language_420pack and ARB_texture_storage. The former is really a merger of what seems like a half-dozen extensions, which much have been in development.

I agree that ARB_shading_language_420pack is very important as I was also very frustrated by the way how you attach bindings to uniforms as an example. However, atomic counters were even more important, I think, as without it we simply cannot implement OIT and other stuff efficiently. And before anybody tries to argue, atomic read/writes exposed by EXT_shader_image_load_store and now also by the ARB version is not equivalent with atomic counters. Atomic counters are more than 10 times faster than atomic read/writes on AMD hardware as they have special hardware for it, and it is also faster on NVIDIA as well.

Honestly, it's not "feature parity" that interests me so much as "niceness parity". And 420pack really, really helps. Shaders are much more robust and stand-alone. And the last of the horrible 3D Labs-based nonsense is finally expunged from GLSL. It only took 10 revisions of the language and 6 years.

Yeah, that's also important, however I'm more interested first in being able to solve a problem than how nicely I can solve it (no, I'm not saying that solving a problem elegantly is less important, however, functioning software has priority over that).

Also, I've come to appreciate why it's one extension instead of a half-dozen. If it were many extensions, then those using GL 3.3 would have to have a giant list of #extension enable lines at the top of every shader. That would be pretty terrible. This way, you just have one extension (or two if you're using pack) and that's it.

Good point as well, even though the name is kind of funky, it's better to have just a single extension.

Update: Actually I'm also very happy to see ARB_base_instance as this was a functionality that was present in hardware for quite some time but even ARB_draw_indirect didn't expose the functionality earlier. This is one of my favorites, even though the name glDrawElementsInstancedBaseVertexBaseInstance sounds a bit ridiculous Btw, I don't know why they didn't simply created two new functions with names like: glDrawElementsDirect and glDrawArraysDirect (analogous to the new indirect draw commands) which does the same like glDrawElementsInstancedBaseVertexBaseInstance and glDrawArraysInstancedBaseInstance. You can do all the glDraw* commands with these two by using proper parameters so people could migrate to the new commands and we could mark all the rest of glDraw* commands as deprecated. Also, it would be great to see glMultiDraw* versions as well (what we have at least for indirect drawing thanks to AMD_multi_draw_indirect).

[malexander]

Thanks for promoting ARB_shader_load_store and the atomic counters, while adding useful features for older hardware. Expanding the shader bindings is great, though I'm still not a big fan of the layout syntax.

However, the one ARB extension I do take issue with is ARB_internalformat_query - not for what it does, but for how it's named. In all instances of "query" in the registry, the use of query as a noun indicates a query object (ARB_occlusion_query, ARB_timer_query), whereas its use as a verb indicates a synchronous, object-less fetch of the information (ARB_texture_query_lod, OES_query_matrix). So at least it should be ARB_query_internalformat.

Further to this, the extension doesn't actually query the internal format of a texture, which I was really hoping for when I saw it. Rather, it queries the supported multisample counts for a given internal format. In my opinion, the extension should have been called ARB_query_multisample. Sorry if this comes across as a bit pedantic, and I realize it's likely too late to do much about, but it felt misleading enough to me to point out in the feedback thread.

[Alfonse Reinheart]

If you check the issues for that extension, it was going to be much more ambitious, but they scaled it back for the current release.

The name makes sense because it's providing a query mechanism for internal format information. It just doesn't do much with that mechanism yet.

[malexander]

I saw that, but that still implies a future extension with a different name. Perhaps ARB_internalformat_query2, 3, etc. are coming, but the name still doesn't do much for the current extension.