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 5 123 ... LastLast
Results 1 to 10 of 50

Thread: Longs Peak Program Objects

  1. #1
    Intern Contributor
    Join Date
    Jun 2006
    Posts
    97

    Longs Peak Program Objects

    From the newsletter:
    In OpenGL 2.1 only one program object can be in use (bound) for rendering. If the application wants to replace both the vertex and fragment stage of the rendering pipeline with its own shaders, it needs to incorporate all shaders in that single program object. This is a fine model when there are only two programmable stages, but it starts to break down when the number of programmable stages increases because the number of possible combinations of stages, and therefore the number of program objects, increases. In OpenGL Longs Peak it will be possible to bind multiple program objects to be used for rendering. Each program object can contain only the shaders that make up a single programmable stage; either the vertex, geometry or fragment stage. However, it is still possible to create a program object that contains the shaders for more than one programmable stage.
    Anyone care to expand or speculate on these ideas?

    I'm thinking "set of compiled shaders that can be quickly linked at runtime", but then things get a bit fuzzy

    Cheers

  2. #2
    Senior Member OpenGL Guru
    Join Date
    Mar 2001
    Posts
    3,576

    Re: Longs Peak Program Objects

    Anyone care to expand or speculate on these ideas?
    No need for speculation.

    All it's saying is that you can have fully linked programs that don't have to include all of the stages that you intend to use. So you can have a vertex program and a fragment program, both compiled and linked, and then you decide to use both when rendering something.

    Before, you would have had to create a combined vertex&fragment program, one program that contains both stages. Now, you don't.

  3. #3
    Intern Contributor
    Join Date
    Jun 2006
    Posts
    97

    Re: Longs Peak Program Objects

    So we'd have something like this:

    Code :
    ...
    glUseProgram(vsSet);
    glUseProgram(gsSet);
    glUseProgram(fsSet);
    ...
    SpecifyWhichShadersToApply();
    DrawLotsOfStuffUsingThisSet();
    Each of the shader sets is considered to be a valid program in its own right, in this model (total program validation presumably deferred to the next draw command). Am I right?

    Where I get fuzzy is in how one would specify the particular {vs,gs,ps} from the active set that is intended for use, and how this selection might interact with uniform (block) updates.

    I realize it's a bit early for specific details, but I just can't resist asking

    Thanks,
    Cheers

  4. #4
    Senior Member OpenGL Pro k_szczech's Avatar
    Join Date
    Feb 2006
    Location
    Poland
    Posts
    1,107

    Re: Longs Peak Program Objects

    Right now we link multiple fragment, geometry and vertex shaders into one program that gets executed - so more than one type of shaders creates a program.
    From now on you will link multiple fragment shaders into one fragment program, multiple vertex shaders into one vertex program - so only one type of shader can be linked together into one program.
    You will not link fragment and vertex shaders into one program.
    You can then enable/disable single fragment/vertex/geometry program separately.


    The API is different thing. Note that
    Code :
    glUseProgram( vp );
    is OK, because we know vp is a set of vertex shaders linked into one vetex program (they're allready linked).
    But this:
    Code :
    glUseProgram( 0 );
    Is no longer valid, because is tells to unbind (bind default) program, but does not tell which stage it reffers to (fragment? geometry?)
    Something like this would be OK:
    Code :
    glUseProgram(GL_DEFAULT_FRAGMENT_PROGRAM);
    That GL_DEFAULT_FRAGMENT_PROGRAM would be defined as external variable being a program object. So unbinding proagam is actually binding default program of that type.
    Perhaps instead we would have glUnbindProgram( vp ) or glUnbindProgram(GL_VERTEX_PROGRAM) - It doesn't mak much difference to me.

    I have no clue how new API will look, but I think the idea (not the API) will be more less what I described.

    Again - don't consider this to be a confirmed fact - it's just how I understand it.

  5. #5
    Junior Member Regular Contributor
    Join Date
    Aug 2006
    Posts
    231

    Re: Longs Peak Program Objects

    The way I understand it is that a program object may contain 1 of each of the shader types (vertex, geometry, fragment). You can then do the following:
    Code :
    glUseProgram(programWithOnlyAVertexShader);
    glUseProgram(programWithOnlyAFragmentShader);
    And it'll work just as if the vertex and fragment shader were in the same program.

    You could also do the following:
    Code :
    glUseProgram(programWithAVertexAndFragmentShader);
    //..draw stuff
    glUseProgram(programWithOnlyAGeometryShader);
    //..draw more stuff
    The first draw would just use the vertex and fragment program, and the second draw would use all 3.

    The bit I'm not sure on is if 2 currently bound programs have matching shader types. I assume the last one to be bound is the one that will be used. E.g.
    Code :
    glUseProgram(programWithAVertexAndFragmentShader);
    glUseProgram(programWithOnlyAFragmentShader);
    In this example it would use the vertex shader from the first program, and the fragment shader from the second program.

    Of course they'd probably change the semantics to bind/unbind, e.g.

    Code :
    glBindProgram();
    glUnbindProgram();
    Regards
    elFarto

  6. #6
    Senior Member OpenGL Pro
    Join Date
    May 2000
    Location
    Naarn, Austria
    Posts
    1,102

    Re: Longs Peak Program Objects

    I don't think there will be a default program.

    The bit I'm not sure on is if 2 currently bound programs have matching shader types.
    I think that won't be allowed. It's a bit fuzzy on that point, but as I read it, you have two choices:

    - link everything into a single program and use this
    - link only shaders of the same stage into a program, and combine multiple programs

  7. #7
    Senior Member OpenGL Pro Zengar's Avatar
    Join Date
    Sep 2001
    Location
    Germany
    Posts
    1,932

    Re: Longs Peak Program Objects

    IMHO:
    I think you can bind multiple programs, but only one 'main()' function for a shader of each type will be allowed. So it's pretty much like current approach, just imagine only that the bound programs will be linked automatically.

  8. #8
    Senior Member OpenGL Pro k_szczech's Avatar
    Join Date
    Feb 2006
    Location
    Poland
    Posts
    1,107

    Re: Longs Peak Program Objects

    I don't think there will be a default program.
    Yes, you're right. I think semantics "unbind" and "bind default" are equivalent when comes to most of implementations, but from the API's point of view fixed functionality still exists. There will be probably something like: glUnbind( <program_type> ).

  9. #9
    Senior Member OpenGL Pro k_szczech's Avatar
    Join Date
    Feb 2006
    Location
    Poland
    Posts
    1,107

    Re: Longs Peak Program Objects

    I think you can bind multiple programs, but only one 'main()' function (...) linked automatically
    You can implement it allready - if you want to use a set of shaders you can create temporary program, attach, link and destroy program after you're done using it. I wouldn't say that doing it multiple times every frame is performance-wise.
    It's better to prepare such 'sets' of shaders we intend to use on init and pre-link them and that leads us back to idea of programs.

    The only difference now is that program object is not for all stages but just for one stage. You can attach them freely with no performance loss as vertex shader does not have to be linked with fragment shader. It never had to.

  10. #10
    Senior Member OpenGL Pro
    Join Date
    May 2000
    Location
    Naarn, Austria
    Posts
    1,102

    Re: Longs Peak Program Objects

    but from the API's point of view fixed functionality still exists
    Are you sure? I don't think so

Posting Permissions

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