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 17

Thread: Primitive Restart with a twist

  1. #1
    Advanced Member Frequent Contributor
    Join Date
    Apr 2009
    Posts
    600

    Primitive Restart with a twist

    As of OpenGL 3.x, primitive restart was added where when enabled if a particular user defined index was encountered, then the primitive creation was restarted (the biggest use case being triangle strips). I would like to make augment it as follows:


    Primitive Restart Index 2 is enabled/disabled GL_PRIMITIVE_RESTART_INDEX_SOME_NICE_NAME when passed to glEnable/glDisable.
    When enabled, any one of the draw commands which transfers a set of generic attribute array elements to the GL the following will occur when index of the vertex is equal to the primitive restart index
    • will restart the primitive
    • the index following is NOT an index for an attribute. Rather it specifies the value gl_SomeGoodSoundingName used by any of the shading stages


    The initial value of
    gl_SomeGoodSoundingName is 0 at the start of each draw command. For instancing, the value if reset to zero at the start of each instance.

    The idea behind this is that there are a number of cases where an attribute is used as an index into an array. Very often, that index does not change a great deal. With this extension, one does not need to occupy an entire attribute for that index.

  2. #2
    Senior Member OpenGL Guru
    Join Date
    May 2009
    Posts
    4,948
    Is there some reason we need a new enable for this? The only thing it changes is a variable that doesn't currently exist, so I don't see why it couldn't just use the current restart enable. Old code won't use a non-existent variable.

    I don't see why it couldn't just piggy back off of regular restarting.

  3. #3
    Advanced Member Frequent Contributor
    Join Date
    Apr 2009
    Posts
    600
    It is a new feature, so only new code would use it The idea is for the following shader code:

    Code :
     
    MyType MyArray[N];
    /* also applies to samplerBuffer with texelFetch, UBO's, etc */
     
    .
    .
    .
    MyType node_value;
    node_value=MyArray[gl_SomeNiceName];

    Currently one needs to do this:
    Code :
     
    MyType MyArray[N];
    in int MyIndex;
    /* also applies to samplerBuffer with texelFetch, UBO's, etc */
     
    .
    .
    .
    MyType node_value;
    node_value=MyArray[MyIndex];

    The idea behind this is that for many vertices, the value of MyIndex is the same.



    I don't see why it couldn't just piggy back off of regular restarting.
    Exactly how would one piggy back this onto current primitive restarting?

  4. #4
    Senior Member OpenGL Guru
    Join Date
    May 2009
    Posts
    4,948
    You misunderstand.

    I'm arguing with the need for a special enum for the functionality, not the functionality itself. I'm saying that it should always be active when restarting, and if the hardware has to do something special based on whether you're going to use the count, it could just as easily check the vertex shader to see if you're using that value.

  5. #5
    Advanced Member Frequent Contributor
    Join Date
    Apr 2009
    Posts
    600
    Quote Originally Posted by Alfonse Reinheart View Post
    You misunderstand.

    I'm arguing with the need for a special enum for the functionality, not the functionality itself. I'm saying that it should always be active when restarting, and if the hardware has to do something special based on whether you're going to use the count, it could just as easily check the vertex shader to see if you're using that value.
    I don't see how to make the interface work with piggybacking it onto the existing primitive restart, because it changes the meaning of an index stream. The current primitive restart implies that the next index specifies a vertex. The jazz I am advocating has the next index does not specify a vertex but specifies a value used by any of the shader stages... at the very least, what I am advocating changes the interpretation of an index stream compared to the current primitive restart... but to spell it out...

    Lets say the primitive restart index is P. Lets say the index stream is given by say as {0,3,4,P,5,6,8,12}

    Current primitive restart then produces the index stream groups G0={0,3,4}, G1={5,6,8,12}

    What I am advocating produces the index stream groups G0={0,3,4}, G1={6,8,12}
    with gl_SomeNiceName begin 0 for those primitives from G0 and having value 5 for those of G1

  6. #6
    Senior Member OpenGL Guru
    Join Date
    May 2009
    Posts
    4,948
    If you want to provide the shader a value after the restart index, you should (for the sake of symmetry) make the first index such a value, so that the user can set this value as normal.

    More to the point, why do you need to do it this way? It would make far more sense if you just bumped an index after each restart, then let the vertex shader do whatever it needs to do to fetch the value of interest.

    After all, what will people do with the value? It's an integer, so it would probably be used to fetch data from some buffer in the VS, right? So why put it in the index list, when you can just make it an implicit counter? Why do users need to be able to set the value?

  7. #7
    Member Regular Contributor malexander's Avatar
    Join Date
    Aug 2009
    Location
    Ontario
    Posts
    328
    More to the point, why do you need to do it this way? It would make far more sense if you just bumped an index after each restart, then let the vertex shader do whatever it needs to do to fetch the value of interest.
    This would effectively make this suggestion, "make gl_PrimitiveID accessible in the vertex shader", which means that the vertex shader would not be able to cache vertices, and instead run on every vertex element.

    I did a test a while back with a 72K point, 288K vertex model with per-face attributes. I compared the performance of promoting the 72K points and 77K per-face attributes to 288K-element vertex arrays via duplication and drew them with glDrawArrays, vs. 72K points drawn with glDrawElements() w/288K elements and a geometry shader to lookup the 77K per-face attributes via gl_PrimitiveID. The performance was roughly the same, though the memory use was a bit lower in the second case (tested on a Nvidia GEForce 670). So this would be more of a convenience or memory saving feature, than a performance improvement.

  8. #8
    Senior Member OpenGL Guru
    Join Date
    May 2009
    Posts
    4,948
    This would effectively make this suggestion, "make gl_PrimitiveID accessible in the vertex shader", which means that the vertex shader would not be able to cache vertices, and instead run on every vertex element.
    How not? Part of the per-vertex input would be the restart count. Thus, changing the restart count changes the input values, and thus you have a different vertex. Between restarts, the vertices could be cached.

    Also, the original suggestion would have this same issue, since you're changing a per-vertex input based on an index value.

  9. #9
    Senior Member OpenGL Guru
    Join Date
    May 2009
    Posts
    4,948
    This would effectively make this suggestion, "make gl_PrimitiveID accessible in the vertex shader", which means that the vertex shader would not be able to cache vertices, and instead run on every vertex element.
    How not? Part of the per-vertex input would be the restart count. Thus, changing the restart count changes the input values, and thus you have a different vertex. Between restarts, the vertices could be cached.

    Also, the original suggestion would have this same issue, since you're changing a per-vertex input based on an index value.

  10. #10
    Member Regular Contributor malexander's Avatar
    Join Date
    Aug 2009
    Location
    Ontario
    Posts
    328
    I wasn't rebutting, just making the point that this can be done now using a geometry shader with similar performance characteristics. This suggestion just becomes a convenience.

Posting Permissions

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