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

  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

  7. #7
    Junior Member Newbie
    Join Date
    Nov 2007
    Posts
    22

    Re: Draft released for feedback

    This isn't a great idea when considering multi-version libraries such as SDL as gl.h and gl3.h can't be compiled together. From this it's unlikely to find full adoption and may interfere with other APIs, is gl3.h really needed?

    I would support the idea if it was more like GLEW and provided easy access to any core spec and extentions but otherwise I don't see a point.

  8. #8
    Junior Member Newbie
    Join Date
    Jun 2010
    Posts
    1

    Re: Draft released for feedback

    It would be nice to see a more developer-oriented/user-friendly header. I can live with having to grab function pointers for what I want to use, but the main problem I and others have is in knowing _what_ to grab, especially now that the deprecation model is in place. A complete API listing for the different OGL versions would be a great step forward in solving this. I know a fair few people who've chosen DX over OGL for this very reason.

    Quote Originally Posted by Scribe
    I would support the idea if it was more like GLEW and provided easy access to any core spec and extentions but otherwise I don't see a point.
    I also this comment! Even something like a #define to specify which version and profile of OGL your code wants support for would be fantastic. Then you could at least be 100% certain that you're not using any functionality that isn't included in the target version (e.g. deprecated/from newer OGL versions). There's far, far too much API-user-interpretation possible at the moment.

    I think the very fact that libraries like GLEW exist to try and help with the confusion/uncertainty in using OGL these days is indicative of some fundamental problems. If I hadn't started with OGL back in the days when it was still extremely straightforward to use (circa '96), I'd probably have picked DX. Much, much more documentation, slightly better feature-set, and a lot simpler to set up correctly.

    ...Wow. I never thought I'd say that last phrase.
    ...Is it _supposed_ to do that?

  9. #9
    Advanced Member Frequent Contributor
    Join Date
    Apr 2009
    Posts
    595

    Re: Draft released for feedback

    Wish:

    rather than .spec to "hold" the generating data for the GL functions, someone floated this idea in the GL4.1 feed back thread, but I think it is a good idea: make the spec file an XML file, with a public thingy on the meaning of each field.

Posting Permissions

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