glVertexAttribIPointer

[Alfonse Reinheart]

Also, it's interesting to follow the etymology of these sorts of things.

glVertexAttribIPointer descends from EXT_gpu_shader4. All of the "contact" listings come from NVIDIA persons, so they either developed almost entirely on their own or had a major part in it.

Generally, NVIDIA doesn't do something API-wise without a good reason. And note that there is no equivalent framebuffer binding method for integer image buffers. Those deduce whether they're for integer buffers from the fragment shader output values alone.

This leads me to suspect that there is, or at least was at the time, a good hardware-based reason for having the user specify this info up-front. That vertex processing hardware of the day needs to know if it's dealing with integers or floats, and fetching this information from the shader object would be slower or otherwise impair performance.

It should be noted that D3D does not require this up-front knowledge however. So if NVIDIA wanted to make this distinction explicit and up-front in the API, they probably had a good reason for it. Especially since they did this again with NV_shader_buffer_shared_memory, which was their own extension.

I can understand why they wanted to make a new function for integer parameters rather than create new type enumerators. I have no idea at all why they made a new function for doubles; that's just dumb.

[Dark Photon]

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?

In the testing I did a few years ago, bindless alone was faster than VAOs + bindless.

(Can't find the threads I posted about this using the search on the new forums to save my life though. Searching for keyword bindless by me reveals only 2 hits.)

And even that case was limited to static VBOs (the best case for VAOs -- you don't need to reload them!). However, have largely flipped to streaming VBOs and there VAOs more an annoyance than anything else. Many little pieces of memory to cause cache misses that you're having to reload. Might as well store the actual 64-bit "handles" in my batch object rather than a 32-bit handle to another memory block containing the 64-bit "handles". The whole point of bindless is to get away from the binding (memory-chasing cache misses), and glBindVertexArray is not bindless.

[Eosie]

I have no idea at all why they made a new function for doubles; that's just dumb.

Simple. glVertexAttribPointer(GL_DOUBLE) converts all doubles into floats at the vertex fetch stage and maps to float shader inputs. glVertexAttribLPointer(GL_DOUBLE) doesn't do any conversion.

[thokra]

Why not simply determine inside the driver if the variable is 64-bit wide? I mean, the index of the attribute is unique and its type is known. This shouldn't be too much of a miracle. Also, there seems to be no error generated when you use the double version to specify data for a floating point vertex attribute.

[Eosie]

I am not sure, but it seems to me the idea was to make vertex shader and vertex attrib states as much independent of each other as possible, so that drivers don't have to look at the vertex shader everytime vertex attribs need to be set up.