Suggestions for next version of OpenGL ES

#21

[QUOTE=Gedolo2;37704]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.[/quote]

Both of these statements are completely untrue. No version of OpenGL or OpenGL ES dictates “what extensions are suppose to be present/supported”.

Take for example ARB_vertex_attrib_binding. This is an extension. However, the functionality exposed by this extension, the specific functions and enumerators, are also part of OpenGL 4.3. This does not mean that it is not still an extension, nor does it mean that OpenGL 4.3 mandates the presence of this extension.

If you want to use this functionality, you can check the version and the extension. If the version is 4.3 or greater, or the extension string is present, then the functionality is available. That’s how it works. The functionality is provided either through the version or though the extension. In versions prior to 4.3, it is optional, provided by the extension. In 4.3 and above, it is mandatory, whether the extension is present or not.

To be sure, OpenGL/ES do require specific features to be supported for a specific version. That is exactly why optional features are exposed via extensions; the core specifications specify the baseline functionality, with extensions covering extra functionality that could be supported.

Yes. And extensions are the exact mechanism that OpenGL and ES have for exposing “SPECIFIC features” as “optional features”.

If you want to know if tessellation shaders are supported by a particular implementation, you check the EXT_tessellation_shader extension. If it is present, then the functionality is supported, in accord with that extension specification.

That is exactly what you asked for: the ability to query if an optional feature is supported.

#22

(English is not my native language.)
Seems like my wording was off. My apologies.

The mechanism is generalised enough and already present, sounds good.

My request is about adding some rendering functionality/features (tessellation and geometry shaders) as optional functionality to the specification. Not as part of the baseline functionality but as part of the next OpenGL ES specification optional functionality.
If there wasn’t demand for those features, there wouldn’t be AEP (Android Extension Pack).

(I hope my language is correct and clear enough this time.)

#23

Please make sure the following three extensions are in the next version of OpenGL ES:
multi draw indirect
https://www.opengl.org/registry/specs/ARB/multi_draw_indirect.txt
multi bind
https://www.opengl.org/registry/specs/ARB/multi_bind.txt
shader draw parameters
https://www.opengl.org/registry/specs/ARB/shader_draw_parameters.txt

#24

Remove s3tc compression format.
Replace with newer formats (maybe by ASTC) that are both technically superior and unencumbered by patents.

#25

Make make sure the following extension is present as well:
GL_ARB_draw_indirect

#26

Add bindless texture functionality by adding the ARB_bindless_texture extension to OpenGL ES.

https://www.opengl.org/registry/specs/ARB/bindless_texture.txt
https://www.opengl.org/wiki/Bindless_Texture

#27

For an OpenGL ES 4.0 release, incorporate all AZDO extensions/functionality in the release.
AZDO: Approaching Zero Driver Overhead
http://www.slideshare.net/CassEveritt/approaching-zero-driver-overhead

#28

Do NOT merge OpenGL ES with a Vulkan embedded standard.
Keep OpenGL ES and embedded Vulkan separate.

#29

The OpenGL 4.6 release has some interesting extensions promoted to core.
Including SPIR-V, now it’s good to add to OpenGL ES.
Also following OpenGL 4.6 core extensions would be good to have in an OpenGL ES 4 release:
GL_ARB_texture_filter_anisotropic
GL_ARB_shader_group_vote
GL_ARB_shader_draw_parameters
GL_ARB_polygon_offset_clamp
GL_ARB_indirect_parameters