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 16

Thread: GLSL: The return to fixed functinoality

  1. #1
    Newbie Newbie
    Join Date
    Jul 2013
    Posts
    3

    GLSL: The return to fixed functinoality

    This seems an obvious question but my google chops seem to be lacking here....

    So with OGL 3 after using a shader you can return to the fixed function pipeline with glUseProgram( 0 ). However with 4 "If program is zero, then the current rendering state refers to an invalid program object and the results of shader execution are undefined." So what is the proper way to return to fixed functionality when you are done with your shader program?

  2. #2
    Senior Member OpenGL Guru
    Join Date
    May 2009
    Posts
    4,948
    The core profile of OpenGL 3.2 and above does not allow a "return to fixed functionality." There is no fixed functionality. It was deprecated in 3.0 and removed in 3.1. The compatibility profile of 3.2 brings it back.

  3. #3
    Senior Member OpenGL Guru Dark Photon's Avatar
    Join Date
    Oct 2004
    Location
    Druidia
    Posts
    3,213
    Yeah, bottom line: you want the compatibility profile if you need the fixed-function pipeline. You get this by default.

  4. #4
    Newbie Newbie
    Join Date
    Jul 2013
    Posts
    3
    Sorry for the explain it like I'm 5. This means that if I create my context *without* setting the FORWARD_COMPATIBLE and CONTEXT_CORE_PROFILE bits that glUseProgram( 0 ) will cause a return to the old fixed functionality pipeline. Correct?

  5. #5
    Senior Member OpenGL Guru
    Join Date
    May 2009
    Posts
    4,948
    First, you shouldn't be using the FORWARD_COMPATIBLE bit at all. Second, if you want a compatibility profile context, you set the CONTEXT_COMPATIBILITY_PROFILE.

  6. #6
    Newbie Newbie
    Join Date
    Jul 2013
    Posts
    3
    Ah. Got it. Ta.

  7. #7
    Junior Member Regular Contributor
    Join Date
    Nov 2012
    Location
    Bremen, Germany
    Posts
    167
    This was something I was wondering about lately: The Forward-comp flag is said to actually REMOVE all Features marked deprecated. Does this mean - in practice and theory - that immediate-draw functionality etc. is masked out, eg. requesting pointers to entry Points will return 0?
    Edit: And shouldn't have the Forward-comp Feature been a context-profile and not a flag? Or are there REALLY plans going on to remove (meaning as above) old Features like glVertex in core-contexts?
    Last edited by hlewin; 07-25-2013 at 12:07 PM. Reason: More qs

  8. #8
    Senior Member OpenGL Guru
    Join Date
    May 2009
    Posts
    4,948
    Quote Originally Posted by hlewin View Post
    This was something I was wondering about lately: The Forward-comp flag is said to actually REMOVE all Features marked deprecated. Does this mean - in practice and theory - that immediate-draw functionality etc. is masked out, eg. requesting pointers to entry Points will return 0?
    You shouldn't be using the forward-compatibility flag at all. It became obsolete when the majority of the deprecated stuff was removed in 3.1.

    Quote Originally Posted by hlewin View Post
    Edit: And shouldn't have the Forward-comp Feature been a context-profile and not a flag? Or are there REALLY plans going on to remove (meaning as above) old Features like glVertex in core-contexts?
    If by "plans," you mean "happened four years ago in OpenGL 3.1", then yes there are "plans" to do that. Perhaps you should read more about profiles on the Wiki.

  9. #9
    Junior Member Regular Contributor
    Join Date
    Nov 2012
    Location
    Bremen, Germany
    Posts
    167
    Hmm - how I understood that:
    compat-profile gives you all functionality PLUS the whole compatibility state variables in shaders, which necessarily get removed in the core-profile.
    So I tend to read the compat-profile as everything written for earlier Version works.
    Core Profile is required to remove cluttering compat-state variables and stuff but is not required to remove entry Points
    whereas Forward-flag should make it impossible to do anything not marked as core.
    This may Sound odd as one would Need the compat-state variables in shaders to retrieve data send by glVertex but I remember to have read attribute-indices to be used internally by the gl-implementations. But I must say I'm not sure about that source stating that those were actully useable without them being bound to eg gl_Vertex.
    And reading this all again my Interpretation seems a lot less plausible to myself then when the idea formed in my head. Right now I'm a Little too tired for reading technically heavy stuff. I'll have a look at the specs etc. sometime else

  10. #10
    Junior Member Regular Contributor
    Join Date
    Nov 2012
    Location
    Bremen, Germany
    Posts
    167
    The figure
    <--B--------------C---------------F--->
    C is the moving Point of the actual core-profile for any Point on the line.
    B is the backward-compatible context Profile.
    F is the Forward-bit in which the core Profile is moving spec by spec.
    What does this mean apart from technical Details?
    That means: If you know, you aren't up to date, set a B means compat-context.
    If you want to get the finger layed on things that aren't up to date anymore, set F.
    If you make your final release, just set C - it is the core.

    So far ideally - do not ask me how this should be realized. The best thing would be to impose the Need to (somehow) include the Information, which GL-core Version the application was built against.
    That's my bid: CreateContext without Version number out of the core!
    Except of course CreateContext already tags the application binary
    Last edited by hlewin; 07-25-2013 at 03:32 PM. Reason: one step ahead

Posting Permissions

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