Survey question regarding OpenGL ES 2.0 API and fixed fu

Should the OpenGL ES 2.0 API include the fixed functionality from OpenGL ES 1.X that can be cleanly replaced by programmable vertex and fragment shaders?

OpenGL ES 2.0 will provide vertex and fragment shader programmability using a close derivative of the desktop OpenGL Shading Language. The desktop OpenGL 2.0 API retains full OpenGL 1.5 fixed functionality to provide full backwards compatibility within a single API. Desktop OpenGL 2.0 also enables fine-grained mixing of shaders with the original fixed-function pipeline to enable OpenGL 1.X programs to be incrementally upgraded with programmability. The design goals for OpenGL ES 2.0 place a stronger emphasis on API simplicity and small driver footprint for embedded markets. OpenGL ES 2.0 could eliminate the fixed functionality from OpenGL ES 1.X that can be cleanly replaced by programmable vertex and fragment shaders - resulting in a smaller, simpler API. Platforms that need backwards compatibility with OpenGL ES 1.X applications could ship a separate OpenGL ES 1.X library. The source code of shader programs that emulate the full OpenGL ES 1.X fixed pipeline could be provided to execute 1.X applications that wish to incrementally use programmability through modifying those shaders. Just as with OpenGL ES 1.X, some software modifications would be necessary to port applications between desktop OpenGL 2.0 and embedded OpenGL ES 2.0.

My personal preference:

I fully support the idea of removing the fixed function pipeline completely for OpenGL ES 2.0.

In addition, make OpenGL ES 2.0 floating point only. Fixed point introduces too many hidden pitfalls (under/overflow/rounding) to be useful for a general shading language. These overflow/underflow/rounding issues were exactly the areas were Vincent needed the most work to get through the conformance test (internally, Vincent is using dynamic code generation, so the problems for a programmable shader directly apply).

Just my two cents,
HM

[ September 17, 2004: Message edited by: Hans-Martin Will ]

I’m with you on eliminating the fixed point math. The fixed function pipeline issue is a bit more complex.

Desktop GPU’s supporting programmability have been in production for quite a few years now, but a significant number of machines in the field still lack the capability. This number is high enough to affect design decisions on desktop apps - if you want your app to run on the maximum number of machines, you use the fixed function pipeline. So for the time being, on the desktop, many new apps still use the fixed pipeline.

By eliminating the fixed pipeline from ES, you’ll restrict the portability of code from the desktop to handhelds. The counter-argument is that this is an opportunity for a fresh start, unencumbered by legacy issues.

Tough call.

Using a fixed-function emulation library, would mixing shader and fixed-function code be allowed?

If so, would there be any burden on the programmer to avoid stepping on the toes of the emulation layer?

“Platforms that need backwards compatibility with OpenGL ES 1.X applications could ship a separate OpenGL ES 1.X library.”

I understand this that the approach is similar to DirectX, where more than one version of the API can be supported; say by giving the driver library a different name.

A model for the success of this rather radical proposal for OpenGL ES 2.0 could be the introduction of XML. First there was IBM’s GML/bookmaster (= Iris GL), which got bloated into SGML (= OpenGL 2.0), but the whole approach really only took off in mainstream once all the legacy overhead got removed to create XML as a simple, elegant & universal standard (= OpenGL ES 2.0?). Probably the first implementation of OpenGL ES 2.0 to hit the market is going to be PS3 anyway, and there the fixed function pipeline would definitively not be needed.

An aspect I would find more interesting, however, is to learn what approach the working group is considering for reducing the complexity of the driver. By introducing a low level shading language?

  • HM

[ September 29, 2004: Message edited by: Hans-Martin Will ]

I think best way can be:

  1. Completely remove any fixed-function pipeline from OpenGL ES 2.0 API
  2. Introduce different naming for link-libraries (something like libGLES2.z)
  3. Open-source implementation for GLES 1.1 -> GLES 2.0 translation library.

