Page 1 of 2 12 LastLast
Results 1 to 10 of 12

Thread: Survey question regarding OpenGL ES 2.0 API and fixed fu

  1. #1
    Administrator khronos's Avatar
    Join Date
    Jun 2002
    Location
    Montreal
    Posts
    55

    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.

  2. #2
    Senior Member
    Join Date
    Sep 2003
    Location
    Seattle, WA
    Posts
    246

    Re: Survey question regarding OpenGL ES 2.0 API and fixed fu

    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 ]

  3. #3
    Junior Member
    Join Date
    Jul 2004
    Posts
    12

    Re: Survey question regarding OpenGL ES 2.0 API and fixed fu

    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.

  4. #4
    Junior Member
    Join Date
    Sep 2003
    Posts
    9

    Re: Survey question regarding OpenGL ES 2.0 API and fixed fu

    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?

  5. #5
    Senior Member
    Join Date
    Sep 2003
    Location
    Seattle, WA
    Posts
    246

    Re: Survey question regarding OpenGL ES 2.0 API and fixed fu

    "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 ]

  6. #6
    Junior Member
    Join Date
    Apr 2003
    Location
    Russia
    Posts
    3

    Re: Survey question regarding OpenGL ES 2.0 API and fixed fu

    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.

  7. #7
    Junior Member
    Join Date
    Sep 2004
    Location
    San Diego
    Posts
    7

    Re: Survey question regarding OpenGL ES 2.0 API and fixed fu

    [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

  8. #8
    Member
    Join Date
    Sep 2004
    Location
    Montreal
    Posts
    31

    Re: Survey question regarding OpenGL ES 2.0 API and fixed fu

    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.

  9. #9
    Junior Member
    Join Date
    Sep 2004
    Location
    San Diego
    Posts
    7

    Re: Survey question regarding OpenGL ES 2.0 API and fixed fu

    <BLOCKQUOTE><font size="1" face="Arial, Verdana, Helvetica, sans-serif">quote:</font><HR>Originally posted by V-man:
    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.
    <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

  10. #10
    Member
    Join Date
    Sep 2004
    Location
    Montreal
    Posts
    31

    Re: Survey question regarding OpenGL ES 2.0 API and fixed fu

    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.

Page 1 of 2 12 LastLast

Similar Threads

  1. OpenGL|ES 1.0 sample are not support Fixed-point
    By m933040045 in forum OpenGL ES general technical discussions
    Replies: 2
    Last Post: 05-10-2005, 03:35 AM
  2. Fixed Size - Fixed orientation texture with OpenGL
    By dautelle in forum OpenGL ES general technical discussions
    Replies: 0
    Last Post: 02-19-2004, 05:09 AM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •