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 15

Thread: glVertexAttribIPointer

  1. #1
    Senior Member OpenGL Guru Dark Photon's Avatar
    Join Date
    Oct 2004
    Location
    Druidia
    Posts
    4,480

    glVertexAttribIPointer

    Minor point in case we ever refactor the API at some point. glVertexAttribIPointer is a bit of a wart in that if you have generic batch launch code (vtx attrib binds, etc.) you have to use a separate API for this, which doesn't even have the same signature, so you're more likely to eat the cost of an "if" per vtx attrib to select the right API (potential branch prediction miss).

    Code :
      if ( integer )
        glVertexAttribIPointer( index, size, type, stride, ptr );
      else
        glVertexAttribPointer (index, size, type, normalized, stride, ptr );

    Would have been better had this been handled like the normalized flag (i.e. added as a flag on a new API call): ignored if your input type isn't a fixed-point value, but used if it is. Then you could just call one API regardless. Alternatively, handle this internally based on the shader input type (e.g. uvec4 vs. vec4) and not even have an arg.

    A middle ground solution isn't as pretty -- wrap AttribIPointer with an function that has the same signature as AttribPointer and then select from a 2-element array based on an integer flag. Avoids the if, but imposes another layer of function call on IPointer.

  2. #2
    Senior Member OpenGL Guru Dark Photon's Avatar
    Join Date
    Oct 2004
    Location
    Druidia
    Posts
    4,480
    Ditto glVertexAttribIFormatNV()

  3. #3
    Member Regular Contributor
    Join Date
    Apr 2009
    Posts
    268
    Quote Originally Posted by Dark Photon View Post
    Minor point in case we ever refactor the API at some point.


    Quote Originally Posted by Dark Photon View Post
    Would have been better had this been handled like the normalized flag
    Useless parameters arent exactly pretty either (though there is some precedent in GL with this).

    Quote Originally Posted by Dark Photon View Post
    Alternatively, handle this internally based on the shader input type (e.g. uvec4 vs. vec4) and not even have an arg.
    That would be a very good solution api wise, imo.
    The problem is, it would be discarding HW feature of conversion int -> float (w/o normalization).

    This could of course be culled into single function that says what is needed explicitly, without O(n) boolean parameters - let specify target format in the function as well with tokens encoding conversion, say NORMALIZED_FLOAT, or whatever.

    Or do like DX does and allow for UNORM/SNORM 'type' (at least thats my understanding as to how it works there).

  4. #4
    Advanced Member Frequent Contributor
    Join Date
    Dec 2007
    Location
    Hungary
    Posts
    989
    Quote Originally Posted by Dark Photon View Post
    Minor point in case we ever refactor the API at some point. glVertexAttribIPointer is a bit of a wart in that if you have generic batch launch code (vtx attrib binds, etc.) you have to use a separate API for this, which doesn't even have the same signature, so you're more likely to eat the cost of an "if" per vtx attrib to select the right API (potential branch prediction miss).
    Well, you forgot that even if you don't have to do the branching to choose between the two cases, the driver will eventually have (besides dozens of other conditionals). I don't say it's nice that we have separate VertexAttribPointer, VertexAttribIPointer and VertexAttribLPointer, but justifying it's rewriting because of the potential overhead of an "if" statement is, hmm, rather optimistic. The driver has orders of magnitude more work when any of these functions get called so eliminating that "if" won't really help (even assuming that it won't result in another "if" in the driver).

    Though, point taken, it's not nice that we have three versions of these functions. Actually, if VertexAttribPointer would have been designed in the first place in a way to handle integer and double attributes properly, the other entry points wouldn't even be necessary.
    Disclaimer: This is my personal profile. Whatever I write here is my personal opinion and none of my statements or speculations are anyhow related to my employer and as such should not be treated as accurate or valid and in no case should those be considered to represent the opinions of my employer.
    Technical Blog: http://www.rastergrid.com/blog/

  5. #5
    Senior Member OpenGL Pro Ilian Dinev's Avatar
    Join Date
    Jan 2008
    Location
    Watford, UK
    Posts
    1,294
    VAO should generally make this a moot point.
    Other than this, like agnuep mentioned, drivers will generally have lots of more branching than this single "if", so a minor optimization like this on user frontend can't improve performance.

  6. #6
    Junior Member Regular Contributor
    Join Date
    Jan 2004
    Location
    Czech Republic, EU
    Posts
    190
    Considering that drivers must check whether every GLenum parameter is legal, sometimes using pretty long switch statements, I wouldn't bother about the performance of one "if". The advice is... just use VAOs.
    (usually just hobbyist) OpenGL driver developer

  7. #7
    Senior Member OpenGL Guru Dark Photon's Avatar
    Join Date
    Oct 2004
    Location
    Druidia
    Posts
    4,480
    Quote Originally Posted by kyle_ View Post
    Quote Originally Posted by Dark Photon
    Alternatively, handle this internally based on the shader input type (e.g. uvec4 vs. vec4) and not even have an arg.
    That would be a very good solution api wise, imo.
    The problem is, it would be discarding HW feature of conversion int -> float (w/o normalization).
    I don't think so. Let me clarify. The idea would be that the convert-to-float Y/N behavior (currently selected by calling Pointer vs. IPointer) would be driven completely by whether the shader input attribute was declared float or not. For instance, float/vec2/... -> YES. uint/uint2/... -> NO.

    For the float input attribute case, you'd still have the "normalized" flag which would tell the driver/GPU whether to do the fixed-point normalize or not when converting to float (e.g. ubyte 0..255 -> 0..1). For the integer input attribute case, the "normalized" flag would be ignored.

    This could of course be culled into single function that says what is needed explicitly, without O(n) boolean parameters - let specify target format in the function as well with tokens encoding conversion, say NORMALIZED_FLOAT, or whatever.
    Could. Just seems to me it doesn't make sense to (for instance) pass uint bits into a float var or float bits into a uint var, so why not make the -convert-to-float operation automatic depending on input type.

  8. #8
    Senior Member OpenGL Guru Dark Photon's Avatar
    Join Date
    Oct 2004
    Location
    Druidia
    Posts
    4,480
    Quote Originally Posted by Ilian Dinev View Post
    VAO should generally make this a moot point.
    Other than this, like agnuep mentioned, drivers will generally have lots of more branching than this single "if", so a minor optimization like this on user frontend can't improve performance.
    Probably true. Can't do much about that besides lazy-state setting. Just trying to keep the app code driving it clean and lean. And re VAOs, I get more bang for the buck with bindless and streaming VBOs.

  9. #9
    Senior Member OpenGL Pro Ilian Dinev's Avatar
    Join Date
    Jan 2008
    Location
    Watford, UK
    Posts
    1,294
    Yeah, VAO is strangely not the best performer on important implementations, even after so many years of having it as a must-use object in core >_< . (though vs bindless it's somewhat understandable)

  10. #10
    Senior Member OpenGL Lord
    Join Date
    May 2009
    Posts
    6,031
    Bindless state (the stuff set by glVertexAttrib*FormatNV) is also VAO state. So there's nothing preventing you from using both.

    Do VAOs make bindless significantly slower?

Posting Permissions

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