[QUOTE]Originally posted by Boardmaster:
[QB]Should the OpenGL ES 2.0 API include the fixed functionality from OpenGL ES 1.X that can be cleanly replaced by programmable vertex and fragment shaders?

For compatibility’s sake, ES 2.0 should definitly include the fixed functionality. Has anyone else noticed how popular the x86 CPU is? – Love it or hate it, the fact remains that a lot of people would rather have compatible. Why else is OpenGL so popular, and not Glide? (x86, and not Itanium???)

I suggest that even more compatibility needs to be in place.

OpenGL 2.1 should include OpenGL-ES 2.0 functionality and OpenGL-ES 1.0, 1.1 1.5 etc.
And OpenGL 1.0, 1.1, 1.3, 1.4, 1.5 etc.

I’ve lately been working on porting various OpenGL things to ES, and this is becoming somewhat problematic. If the OpenGL-ES functionality is a subset of OpenGL, then why is the API not a subset? I should be able to run my ES application on an ES card, or better. Otherwise we will need 4+ different versions of our applications so that they can work everywhere, even though we are using the smallest subset of functionality.

Jamie

From my POV, the fixed function is not interesting.

I don’t see why GL ES 1.x could not be for less powerful hw and GL ES 2.0 could be for more powerful stuff.

Software houses can put out 2 versions instead of having multiple paths in one binary.

<BLOCKQUOTE><font size=“1” face=“Arial, Verdana, Helvetica, sans-serif”>quote:</font><HR>Originally posted by V-man:
[b]From my POV, the fixed function is not interesting.

I don’t see why GL ES 1.x could not be for less powerful hw and GL ES 2.0 could be for more powerful stuff.

Software houses can put out 2 versions instead of having multiple paths in one binary.[/b]<HR></BLOCKQUOTE>

But they don’t have to have 2 versions. They can have a 2.0 version, and the 1.x fixed functions will not get in the way.

The apps that want to be 1.1 compatible can then also work on any system.

The driver writers can fairly easily add many of the glFoox functions like this:

glFoox(GLFixed fixed){
GLfloat passIt;
passIt = convertIt(passIt);
return glFoof(passIt);
}

I understand your lack of interest in the fixed functionality portion, but having the driver include the fixed calls doesn’t hinder your Slang development. – It’s exclusion will affect those that do though.

For OpenGL to continue being as successful as it is, it needs to maintain backward compatibility, and subset compatibility. I believe that this is the reason that the fixed functionality is maintained in GL 2.0

  • This way, the shiny new doom3 game that I got still works with my shiny new OGL2 graphics card, even though OGL2 was not quite out when the game was developed. – The same should apply to ES.

Jamie

GL ES needs to be small, like the first post describe.

It can be by stripping away redundent stuff.

Besides, it’s not like the x86 platform where thousands of dollars of old software need to be supported.

It is my understanding Doom3 doesn’t use GL2 functionality.

<BLOCKQUOTE><font size=“1” face=“Arial, Verdana, Helvetica, sans-serif”>quote:</font><HR>Originally posted by V-man:

It is my understanding Doom3 doesn’t use GL2 functionality.
<HR></BLOCKQUOTE>

Exactly. It uses the closest thing that was available at the time, the ARB GLSlang extension. When the proper GL2 driver comes out, it will be compatible, and the game will still work. So you can update your driver without buying a new game!

How much bigger will GLES be if it includes the old API?

How much size is available on current ES platforms?

A My guess is that the size increase will not even be noticeable on the systems that use ES.

[ September 23, 2004: Message edited by: James Amendolagine ]

I think Doom3 uses ARB_vertex_program and ARB_fragment_program. I don’t own the game, but from the files I’ve seen, that’s my understanding.

As for backwards compatibility, your case with GL2 doesn’t make sense, unless what you are asking for is for the extensions string to contain the extension name of the feature.

In the case of GLES 2, they will make another a 1.x compatibility library.

So all software will run.

This topic was automatically closed 183 days after the last reply. New replies are no longer allowed.