Part of the Khronos Group
OpenGL.org

The Industry's Foundation for High Performance Graphics

from games to virtual reality, mobile phones to supercomputers

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

Thread: GL 4 Core Function Loading in Core 3.1+ Confusion

  1. #1
    Junior Member Newbie
    Join Date
    Dec 2013
    Posts
    10

    GL 4 Core Function Loading in Core 3.1+ Confusion

    Recently, I removed GLEW from my engine and implemented my own GL function loader. Well, I never really cared about it.
    During the refactoring step, I came to download the glcorearb.h file from the gl website and I was not so amused to see what functions became core 4.0.

    First of all, I just thought, OpenGL 4.0 is an API for "new" generation hardware. You know, when it started with hw tesselation and stuff. Anyway. Seeing the Transform Feedback function in the GL_VERSION_4_0 section of glcorearb.h somehow breaks my heart.

    I really commited to OpenGL 3.1-3.3 API features, because I wanted to port to OpenGL ES 3 soon and I thought that would be like a dream if using OpenGL 3.3 core features. I also really need Transform Feedback, because this is a super nice(and only) OpenGL 3.1+ feature(in my thoughts) that allows you to do GPU only computation. I.e. not being required to go though the CPU.

    But what does it mean to see those TF functions in the GL_VERSION_4_0? Well I tried the following:

    When I create a GL 3.1, 3.2 or 3.3 context with core profile, the nvidia driver actually supports the TF functions, but it does not support all of the function listed in the GL_VERSION_4_0 section of glcorearb.h file. This is important to me! With an 3.1, 3.2 or 3.3 core profile context, I can actually load the TF functions! With support, I mean wglGetProcAddress is able to load the function.

    Now. Creating a 4.0 core profile context, ALL function of the GL_VERSION_4_0 can be loaded!

    So whats going on? Being able to load functions listed under GL_VERSION_4_0 in glcorearb.h with a GL 3.1, 3.2 or 3.3 core context?

    By any chance, could someone please enlighten me?

  2. #2
    Senior Member OpenGL Lord
    Join Date
    May 2009
    Posts
    5,906
    But what does it mean to see those TF functions in the GL_VERSION_4_0?
    It means that NVIDIA probably supports ARB_transform_feedback2 and/or ARB_transform_feedback3. These are both "backwards-compatibility extensions" or "core extensions"; so they use the same function entrypoints as the core OpenGL version feature. That way, hardware that can't support all of, for example, OpenGL 4.0 can express support for parts of it via extensions.

    If you're going to write an OpenGL loader (and I have no idea why you'd want to, since there are many of them with varying featuresets), then you must make sure to only load functions for things you've verified are actually available. Many OpenGL implementations will return non-NULL function pointers for everything, even for `glFunctionThatDoesntExist`. You should use the version number and the extension list to define what functionality is available.

  3. #3
    Junior Member Newbie
    Join Date
    Dec 2013
    Posts
    10
    I though, Transform Feedback is OpenGL 3.1-3.3 domain!? It really bugs me that especially DrawTransformFeedback is in OpenGL 4 domain! I really do not understand why this is in OpenGL 4 Domain. Isn't OpenGL 4.0 supposed to mainly introduce the new tesselation/compute functionality?
    If I take a look into the Transform Feedback extensions, I can not see any note of OpenGL 4. It is rather mentioning OpenGL 2!
    Quote Originally Posted by ARB_transform_feedback2
    The OpenGL Shading Language (GLSL) is required. OpenGL 2.0 or the ARB_shader_objects extension is required.
    What is the general way of figuring out which feature is supported in which version of OpenGL?
    If I created an OpenGL 3 core profile context, can I assume to be provided with ALL OpenGL 3 Core functionality?
    What do you call core functionlity. Is it still call "extensions"?

    Let's say, you implemented Transform Feeback into your engine and you require it for certain algorithm(make it fast). What would you tell a customer which OpenGL Version(compatible graphics card) he/she requires in order to run the program?
    Last edited by master_of_the_gl; 12-31-2015 at 06:37 AM.

  4. #4
    Senior Member OpenGL Guru
    Join Date
    Jun 2013
    Posts
    2,402
    Quote Originally Posted by master_of_the_gl View Post
    I though, Transform Feedback is OpenGL 3.1-3.3 domain!?
    glBeginTransformFeedback is 3.0. glBindTransformFeedback and glDrawTransformFeedback are 4.0. glDrawTransformFeedbackInstanced is 4.2. glCreateTransformFeedbacks is 4.5.

    Quote Originally Posted by master_of_the_gl View Post
    It really bugs me that especially DrawTransformFeedback is in OpenGL 4 domain! I really do not understand why this is in OpenGL 4 Domain. Isn't OpenGL 4.0 supposed to mainly introduce the new tesselation/compute functionality?
    If I take a look into the Transform Feedback extensions, I can not see any note of OpenGL 4. It is rather mentioning OpenGL 2!
    The only "domains" are (desktop) OpenGL and OpenGL ES. Other than that, OpenGL versions aren't maintained in parallel. The publication of the OpenGL 4.0 specification meant that there would be no more OpenGL 3.x versions.

    Quote Originally Posted by master_of_the_gl View Post
    What is the general way of figuring out which feature is supported in which version of OpenGL?
    The specification for a particular version specifies everything that's provided by that version. The OpenGL 4 reference pages list the supported versions for each function at the bottom of each page. If specific parameters or combinations of parameters require a particular version higher than that for the function itself, it is usually documented in the Notes section.

    Quote Originally Posted by master_of_the_gl View Post
    If I created an OpenGL 3 core profile context, can I assume to be provided with ALL OpenGL 3 Core functionality?
    Yes.

    Quote Originally Posted by master_of_the_gl View Post
    What do you call core functionlity. Is it still call "extensions"?
    An extension is anything that isn't core functionality. Most core functionality in later versions started out as an extension before being added to core. However: it's not uncommon for the version added to core to differ from the extension in some respect, and even if there is no difference, the core version is not the extension. You can't expect to be able to use functions or enumerants ending in EXT, NV, etc unless you've queried for the extension and found it to be present, regardless of the version. And you can't assume that you can "mix and match" the two, e.g. using enumerants from the extension with functions from the core version or vice versa.

    Quote Originally Posted by master_of_the_gl View Post
    Let's say, you implemented Transform Feeback into your engine and you require it for certain algorithm(make it fast). What would you tell a customer which OpenGL Version(compatible graphics card) he/she requires in order to run the program?
    Which transform-feedback features? If you only need the functions which are present in 3.0, then you only need 3.0. If you need glDrawTransformFeedback() then you need 4.0.

  5. #5
    Junior Member Newbie
    Join Date
    Dec 2013
    Posts
    10
    First of all. Thank you for your explanations!

    I am particularly talking about ARB_transform_feedback2.

    I totally commited to that extension because I thought it is within OpenGL 3.1-3.3 featureset. Very important: Pre OpenGL 4 capable hardware! Targeting OpenGL 3.x and OpenGL ES 3 is very important to me.

    Now, the extension text mentions DrawTransformFeedback and in fact I am also using it a lot! But I can not see any mention of OpenGL 4 in that text. So I wonder why, in this example, DrawTransformFeedback became an OpenGL 4 Core feature?! The text only refers to OpenGL 2.1.

    Why does ARB_transform_feedback2 has become an OpenGL 4 Core feature when OpenGL 4 hardware is not required for that feature?

    P.S.

    Allow me ask the other way around: Is it possible to create an OpenGL 4.0 core profile context on a graphics card that does not feature OpenGL 4 hardware feature like tesselation?
    Last edited by master_of_the_gl; 12-31-2015 at 09:36 AM.

  6. #6
    Senior Member OpenGL Lord
    Join Date
    May 2009
    Posts
    5,906
    Isn't OpenGL 4.0 supposed to mainly introduce the new tesselation/compute functionality?
    No. It includes lots of things. Some require very specific hardware, but many of them could also be implemented on lesser hardware. That's why extensions like ARB_transform_feedback2 exist; so that pre-4.x hardware can still expose that particular functionality without having to expose it all.

    Targeting OpenGL 3.x and OpenGL ES 3 is very important to me.
    Then you have made a mistake and need to undo it. ARB_transform_feedback2 isn't supported in OpenGL ES of any kind.

    If you want to prevent such mistakes in the future, you should use an OpenGL Loading Library that provides version-specific loaders. Where you can say "only give me what core OpenGL 3.3 provides", and the headers you get will only have core functions from that version.

    Now, the extension text mentions DrawTransformFeedback and in fact I am also using it a lot! But I can not see any mention of OpenGL 4 in that text. So I wonder why, in this example, DrawTransformFeedback became an OpenGL 4 Core feature?! The text only refers to OpenGL 2.1.

    Why does ARB_transform_feedback2 has become an OpenGL 4 Core feature when OpenGL 4 hardware is not required for that feature?
    Think of it like this.

    It's a required feature of OpenGL 4.x. But it's an optional feature of any OpenGL version 2.0 or better. It may be available or it may not. The way you state that an optional feature is available on the current OpenGL implementation is with an extension.

    So if the OpenGL version is 4.0+ OR ARB_transform_feedback2 is available, then the functionality is there. That's what you do to test for it. And if your program relies on it, then you need to have your program terminate if the condition fails.

    Allow me ask the other way around: Is it possible to create an OpenGL 4.0 core profile context on a graphics card that does not feature OpenGL 4 hardware feature like tesselation?
    No.

  7. #7
    Senior Member OpenGL Guru
    Join Date
    Jun 2013
    Posts
    2,402
    Quote Originally Posted by master_of_the_gl View Post
    Now, the extension text mentions DrawTransformFeedback and in fact I am also using it a lot! But I can not see any mention of OpenGL 4 in that text.
    ARB_transform_feedback2 says
    Status

    Complete. Approved by the ARB at the 2010/01/22 F2F meeting.
    Approved by the Khronos Board of Promoters on March 10, 2010.
    OpenGL 4.0 was published March 11, 2010, i.e. it didn't exist at the time that the extension was being formalised.

    More generally, extensions are normally written against the oldest core version which it is practical to extend. The purpose of transform-feedback is to store the outputs from a vertex shader, which means that it's going to be rather awkward to write it as an extension to a version which doesn't have shaders (i.e. any 1.x version).

    Quote Originally Posted by master_of_the_gl View Post
    Why does ARB_transform_feedback2 has become an OpenGL 4 Core feature when OpenGL 4 hardware is not required for that feature?
    Writing an extension against a specific version of the standard doesn't say anything about the type of hardware required to implement that extension. Just because it's written against 2.1, that doesn't mean that the extension can be implemented on any hardware which can fully implement 2.1, only that it's practical to write the extension specification without needing to refer to language which was added in later versions.

    But even if it can be implemented on 3.x hardware, OpenGL 3.3 and OpenGL 4.0 were both released on March 11th, i.e. the day after the extension became final. In theory, it could have been incorporated into either. The choice may have been dictated by practical considerations, e.g. if the extension was initially formulated at a time when drivers for 3.3 were well advanced but drivers for 4.0 were at an early stage or not yet started, excluding it from 3.3 could have avoided delays in providing drivers.

    Quote Originally Posted by master_of_the_gl View Post
    Allow me ask the other way around: Is it possible to create an OpenGL 4.0 core profile context on a graphics card that does not feature OpenGL 4 hardware feature like tesselation?
    In theory, yes: it's entirely possible to provide a conforming OpenGL implementation for a 1990s-era VGA card, but it's going to be implemented entirely in software. In practice, vendors typically don't bother supporting OpenGL versions which would require substantial software fallbacks. They expose the highest version which can be fully implemented in hardware then whichever individual extensions the hardware supports. That allows the application to select an approach which is appropriate for the hardware.

    It's not possible (or at least it shouldn't be possible) to create a 4.0 context with a hardware+driver combination where some 4.0 feature simply isn't available. If you successfully create a 4.0 context, glCreateShader(GL_TESS_EVALUATION_SHADER) isn't allowed to fail with GL_INVALID_ENUM.

    Having said that, vendors do sometimes take liberties with conformance. E.g. the noise functions were part of GLSL since the beginning. They were eventually deprecated in 4.4 because no-one actually implemented them.

  8. #8
    Senior Member OpenGL Lord
    Join Date
    May 2009
    Posts
    5,906
    More generally, extensions are normally written against the oldest core version which it is practical to extend. The purpose of transform-feedback is to store the outputs from a vertex shader, which means that it's going to be rather awkward to write it as an extension to a version which doesn't have shaders (i.e. any 1.x version).
    It's important to note that "written against" and "minimal version" are not always the same version number. For example, transform_feedback2 is written against OpenGL 2.1, so all of its changes are relative to that specification. But the minimum version it says that it requires is 2.0.

  9. #9
    Junior Member Newbie
    Join Date
    Dec 2013
    Posts
    10
    For me, OpenGL 3.3 to OpenGL 4.0 was like the transition of DX10 to DX11 which was like the transition from non-tessellation hardware to tessellation hardware. So that API versions transition became dependent on the hardware due to tessellation. So in my eyes, making a feature core OpenGL 4.0 that does not require tessellation, makes no sense to me, because ARB_transform_feedback2 has a wide range of usefullnes that could be used on pre tessellation hardware. Yes I understand that it can still be present due to implemented extensions. But saying my app requires OpenGL 3.3 core instead of "I basically only need OpenGL 3.3 core but I also need some functionality of OpenGL 4 core that do not depend on hardware and could be there. Here's the list.", just sounds better.

    So then, lets say, you know, you have a DirectX 10 compatible GPU. Would you buy a game/application that requires DirectX 11? I suppose you would not. Becuase you want that hardware implemented goodness of functionality.

    How would you say that in OpenGL language? Where do you draw the compatibility line WITHOUT passing a 100 line extension list to the customer listing all OpenGL extension that are required for running your program?

    Because you could basically say, my application requires OpenGL 2.0 but with this list of extensions. I think no one would be interested in that list. How would you explain to a customer, what hardware is required to run the program by telling an OpenGL version? As a customer you may be confronted with a decision like "Do I have to buy new hardware in order to run that program?"

  10. #10
    Senior Member OpenGL Lord
    Join Date
    May 2009
    Posts
    5,906
    Quote Originally Posted by master_of_the_gl View Post
    For me, OpenGL 3.3 to OpenGL 4.0 was like the transition of DX10 to DX11 which was like the transition from non-tessellation hardware to tessellation hardware. So that API versions transition became dependent on the hardware due to tessellation.
    Your belief that D3D11 == "tessellation" is based on marketing speak and buzzwords, not actual facts. Tessellation may have been the marque feature of D3D11, but it was hardly the only thing it brought to the table.

    D3D11 represented a higher level of functionality than D3D10. But that higher level included a lot more than just tessellation.

    Quote Originally Posted by master_of_the_gl View Post
    So in my eyes, making a feature core OpenGL 4.0 that does not require tessellation, makes no sense to me, because ARB_transform_feedback2 has a wide range of usefullnes that could be used on pre tessellation hardware.
    And what about "pre-tessellation hardware" that cannot actually implement transform_feedback2? Your problem is that you believe that this functionality is purely an API change. It is not.

    Yes, binding transform feedback state into an object is purely an API change. But that's not all TF2 provides. It allows you to pause and resume feedback operations. It allows you to render feedback operations without doing a GPU-CPU readback.

    Pausing feedback operations requires that the feedback hardware be able to do that. This means the hardware has to be able to store its current position to some location, then restore that current location later. Rendering feedback operations requires... basically most of the same stuff that ARB_draw_indirect does.

    I don't see why you're so up in arms about things like transform_feedback_2, when there are far more eggregious pieces of functionality that could be implemented on GL 3.3 hardware that aren't core 3.3. Like ARB_separate_shader_objects, most of ARB_enhanced_layouts, ARB_explicit_uniform_locations, ARB_texture_storage, ARB_buffer_storage, and so forth. None of them are specific to hardware versions.

    Quote Originally Posted by master_of_the_gl View Post
    So then, lets say, you know, you have a DirectX 10 compatible GPU. Would you buy a game/application that requires DirectX 11? I suppose you would not. Becuase you want that hardware implemented goodness of functionality.

    How would you say that in OpenGL language?
    I wouldn't specify an OpenGL version. I would specific the specific hardware that I know will work. Like GeForce GT 2xx or better, Radeon HD 3xxx or better, Intel HD 4xxx or better. Not only is that more specific, it's easier for a user to know when they have the right hardware. They don't have to look up a version number; they just look up what their hardware is.

Tags for this Thread

Posting Permissions

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