glVertexAttribIPointer

[Dark Photon]

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).

  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.

[Dark Photon]

Ditto glVertexAttribIFormatNV()

[kyle_]

Minor point in case we ever refactor the API at some point.

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).

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).

[aqnuep]

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.

[Ilian Dinev]

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.

[Eosie]

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.

[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.

[Dark Photon]

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.

[Ilian Dinev]

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)

[Alfonse Reinheart]

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?