Part of the Khronos Group
OpenGL.org

The Industry's Foundation for High Performance Graphics

from games to virtual reality, mobile phones to supercomputers

Results 1 to 10 of 37

Thread: OpenGL 4.6 request list

Threaded View

Previous Post Previous Post   Next Post Next Post
  1. #1
    Intern Contributor
    Join Date
    Nov 2013
    Posts
    50

    OpenGL 4.6 request list

    Please add the following features to OpenGL 4.6

    Add OpenGL ES 3.2 context creation functionality to OpenGL 4.6 core.

    Add the extensions from OpenGL ES 3.2 to core OpenGL.
    Make OpenGL a superset of OpenGL ES again.

    Make in core OpenGL the ASTC support mandatory and s3tc optional (or what I like to see more: deprecate/remove s3tc).
    Possibly adding one of the following ASTC extensions:
    OES_texture_compression_astc
    https://www.khronos.org/registry/gle...ssion_astc.txt
    texture_compression_astc_hdr
    https://www.opengl.org/registry/spec...n_astc_hdr.txt
    Maybe make a full and portable profile for ASTC with different texture limits to serve the full spectrum of devices?

    Put shader draw parameters in core.
    https://www.opengl.org/registry/spec...parameters.txt

    Allow using more varied names in core for low component texture components.
    Especially single and dual.
    Allow not only R but G, B and A as well.
    And allow another letter for differentiating between colour components and other miscellaneous components.
    (Maybe c for component or channel, maybe another letter)
    The reason, rational for such a thing is: it makes detecting errors much easier for programmers. Allowing them to much easier see if their code is using the components correctly or not.
    Do not mandate how to use the component names to avoid them becoming a programming limitation instead of a more expressive way to write code.



    If you introduce an extension for async shader compilation, please put async somewhere in the name. And have both compilation and loading of shaders done asynchronously by the extension.
    Perhaps the name could be GL_ARB_parallel_async_shader_compile for OpenGL and also used in OpenGL ES.
    Not GL_ARB_parallel_shader_compile.
    If it provides async compilation, that is a big feature/point, such a feature needs to be advertised in the name.
    Unify with how async is done in Vulkan might be a good idea.
    It seems only minor adjustments would need to be done to the following extension:
    https://www.opengl.org/registry/spec...er_compile.txt
    Also have the specification provide plenty of information about how it interacts with a shader cache. Put in the specification plenty of information about shader caches. What a shader cache is, what it does, allows and mention shader cache a few times more in the description of the extension.
    Do make sure there is good information about what async shader compilation and loading allows, especially in reducing lag spikes.
    Increasing predictability and performance while reducing lag and stutter.


    Do NOT put in features from Vulkan YET.
    The following is not applicable to putting compatibility contexts between OpenGL and Vulkan.
    It's too early. Between several things:
    - apparently a new Vulkan release this summer
    - the Vulkan spec churn (new documentation release every week)
    - the resulting spec churn from the new Vulkan release this summer
    - getting feedback from developers about desired feature sets
    Vulkan really is not ready yet to base individual features for OpenGL on.
    Once more time has passed it will be.
    Once the documentation becomes somewhat more stable (maybe as early as next year: 2017). Once Vulkan's features will be more crystallized with feature sets. And the new release of Vulkan has happened.
    After those things will have happened, it will be the right time to start doing feature cross-pollination between the two API's.
    Also don't put in SPIR-V when there is a new release coming up this summer.
    It makes little sense to start copying features between both API's.
    Especially since with Vulkan. There will be feedback on what features developers want to have through determining feature sets. Knowing what features are popular will allow spec makers at Khronos to optimally choose which features to copy to other API's.
    Last edited by Gedolo2; 05-23-2016 at 08:23 AM. Reason: Added async shader compilation name suggestion

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
  •