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 12 of 12

Thread: Official feedback on OpenGL 4.6 thread

  1. #11
    Intern Newbie
    Join Date
    Nov 2013
    Posts
    47
    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,871
    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.

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
  •