Part of the Khronos Group
OpenGL.org

The Industry's Foundation for High Performance Graphics

from games to virtual reality, mobile phones to supercomputers

Results 1 to 9 of 9

Thread: Draft <GL3/gl3.h> released for feedback

Hybrid View

  1. #1
    Administrator Contributor
    Join Date
    Jan 2002
    Location
    Mt. View, CA
    Posts
    97

    Draft released for feedback

    There's a draft <GL3/gl3.h> header in the Registry now, as described in appendix H.2 of the OpenGL 3.1 specification. This is not ready for general use yet, but we'd appreciate feedback from interested parties, particularly in terms of making it work with existing GL 3.1 implementations (getting feedback from Mesa/X.org folks is probably most critical in this regard).

    Eventually it will be possible to just drop gl3.h in on top of a shipping GL3.1 implementation, but to get there we need to do some work on the calling conventions and other platform-specific stuff in the header before it's likely to work well on most platforms.

    In terms of the interfaces provided, it should be pretty good, but I wouldn't be surprised if a couple of tokens and functions either should be there and are not (core 3.1 functionality), or shouldn't be there and are (removed functionality).

    None of the preprocessor logic should be taken too seriously at this point other than GL_VERSION_3_1. Much of it is leftover from rewiring the glext.h generator scripts and there's no
    reason to continue #defining GL_VERSION_3_0 (or previous), for example. There are also some extraneous typedefs, such as GLintptrARB, that are only meaningful with glext.h and will be removed soon.

    It would be really helpful if feedback came by way of Khronos Bugzilla rather than in the forums, since TBH I am so swamped with internal Khronos stuff that I rarely have time to keep up with the forums. If you do provide feedback that way, please use product "OpenGL" component "Registry".
    Jon Leech
    Khronos API Registrar
    ARB Ecosystem TSG Chair
    GL/EGL/GLES Spec Editor
    ...and suchlike

  2. #2
    Member Regular Contributor
    Join Date
    Aug 2003
    Posts
    261

    Re: Draft released for feedback

    So does this mean extensions will automatically be bound correctly without user intervention? It seems some of them are listed in that header file.

  3. #3
    Junior Member Regular Contributor
    Join Date
    Mar 2007
    Location
    Latvia
    Posts
    225

    Re: Draft released for feedback

    No, it wont. But nobody stops writing you such functionality yourself. It is actually very simple.

  4. #4
    Senior Member OpenGL Pro Ilian Dinev's Avatar
    Join Date
    Jan 2008
    Location
    Watford, UK
    Posts
    1,290

    Re: Draft released for feedback

    It's just a clean-up of gl.h . You simply add "3" to your "#include <gl\gl.h>" lines, and if your project followed the specs, it compiles and runs without errors.

  5. #5
    Member Regular Contributor
    Join Date
    Mar 2005
    Posts
    301

    Re: Draft released for feedback

    Jon,

    while not directly related to the 3.1 parts, hitting the End key I just found the following (examples for discussion, glGetUniformIndices vs. PFNGLGETUNIFORMINDICESPROC).

    Should it be related to a scripting/sed accident, let's leave it at that.

    Are there any (valid, technical) reasons that:

    - function prototypes are conditionally visible ("#ifdef GL3_PROTOTYPES"), but the function pointer typedefs are not (i.e. always)?

    - function prototypes do NOT have the parameter names, but the function pointer typedefs have (isn't this opposite of what one would expect)?

  6. #6
    Administrator Contributor
    Join Date
    Jan 2002
    Location
    Mt. View, CA
    Posts
    97

    Re: Draft released for feedback

    Quote Originally Posted by tamlin
    Are there any (valid, technical) reasons that:

    - function prototypes are conditionally visible ("#ifdef GL3_PROTOTYPES"), but the function pointer typedefs are not (i.e. always)?
    Yes. You cannot expect that the static entry points for anything in glext.h will be defined in the GL link library, in which case there's no utility in defining a bunch of prototypes for functions you can't call except through a function pointer. If you do have a platform that defines some of the extensions in the GL link library, then you probably also have a gl.h provided by the platform that defines those extension interfaces.

    - function prototypes do NOT have the parameter names, but the function pointer typedefs have (isn't this opposite of what one would expect)?
    I don't think there's a valid technical reason, it's more an ancient legacy of the way the generator scripts were originally written at SGI 20-odd years ago persisting through many rewrites of the scripts. It could be changed and I occasionally find it a bit annoying myself, but OTOH it bulks up what's already an enormous header file even more and is a largely gratuitous change.
    Jon Leech
    Khronos API Registrar
    ARB Ecosystem TSG Chair
    GL/EGL/GLES Spec Editor
    ...and suchlike

Posting Permissions

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