OpenGL 3 Updates

[Jan]

I really don't bother much about such minor details


What i do bother about VERY MUCH: OpenGL has become a major pain in the ass regarding vertex attributes and i wonder, whether there is anything in the pipeline to remedy this (though i fear, if at all, it will become worse).

Back in "the days", if i wanted to render something, i set a glVertexPointer, glNormalPointer and glTexCoordPointers. In the shaders i simply used the built in variables (gl_Normal, gl_MultiTexCoord*) and it was mostly fine.

Well, glTexCoordPointer is deprecated, and anyway i have int-attributes and other stuff, such that i prefer to use generic vertex attributes.

The problem with these is, i need to query the CURRENT shader, which bind-point a certain attribute is attached to. That actually means, that every time that i change a shader, i would need to reevaluate where to bind my vertex-arrays to. Some shader might not use one of the available attributes, such that some bind points change.

That means there is for every shader/vertex-buffer combination a certain attribute mapping. Sure, i CAN handle this, i can even make this "fast", using VAOs (though they seem to be buggy yet, and not speed up anything) which i store for every such combination.

But only because it's possible, doesn't mean it's not awkward...

What i would really like to do, is simply to tell the API "here is my shader" and "here is a VBO that consists of the attribute arrays 'position', 'texcoord', 'tangent' and 'whatever'" and have the driver sort out any mappings internally. Just instead of "glGetAttibLocation ('bla') glBindAttibute (location, ..)" (at EACH shader switch) i'd rather say ONCE "glBindAttributeByName ('bla', ..)" and have the driver take care for the rest, until i deactivate the array again.


But i fear i have to implement such an abstraction myself someday.

Jan.

[skynet]

Why don't you use your own fixed scheme of (semantic) attribute stream to attribute location? You can enforce this using glBindAttribLocationARB().

[Jan]

Hm, didn't know about that function. Well, it is a start. But if i see this right, i need to have the mapping for all attributes that i will ever use fixed before i link any shader, that uses it. So this one looks like the complete opposite of what i am doing right now. It just replaced one inconvenience with another. I will have to think about this a bit more. But thanks for the info.

Jan.

[Stephen A]

I have created an abstraction that works exactly like Jan's proposal. Since this is C# code, it is possible to use reflection and discover the mapping automatically at runtime, i.e. if the shader has a 'Position' attribute and the VBO has a 'Position' field, they will be bound automatically.

I would very much like to see something like "glBindAttributeByName" in a future OpenGL version. Both current methods (query locations on every shader change or use fixed locations only) are problematic, awkward to use and suboptimal.

[martinsm]

Stephen A: you don't need to query locations on every shader change. Do it only when linking occurs. Vertex attributes change locations only on shader linking.

[Brolingstanz]

Any chance of getting an unofficial preview of what's in store for 3.2?

[Stephen A]

Stephen A: you don't need to query locations on every shader change. Do it only when linking occurs. Vertex attributes change locations only on shader linking.

Never claimed otherwise

I build a map of attributes when each shader is linked, then create (a cached) map of attributes for each VBO. On rendering, I use these maps to bind the correct locations.

If you think about it, this is a roundabout way of binding attributes: The driver knows the attribute names (you can query them) and also knows the attribute indices (you can also query them). Shadowing this information in the aforementioned maps is not optimal; it would be simple to expose a glBindAttributeByName and avoid this overhead, both in code and in memory.

Also note that this trick is all but impossible to pull off in metadata-poor C or even C++. You are more or less forced to use fixed attribute locations, which are a performance minefield.

[skynet]

...and having the driver to do a string-lookup every time you do a glAttribPointer("my_attribute", ...) call is not a performance minefield? And in which way are fixed attribute locations a performance minefield? The only "problem" they provide is that you may have more _possible_ streams than available attribute slots. But this simply boils down to the finding that you don't want to bind them all at once anyway. You can allow some kind of "aliasing", between attributes that are unlikely to be used together, in your own fixed scheme.

Btw, we're getting slightly off-topc ;-)

[Stephen A]

The driver already maintains a hashtable of attribute names <-> locations, so I don't see how this is a performance minefield.

When you force your own, fixed attribute locations, you may be putting the driver out of the fast path. Check out this (under the custom vertex attributes section) and this.

The following quote from the second link is especially damning:

It is possible to assign the same location to multiple attributes. This process is known as aliasing, and is only allowed if just one of the aliased attributes is active in the executable program. HOWEVER the implementation is not required to check for aliasing and is free to employ optimizations that only work in the abscence of aliasing.

That's the definition of a minefield.

[Brolingstanz]

Fortunately for me I only use 1 or maybe 2 vertex formats tops for everything (but then I don't have to deal with anything but my little world).