Suggestions for next version of OpenGL ES


#1

Please do bring out an OpenGL ES 4.
With only DSA functions, without non DSA functions.
Direct State Access is a big difference, change main version number from 3 to 4.
Create OpenGl ES 4.0
For application developers who want to use new functionality with non DSA functions, bring out an OpenGL ES 3.2 release with other performance enhancing functionality.

With for OpenGL ES 4 and if there will be OpenGL ES 3.2 context creation options in the next version of OpenGL 4.x.

This will allow to write better, shorter, less bloated, less error prone code that interfaces simpler and easier with middleware.

Add the following from OpenGL 4.5:
+Direct State Access (DSA) : object accessors enable state to be queried and modified without binding objects to contexts, for increased application and middleware efficiency and flexibility;

  • Robustness : providing a secure platform for applications such as WebGL browsers, including preventing a GPU reset affecting any other running applications;
    (Mobile devices such as tablets are starting to run multiple applications simultaneously.)

  • Flush Control : applications can control flushing of pending commands before context switching – enabling high-performance multithreaded applications;
    (Mobile devices are using quad core processors these days, more efficient, faster handling of commands is always a good improvement.)


#2

Have OpenGL ES 4 only support and use bindless textures and DSA functions.

Forms a good break with the major version number change (3 -> 4).


#3

Break compatibility going from OpenGL ES 3.x to OpenGL ES 4, has also been allowed going from OpenGL ES 1.x to OpenGL ES 2.


#4

Have context creation for OpenGL ES 4 and if created OpenGL ES 3.x too in OpenGL, similar to current OpenGL ES context creation in current OpenGL.


#5

And keep the compute shaders capability up to date with OpenCL.
With the newer OpenCL 2.0 release.


#6

Providing something between now and when OpenGL NG comes out.
Would be a nice thing. If next summer OpenGL NG isn’t finished yet, you can release OpenGL ES 4 and OpenGL 4.6.


#7

Don’t integrate SPIR(OpenCL 2.0).
Is not good feature to integrate with an OpenGL ES 4 release.
Because OpenGL NG/newer would be a better fit for integrating this IR(intermediate representation) feature (SPIR, OpenCL IR)
Add OpenCL 2.0 compute shaders without the SPIR(OpenCL) IR in OpenGL ES 4.

Do specify SPIR (OpenCL 2.0) only for OpenGL NG/newer.
This feature (SPIR) fits very well with the suggested IR representation feature of OpenGL NG.


#8

And remove pre-ETC2/EAC texture compression formats/algorithms.
Older algorithms should make place for technically more useful alternatives such as ETC2/EAC and newer.
Good version number change to do this.


#9

Be sure to keep things that improve performance.
Such as the pieces mentioned in AZDO(Approaching Zero Driver Overhead):
http://www.slideshare.net/CassEveritt/beyond-porting
Features mentioned are GL_ARB_buffer_storage + Bindless / sparse textures + shared UBOs (uniform buffer object) + GL_ARB_multi_draw_indirect.
http://www.geeks3d.com/20140123/how-to-increase-the-number-of-draw-calls-in-opengl/

Be sure to keep the indirect drawing capabilities up to including but not limited to GL_ARB_multi_draw_indirect from OpenGL 4.3.


#10

In OpenGL ES use the OpenCL ES profile. Because ES profile.


#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.


#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.


#13

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.


#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/specs/NV/bindless_multi_draw_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.


#15

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.


#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.)


#17

From https://www.khronos.org/news/press/khronos-group-announces-key-advances-in-opengl-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.


#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.


#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.


#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.