Official feedback on OpenGL 4.6 thread

OpenGL
1

The KhronosGroup announces from the SIGGRAPH 2017 Conference the immediate public availability of the OpenGL 4.6 specification. OpenGL 4.6 integrates the functionality of numerous ARB and EXT extensions created by Khronos members AMD, Intel, and NVIDIA into core, including the capability to ingest SPIR-V™ shaders.
SPIR-V is a Khronos-defined standard intermediate language for parallel compute and graphics, which enables content creators to simplify their shader authoring and management pipelines while providing significant source shading language flexibility. OpenGL 4.6 adds support for ingesting SPIR-V shaders to the core specification, guaranteeing that SPIR-V shaders will be widely supported by OpenGL implementations.
OpenGL 4.6 adds the functionality of these ARB extensions to OpenGL’s core specification:

[ul]
[li]GL_ARB_gl_spirv and GL_ARB_spirv_extensions to standardize SPIR-V support for OpenGL[/li][li]GL_ARB_indirect_parameters and GL_ARB_shader_draw_parameters for reducing the CPU overhead associated with rendering batches of geometry[/li][li]GL_ARB_pipeline_statistics_query and GL_ARB_transform_feedback_overflow_query standardize OpenGL support for features available in Direct3D[/li][li]GL_ARB_texture_filter_anisotropic (based on GL_EXT_texture_filter_anisotropic) brings previously IP encumbered functionality into OpenGL to improve the visual quality of textured scenes[/li][li]GL_ARB_polygon_offset_clamp (based on GL_EXT_polygon_offset_clamp) suppresses a common visual artifact known as a “light leak” associated with rendering shadows[/li][li]GL_ARB_shader_atomic_counter_ops and GL_ARB_shader_group_vote add shader intrinsics supported by all desktop vendors to improve functionality and performance[/li][li]GL_KHR_no_error reduces driver overhead by allowing the application to indicate that it expects error-free operation so errors need not be generated[/li][/ul]
In addition to the above features being added to OpenGL 4.6, the following are being released as extensions:

[ul]
[li]GL_KHR_parallel_shader_compile allows applications to launch multiple shader compile threads to improve shader compile throughput[/li][li]WGL_ARB_create_context_no_error and GXL_ARB_create_context_no_error allow no error contexts to be created with WGL or GLX that support the GL_KHR_no_error extension[/li][/ul]
The OpenGL 4.6 specification can be found at Khronos OpenGL® Registry - The Khronos Group Inc. The GLSL to SPIR-V compiler glslang has been updated with GLSL 4.60 support, and can be found at GitHub - KhronosGroup/glslang: Khronos-reference front end for GLSL/ESSL, partial front end for HLSL, and a SPIR-V generator..
Sophisticated graphics applications will also benefit from a set of newly released extensions for both OpenGL and OpenGL ES to enable interoperability with Vulkan and Direct3D. These extensions are named:

[ul]
[li]GL_EXT_memory_object[/li][li]GL_EXT_memory_object_fd[/li][li]GL_EXT_memory_object_win32[/li][li]GL_EXT_semaphore[/li][li]GL_EXT_semaphore_fd[/li][li]GL_EXT_semaphore_win32[/li][li]GL_EXT_win32_keyed_mutex[/li][/ul]
They can be found at: Khronos OpenGL® Registry - The Khronos Group Inc

Khronos invites and welcomes your feedback on this release. Tell us what you think.

2

[QUOTE=Khronos_webmaster;1288035]
[ul]
[li]GL_KHR_parallel_shader_compile allows applications to launch multiple shader compile threads to improve shader compile throughput[/QUOTE][/li][/ul]

Actually, this allows applications to limit the number of threads used for parallel compiles. Previously, drivers were free to use as many threads as they like.

3

Reading the announcement at https://www.khronos.org/news/press/khronos-releases-opengl-4.6-with-spir-v-support I noticed a discrepancy.
Disappointed they did not mention the relevant patents by their numbers, dates and names.

And the announcement has a peculiarity in it:

GL_ARB_texture_filter_anisotropic (based on GL_EXT_texture_filter_anisotropic) brings previously IP encumbered functionality into OpenGL to improve the visual quality of textured scenes
GL_ARB_polygon_offset_clamp (based on GL_EXT_polygon_offset_clamp) suppresses a common visual artifact known as a “light leak” associated with rendering shadows

Mentions polygon offset clamp without IP.
While a little further in the article:

This includes resolving previous intellectual property roadblocks to bringing anisotropic texture filtering and polygon offset clamping into the core specification

