Part of the Khronos Group
OpenGL.org

The Industry's Foundation for High Performance Graphics

from games to virtual reality, mobile phones to supercomputers

Page 2 of 2 FirstFirst 12
Results 11 to 15 of 15

Thread: Official feedback on OpenGL 4.6 thread

  1. #11
    Intern Contributor
    Join Date
    Nov 2013
    Posts
    50
    Quote Originally Posted by Silence View Post
    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.
    Direct State Access apparently replaces some older functions and other stuff.
    Can't remember all the details on the top of my head though.

  2. #12
    Senior Member OpenGL Lord
    Join Date
    May 2009
    Posts
    5,906
    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.

  3. #13
    Intern Contributor
    Join Date
    Nov 2013
    Posts
    50
    Quote Originally Posted by Alfonse Reinheart View Post

    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?
    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?
    Last edited by Gedolo2; 09-17-2017 at 03:28 PM. Reason: fixed spelling

  4. #14
    Intern Contributor
    Join Date
    Nov 2013
    Posts
    50

    Lightbulb

    Quote Originally Posted by Alfonse Reinheart View Post
    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.
    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!
    Last edited by Gedolo2; 09-17-2017 at 03:23 PM.

  5. #15
    Intern Contributor
    Join Date
    Nov 2013
    Posts
    50
    Quote Originally Posted by Alfonse Reinheart View Post

    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.
    Couldn't shader compilers optimize this automatically when compiling to SPIR-V by swapping out variables and doing some code transformations?

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •