Page 2 of 4 FirstFirst 1234 LastLast
Results 11 to 20 of 31

Thread: Suggestions for next version of OpenGL ES

  1. #11
    The previous comment talking about using OpenCL ES profile is talking about the compute shader. The use of OpenCL (ES) based/inspired API in the compute shader.
    Last edited by Gedolo2; 11-13-2014 at 01:31 AM.

  2. #12
    Use same version number for GLSL ES as for OpenGL ES.
    Thus when bringing out another OpenGL ES 3.x have the GLSL ES version also be 3.x.
    When bringing out an OpenGL ES 4.0 have the GLSL ES version also be 4.0.

  3. #13
    Junior Member
    Join Date
    Jun 2010
    Posts
    21
    While we're getting our wish list together, how about bindless vertex attribute and index lists? Minimizing time spent/wasted in the driver just getting ready to launch batches is even more important with slower CPUs and memory.
    Last edited by Dark Photon; 11-19-2014 at 05:48 AM.

  4. #14
    Oh yes, of course.
    To make the list complete for the new bindless paradigm:
    Add bindless vertex processing!
    Efficient drawing of vertex data is very, very useful. Is a natural fit with the newer DSA and bindless textures way of working.
    https://www.opengl.org/registry/spec...w_indirect.txt
    http://www.ustream.tv/recorded/51212968

    @Dark Photon
    Thanks I missed that one.

    Also the bindless vertex processing should definitely be present in OpenGL 4.x too! And be the same.

  5. #15
    Administrator khronos's Avatar
    Join Date
    Jun 2002
    Location
    Montreal
    Posts
    98

    Suggestions for next version of OpenGL ES

    We're restructuring and cleaning up our forums. This will be the official thread for everyone to post their suggestions for the next version of OpenGL ES. We have moved the most recent suggestions into this thread already. We look forward to seeing more suggestions.

  6. #16
    Bring out this new version of OpenGL ES out after an OpenGL 4.x update with the efficient vertex processing.

    It's important to not bring out an OpenGL Es too soon. Since missing the tidy up and final cleanup of the OpenGL 4.x API line can easily be avoided.
    And having to make more releases of OpenGL ES would move focus too much away from glNext.
    It would be great if OpenGL 4.x could finish and OpenGL Es could finish with a last release, all tidied up and cleaned up.
    The idea is to have a middle ground between current OpenGL ES 3.1 and glNext.
    (Maybe an OpenGL ES 4 release in summer 2016 or summer 2017 would be good.)

    The idea is to tidy up and finish modernizing the current API lines and ramping down development in favor of glNext.
    In an stepwise and smooth fashion.
    (Leaving the current API lines only old and not ridiculously ancient, outdated.)
    Last edited by Gedolo2; 02-04-2015 at 01:26 PM.

  7. #17
    From https://www.khronos.org/news/press/k...engl-ecosystem
    and OpenGL 4.5 at a glance from https://www.khronos.org/opengl/

    GL_ARB_clip_control
    GL_ARB_cull_distance

    Very interesting functionality.
    Last edited by Gedolo2; 06-14-2015 at 01:02 PM.

  8. #18
    Evaluate features from Android Extension Pack (AEP).

    Introduce optional features for standardizing on ES on how to use tessellation and geometry shaders where supported. Since not every device has them but a developer might want to use them where available we need a flexible solution.
    The solution is to satisfy developers wishes by having optional features.
    This way the goals of standardising functionality and not locking out platforms/devices are both satisfied for OpenGL ES.
    Allows to standardize how to use those desktop-class graphics features, allowing for the most flexible and developer friendly approach.

    Developers can take into account different feature sets being present.
    And code accordingly.
    Functions to check whether the ( tessellation and geometry shaders ) functionality is present in devices must be present and not optional.

  9. #19
    That's what extensions are. They're a standardized mechanism for querying and accessing optional features of an implementation. You are describing exactly why extensions exist.

    We have a standard to "check whether the ( tessellation and geometry shaders ) functionality is present in devices." The extension mechanism in OpenGL ES is "not optional".

    So it's not clear what exactly you're asking for that doesn't currently exist.

  10. #20
    Different OpenGL profiles and versions dictate what extensions are suppose to be present/supported.
    Both OpenGL and OpenGL ES demand some extensions/feature to be supported. Meaning they are not optional features.

    My previous post is not about wanting an extension mechanism
    It's about whether some features being mandatory or optional.

    The request is about having the mentioned, SPECIFIC features as optional features.
    And maybe more applicable to your questions, requesting those features STAY OPTIONAL.
    This is about having those particular features as optional features in the next OpenGL ES version.
    It's not about the standard to check, it's about the features themselves.

Page 2 of 4 FirstFirst 1234 LastLast

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
  •  
Proudly hosted by Digital Ocean