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 1 of 2 12 LastLast
Results 1 to 10 of 15

Thread: Official feedback on OpenGL 4.6 thread

  1. #1
    Administrator Regular Contributor Khronos_webmaster's Avatar
    Join Date
    Apr 2007
    Location
    Montreal
    Posts
    175

    Official feedback on OpenGL 4.6 thread

    The Khronos Group 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:

    • GL_ARB_gl_spirv and GL_ARB_spirv_extensions to standardize SPIR-V support for OpenGL
    • GL_ARB_indirect_parameters and GL_ARB_shader_draw_parameters for reducing the CPU overhead associated with rendering batches of geometry
    • GL_ARB_pipeline_statistics_query and GL_ARB_transform_feedback_overflow_query standardize OpenGL support for features available in Direct3D
    • 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
    • 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
    • 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

    In addition to the above features being added to OpenGL 4.6, the following are being released as extensions:

    • GL_KHR_parallel_shader_compile allows applications to launch multiple shader compile threads to improve shader compile throughput
    • 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

    The OpenGL 4.6 specification can be found at https://khronos.org/registry/OpenGL/index_gl.php. The GLSL to SPIR-V compiler glslang has been updated with GLSL 4.60 support, and can be found at https://github.com/KhronosGroup/glslang.
    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:

    • GL_EXT_memory_object
    • GL_EXT_memory_object_fd
    • GL_EXT_memory_object_win32
    • GL_EXT_semaphore
    • GL_EXT_semaphore_fd
    • GL_EXT_semaphore_win32
    • GL_EXT_win32_keyed_mutex

    They can be found at: https://khronos.org/registry/OpenGL/index_gl.php

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

  2. #2
    Advanced Member Frequent Contributor arekkusu's Avatar
    Join Date
    Nov 2003
    Posts
    870
    Quote Originally Posted by Khronos_webmaster View Post
    • GL_KHR_parallel_shader_compile allows applications to launch multiple shader compile threads to improve shader compile throughput


    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. #3
    Intern Contributor
    Join Date
    Nov 2013
    Posts
    50
    Reading the announcement at https://www.khronos.org/news/press/k...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.
    Last edited by Gedolo2; 07-31-2017 at 02:41 PM. Reason: clarified reasoning behind question

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

    Question Question about pre non DSA deprecation

    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?
    Last edited by Gedolo2; 07-31-2017 at 02:38 PM.

  5. #5
    Intern Contributor
    Join Date
    Nov 2013
    Posts
    50
    Quote Originally Posted by Khronos_webmaster View Post
    • 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
    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. #6
    Intern Contributor
    Join Date
    Nov 2013
    Posts
    50

    Smile

    Quote Originally Posted by Khronos_webmaster View Post
    • GL_ARB_indirect_parameters and GL_ARB_shader_draw_parameters for reducing the CPU overhead associated with rendering batches of geometry
    Yes

  7. #7
    Intern Contributor
    Join Date
    Nov 2013
    Posts
    50

    Post Mesamatrix.net is updated for OpenGL 4.6

    The mesamatrix.net resource is updated for OpenGL 4.6

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

  8. #8
    Member Regular Contributor
    Join Date
    Jul 2012
    Posts
    417
    Quote Originally Posted by Gedolo2 View Post
    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?
    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. #9
    Senior Member OpenGL Guru
    Join Date
    Jun 2013
    Posts
    2,402
    Quote Originally Posted by Gedolo2 View Post
    Until the application isn't, this extension is basically has a no error reporting functionality, not a no error functionality.
    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. #10
    Intern Contributor
    Join Date
    Nov 2013
    Posts
    50
    Quote Originally Posted by GClements View Post
    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.
    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.
    Last edited by Gedolo2; 08-01-2017 at 02:54 PM. Reason: Added a few more better names

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
  •