Oddly inconsistent description. I know you can look this stuff up but this should be clearly described in the announcement itself.
Is either the polygon offset clamp missing this IP mention in the new core extension list or is the later paragraph mistaken?
If it is missing the IP mention then why does anisotropic filtering have an IP mention in the list?
This is not consistent writing.
It is not made unambiguously clear whether polygon offset clamp had to do with IP roadblocks or not.
Adding this, mentioning the IP roadblock for polygon offset clamp in the list of new core extensions too would make this unambiguous.

4

With DSA(GL_ARB_direct_state_access) introduced in core OpenGL 4.5, the previous OpenGL release. And replaces some stuff, makes that stuff obsolete.
Does it mean this release (4.6) of OpenGL core deprecates that obsolete functionality?
And will the obsolete functions and other stuff be removed from core in OpenGL 4.7/5.0 to leave only Direct State Access style stuff?

5

[QUOTE=Khronos_webmaster;1288035]
[ul]
[li]GL_KHR_no_error reduces driver overhead by allowing the application to indicate that it expects error-free operation so errors need not be generated[/li][/ul][/QUOTE]
Until the application isn’t, this extension is basically has a no error reporting functionality, not a no error functionality.
In other words this extension removes error reporting from interfering with performance.
Should have called it GL_KHR_no_error_reporting

6

Yes :D:D:D:D:D:D

7

The mesamatrix.net resource is updated for OpenGL 4.6

1109×336 42.2 KB

Image: https://i.imgur.com/i2Z8S8t.png

8

[QUOTE=Gedolo2;1288045]With DSA(GL_ARB_direct_state_access) introduced in core OpenGL 4.5, the previous OpenGL release. And replaces some stuff, makes that stuff obsolete.
Does it mean this release (4.6) of OpenGL core deprecates that obsolete functionality?
And will the obsolete functions and other stuff be removed from core in OpenGL 4.7/5.0 to leave only Direct State Access style stuff?[/QUOTE]

Can you be a bit more explicit ? What stuff is becoming obsolete please ?
From my limited knowledge of newer OpenGL, this is very unclear when reading this.

9

Aside from the lack of reporting, it removes the requirement that commands which generate errors (other than GL_OUT_OF_MEMORY) have well-defined side-effects; i.e. commands which generate errors are silently ignored unless the specification explicitly states otherwise.

With a no-error context, any error may terminate the application or leave the context in an undefined state.

10

[QUOTE=GClements;1288059]Aside from the lack of reporting, it removes the requirement that commands which generate errors (other than GL_OUT_OF_MEMORY) have well-defined side-effects; i.e. commands which generate errors are silently ignored unless the specification explicitly states otherwise.

With a no-error context, any error may terminate the application or leave the context in an undefined state.[/QUOTE]

Thanks for clarifying. That still does not reflect the name very well.
Better names would be no error handling, no error expectation, discard error, silent error or other.

11

[QUOTE=Silence;1288053]Can you be a bit more explicit ? What stuff is becoming obsolete please ?
From my limited knowledge of newer OpenGL, this is very unclear when reading this.[/QUOTE]
Direct State Access apparently replaces some older functions and other stuff.
Can’t remember all the details on the top of my head though.

12

The Fourth Not-Annual Unofficial OpenGL Feature Awards!

We Finally Did What We Said We Were Gonna Award

Open-sourcing the CTS.

Having a CTS is good. Having one that people who find bugs in “conforming” implementations can submit tests for is much better. It remains to be seen what exactly will have to be done to get patches into the CTS or how CTS versioning works. Will implementers have to state exactly which version of the CTS they are conformant to?

But at least now when we encounter driver bugs, we have the opportunity to write something that will ensure that such drivers are not considered “conformant” until they fix them.

One Little Mistake Award

GL_ARB_shader_draw_parameters

This was a fine idea… in 2013, when the extension was released. But since then, things have changed. Among them, Vulkan was released.

Vulkan’s VertexIndex and InstanceIndex input values are the values that users actually want. By all rights, we should have just hooked into those semantics, using KHR_vulkan_glsl’s definition of gl_VertexIndex and gl_InstanceIndex. And the SPIR-V equivalent would allow us to use VertexIndex and InstanceIndex.

I’m not saying we don’t need gl_BaseVertex and gl_BaseInstance. But having to do math to compute what we want most often isn’t the best idea in the world. The vast majority of uses of this will be gl_InstanceID + gl_BaseInstance.

Yes, this is good functionality; it’s just specified incorrectly for a modern world.

3D Labs Is Buried In A Shallow Grave Award

GL_ARB_gl_spirv

Never has their been a greater repudiation of “the thing that 3D Labs built” than us developing an entire language to avoid using their stuff. We can now write OpenGL programs that are completely free of the vestiges of 3D Labs.

While I respect that they actually stepped forward with ideas at a critical time in OpenGL’s history, 3D Labs made so many bad decisions with GLSL. From oddball and inconsistent parts of its language, to having us specify interface aspects from OpenGL rather than in the shader where they belong. These design missteps hampered OpenGL development and usage for a long time.

