View Full Version : Please add the following OpenGL 4 stuff into OpenGL ES
03-12-2010, 01:46 PM
Recenty with the release of OpenGL 4.
There are a few extensions that really could improve efficiency.
The drawing of data generated by OpenGL, or external APIs such as OpenCL, without CPU intervention is a really good thing to have here. Especially because the CPU's are very constrained in devices that use OpenGL ES.
Furthermore the following things should be added because they allow performance improvements that count for a lot where OpenGL ES is being used.
* shader subroutines for significantly increased programming flexibility;
* performance improvements, including instanced geometry shaders, instanced arrays, and a new timer query.
The timer query and the new shader flexibility allows for mini benchmarking and self optimizing programs when well written. (By using, trying and timing different approaches at runtime and then choosing the most efficient. Keeping improving until the program has achieved the maximum efficiency.)
Of course all things that allow for pure performance improvements should be added (no new stuff e.g. tessellation does not belong here)
Please add seamless cube maps (filtering) from OpenGL 3.2
And Shader Fragment coordinate convention control
(didn't found them while using the search function in the pdf describing the specs)
Please do consider as much as possible (preferably all) of the features described here.
Especially the drawing without cpu intervention + other performance improvements will be very welcome in OpenGL ES.
02-15-2012, 01:06 PM
OpenGL ES 2.0
OpenGL ES 2.0 was publicly released in March 2007. It eliminates most of the fixed-function rendering pipeline in favor of a programmable one. Almost all rendering features of the transform and lighting pipelines, such as the specification of materials and light parameters formerly specified by the fixed-function API, are replaced by shaders written by the graphics programmer. As a result, OpenGL ES 2.0 is not backward compatible with OpenGL ES 1.1. 2.0 also goes agnostic on the handedness of the coordinate system, and many implementations seem to be left handed, in contrast to OpenGL history.
Please specify a default handedness of the coordinate system.
Make this fully specified in all the kinds of OpenGL.
02-16-2012, 02:26 PM
Might as well add these too:
All things for operability with OpenCL:
+CopyBuffer API for fast data copy; used in conjunction with OpenCL
(+If not present rectangular textures, if I need a rectangle and use square I'm going to have to waste memory. Going to have to use smallest square where the rectangle fits in.
+The ability to bind programs individually to the five programmable stages (Vertex, Tessellation Control, Tessellation Evaluation, Geometry, and Fragment)
Because: Or else you have to generate and store all combinations. Costs memory and performance.
+Support for modifying an arbitrary subset of a compressed texture, without having to re-download the whole texture to the GPU for significant performance improvements.
02-17-2012, 03:40 AM
Some more stuff:
+Separation of texture state and texture data through the addition of a new object type called sampler objects.
+sRGB framebuffer stuff
Would be nice to be able to use sRGB for any texture.
Be able to assign a gamma value with any random texture that I want to work with.
(Include a default gamma value that asks the least amount of calculations to do stuff.
When not specified OpenGL works with the texture as if the default gamma value is assigned to it.)
+Direct State Access
On the long term, replacement of all functions that need bind and release with DSA counterparts.
+Able to specify texture format. There are all sorts of texture formats specified. Please make a unified way to at least determine the number of bits and order of components. This will make a lot of vendor specific extensions unecessary. (Meaning order and number of bits for each component, to leave out a component just say the component with 0 bits.)
+Try to replace as many vendor extensions with EXT counterparts.
+Try to replace as many EXT stuff with ARB where possible, no rush!!!
Better late than a bad specification of a function because of time pressure.
02-17-2012, 03:47 AM
+Make it so that a future version of WebGL need as little specific extensions as possible to work.
03-12-2012, 11:54 AM
+All the things needed for order independent transparency. (if doable)
05-09-2012, 03:22 PM
Also posted here:
Just to add something.
I looked at the way context creation is done.
The application should be able to
a) get major, minor and core or compatibility profile (this is done and good, please make this kind of a thing consistent across all khronos api's so you only have to develop it once.)
b) when an application wants to exist let it present a version and profile to the driver.
The driver then decides to execute it or gives an error with does not have <needed version> for application: <application name>.
(There seems to be inconsistencies between the GL and GL ES about this.
Also I'm not sure if I read correctly
but please allow for a general api mechanism where the application can just do a call with the version and profile it wants.)
This can be useful for all the api's, dealing with changing specifications.
Making a general thing across all khronos api's benefits from only having to develop it once.
old applications will be recognizable by new drivers because of the calls.
New applications can just work on new drivers since the drivers can have a very good idea of what is asked. You can theoretically even break the api constantly and still have old and new applications running on new drivers without problems related to compatibility.
(Provided that the driver writers can keep up implementing everything.)
No danger for legacy + able to change everything without problems related to the way changing something could mess up expectations between applications and drivers.
05-27-2012, 06:57 AM
Somewhere I read NPOT (non power of two) textures have some limitations.
(The article I read mentioned mipmaps but there may be other things.)
+Being able to work with NPOT textures without limitations compared to POT textures.
(Meaning removing the mipmap problems and other problems if there are and if that's possible.)
+Being able to replace OES_texture_npot with an arb extension.
(May or may not require OpenGL to add or change functionality to get the exact same behaviour.)
Powered by vBulletin® Version 4.2.2 Copyright © 2015 vBulletin Solutions, Inc. All rights reserved.