But OpenGL 4.6 is now, finally, free of those mistakes. Granted, OpenGL has already suffered the bulk of the pain from those mistakes. But at least we’re free now.

Recursion Award

GL_ARB_spirv_extensions

It’s not every day that you see an extension that gets constantly extended. But that’s apparently the idea with this guy. Every time they come up with new SPIR-V extensions to support OpenGL extension functionality, they’ll extend this list.

Fortunately it’s done by strings and not OpenGL enumerators, so you don’t have to constantly update your OpenGL loader. Even so, the logistics of having to update an extension (especially one that’s actually part of OpenGL itself) every time a new SPIR-V extension comes out must be somewhat odd.

Last Kid Picked For Baseball Award
Let’s Not Make Geometry Shaders Completely Useless Award

GL_ARB_shader_viewport_layer_array

Is there some particular reason why that’s not core OpenGL yet? The component ARB extensions are widely implemented in GL 4.x land. That extension is something that ought to have been core in GL 4.5; not being core in 4.6 just doesn’t make sense at this point.

Do we really want to keep GS’s around this badly that we’re not implementing their replacement?

Hardware Fragmentation Really Hurts Us Award

OpenGL 4.6

Core SPIR-V support is nice and all. And yeah, we’ve needed a couple of those extensions for a while. But there’s even less substance in 4.6 than in 4.5. This despite the fact that there are real hardware features that could have been standardized.

Why aren’t they core? Because most of the tasty features aren’t supported by all of the big-3 hardware developers. Sparse Textures? Intel doesn’t support it. Bindless textures? Most Intel hardware doesn’t support it. Fragment shader interlock? AMD doesn’t support it. And so on.

It feels more like OpenGL can’t effectively move forward until all the hardware vendors agree on a common feature set that’s better than what we’ve got. And without Microsoft pushing them to adopt a particular feature set, they’re just off doing whatever.

13

I for one support promoting the ARB_shader_viewport_layer_array extension to core.
And you’re also putting ARB_shader_viewport_layer_array forward as an ARB replacement for NV_geometry_shader_passthrough, right?
Is it really a complete replacement, can it do everything the NV extension can?
What things can it do more or better than the NV extension can?
And if applicable which things of the ARB extension, not in the NV extension, are important according to you?

14

What about bringing correctly specified functionality for a modern world into OpenGL with an extension?
An extension to be used in conjunction with or maybe without or even replacing some other OpenGL extensions. (These could be GL_ARB_shader_draw_parameters, GL_ARB_multi_draw_indirect, GL_ARB_base_instance, GL_ARB_draw_indirect, GL_ARB_draw_elements_base_vertex, GL_ARB_draw_instanced and others)
Bringing Vulkan’s better instancing and indirect drawing into OpenGL.
Some sort of better OpenGL instancing and multiDrawIndirect extension.
Maybe call it GL_ARB_shader_draw_index_parameters, GL_ARB_shader_draw_elements_index or something else.
Might be great for working with SPIR-V.
Might get a bit messy because some extension equivalents and mappings are a superset of their OpenGL equivalent extension. Such as VK_KHR_shader_draw_parameters being a superset.
Anyway those arrayed drawing commands, if applicable, can be put in the proposed new draw extension. Allowing OpenGL to use them too if useful.

Interactions and External Dependencies

    Requires the SPV_KHR_shader_draw_parameters SPIR-V extension.

    Requires GL_ARB_shader_draw_parameters for GLSL source languages.
  1. Is this the same functionality as GL_ARB_shader_draw_parameters?

RESOLVED: It’s actually a superset as it also adds in support for arrayed drawing commands.

They should have left the support for arrayed drawing commands out of it.
A clean mapping would have been better.
If you add an mapping, conversion extension for something. Do not extend it, do not make it a superset!

15

[QUOTE=Alfonse Reinheart;1288124]

One Little Mistake Award

GL_ARB_shader_draw_parameters

This was a fine idea… in 2013, when the extension was released. But since then, things have changed. Among them, Vulkan was released.

Vulkan’s VertexIndex and InstanceIndex input values are the values that users actually want. By all rights, we should have just hooked into those semantics, using KHR_vulkan_glsl’s definition of gl_VertexIndex and gl_InstanceIndex. And the SPIR-V equivalent would allow us to use VertexIndex and InstanceIndex.

I’m not saying we don’t need gl_BaseVertex and gl_BaseInstance. But having to do math to compute what we want most often isn’t the best idea in the world. The vast majority of uses of this will be gl_InstanceID + gl_BaseInstance.

Yes, this is good functionality; it’s just specified incorrectly for a modern world.[/QUOTE]
Couldn’t shader compilers optimize this automatically when compiling to SPIR-V by swapping out variables and doing some code transformations?