a loop through active attributes and requesting slots with GetAttribLocationARB I get following result:
aNormal is mapped to attribute slot 1, aPosition to attribute slot 2 and aPosition to attribute slot 3.
No other generic or conventional attributes where used in the shader and nothing is rendered because slot 0 is missing.
Can somebody confirm this? On nvidia hardware I didn’t had this problem.
If gl_Vertex isn’t used generic attribute 0 represents the vertex. But how would the driver know which of your attribute names that you declared you intend to be the vertex? So it can’t assign any of them to zero. You’ll have to do that yourself with glBindAttribLocation(). This only matters if you’re using immediate mode though.
Originally posted by Relic: [quote] This only matters if you’re using immediate mode though.
This always matters.[/QUOTE]Mhh, after Humus’s post and rereading the ARB spec I started to believe it only matters for immediate mode. Either I haven’t found the important section or the spec seem to be a little inaccurate if it applies to vertex arrays or not. I’ve only found issue 11 in ARB_vertex_shader but after that issue it sounds more like it only matters for immediate mode. I mean why/how should a vertex end be signaled with vertex arrays?
But regarding the ati driver bug it seem as if at least the ati driver needs attrib 0 for rendering with vertex arrays but doesn’t bind it.
Originally posted by Humus: If gl_Vertex isn’t used generic attribute 0 represents the vertex. But how would the driver know which of your attribute names that you declared you intend to be the vertex? So it can’t assign any of them to zero. You’ll have to do that yourself with glBindAttribLocation(). This only matters if you’re using immediate mode though.
But for immediate mode I still think the driver should bind any attribute to slot 0. With a data/shader driven architecture you don’t want to rebind attributes and you don’t care which information is bound to attribute 0. You ask for attributes and their slots and then set the attribute data you have, with attribute 0 at last to trigger the rendering. So no problem here if the driver pick a random attribute as attribute 0.
And either way there seem to be a driver bug:
conventional attrib only + vbo = working
conventional attrib only + normal vertex array = working
generic attrib only + vbo = nothing rendered and that very slow
generic attrib only + va = nothing rendered but fast
mixed conventional+generic without attrib0 and gl_Vertex + vbo = nothing rendered and that very slow
mixed conventional+generic without attrib0 and gl_Vertex + normal vertex array = nothing rendered but fast
mixed conventional+generic with gl_Vertex + vbo = working
mixed conventional+generic with gl_Vertex + normal vertex array = working
btw: Didn’t tested the conventional attributes on nvidia hw because of the bug that they are not listed as active attributes but the cases with all generic va + vbo work without problems. So I guess this time it’s a ati driver bug :rolleyes:
Does anyone know when we can expect decent, production quality glsl driver support from ATI and nvidia? I mean beta support already last very long, and till know using glsl is still a pain in the ass. Both on ATI and nvidia hw. My initial suspicions for bugs already shifted from own code to driver bugs
Regarding the attribute 0 thing:
This attribute is the special one which invokes the vertex shader.
It does matter that you bind it to a vertex attribute in your vertex shader or you won’t render anything with any method of rendering.
Agreed, the order in which attrbute values are sent to the GL matters in immediate mode because the attribute 0 needs to be the last one in the commands to fetch the other’s values from the current state.
In vertex arrays GL sorts that “order” out for itself, but still attribute 0 unbound renders nothing.
But as the GL does not know at generic bind time what you’re going to use as API it shouldn’t assign arbitrary attributes to the 0th index because that would be implementation dependent behaviour and people would wonder why their application doesn’t run on other implementations or versions of the same.
Originally posted by Relic:
But as the GL does not know at generic bind time what you’re going to use as API it shouldn’t assign arbitrary attributes to the 0th index because that would be implementation dependent behaviour and people would wonder why their application doesn’t run on other implementations or versions of the same.
I disagree with that. In immediate mode you have an application dependent behaviour anyway. What is the purpose of automatic driver binding if it’s not fully usable with vertex arrays, without providing advantages for the immediate mode by this defect?
You have two use cases:
application driven: load shader, bind your parameters as you like, build and provide data.
data driven: load shader, build, ask for parameters, provide data for parameters. Ok, for immediate mode you have to be carefull to set attribute data for attribute 0 as last, or rebind attributes to match your settings. But at least rebinding you also need if nothing is assigned to attrib 0. So no disadvantage with random binding attrib 0 for immediate mode.
With random binding to attrib 0 you can use vertex arrays without any further thinking. Without you have to rebind by hand which is imo a great disadvantage and makes the whole idea of automatic driver binding absurd.
btw: this seem to be in unresolved issue in the ARB Spec, isn’t it? Should attribute 0 be automatically bound by the driver, or not. Haven’t found that explicitly mentioned anywhere in the spec. But I think because attrib 0 is needed and binding should be automatic (!!!) it would be reasonable to force the drive to bind something to attrib 0.
Also, it isn’t like it’s hard for the driver to do the binding. It has the vertex shader; it knows whether there is an explicit position or not. And if there is not, it should bind one of the generic attributes to attribute 0. It’s really simple, and it works.
The only problem is that immediate mode rendering requires that the user know, at compile time, which one is attribute 0. So, the API forces the user to specify one of them to be attribute 0. Looks like another case of immediate mode holding the API back.
And people say that OpenGL doesn’t need a revision :rolleyes:
Originally posted by Korval:
[b]
The only problem is that immediate mode rendering requires that the user know, at compile time, which one is attribute 0. So, the API forces the user to specify one of them to be attribute 0. Looks like another case of immediate mode holding the API back.
And people say that OpenGL doesn’t need a revision :rolleyes: [/b]
who actually uses immediate mode? This is an inherent issue of immediate mode. If you describe a vertex by sequential calls, one call has to signal the completion of a vertex. To bind nothing to attrib 0 doesn’t change anything about this issue but only break the reasonable use of automatic binding with vertex arrays.
If you want to use immediate mode you have to pay the prize in elegance and performance. I wonder what you want to change about that with a revision, nowadays you don’t use immediate mode but batch, batch, batch The only way to solve this is probably to remove the immediate mode, but for what benefit?
I don’t see a problem in demanding a binding to attribute 0, the problem is that the ATI driver doesn’t do this automatically, which I would regard as a driver bug.
To bind nothing to attrib 0 doesn’t change anything about this issue but only break the reasonable use of automatic binding with vertex arrays.
I don’t think you quite understand. There is a collision of two things going on here:
Vertex arrays don’t render anything unless glVertex/attribute 0 is bound.
The shader will not automatically bind anything to attribute 0 because immediate mode has a compile-time dependency on which attribute is attribute 0. As such, it requires that the user bind something to attribute 0 manually.
Because of the limitations of supporting immediate mode (no auto binding of attribute 0), we have to add code to manually bind to attribute 0. Plus, because of that, I don’t think we can use all 16 generic attributes. I think this means that we only get 15 generics.
I wonder what you want to change about that with a revision,
Among other things, removing immediate mode (or, at least, force the user to specify all valid attributes for each vertex) and getting rid of the silly need for this attribute 0/glVertex nonsense entirely. The thing is, if I don’t use generics, and I don’t use glVertex (I compute it in some way something else, for example), then I don’t get rendering, even though the vertex shader is perfectly valid.
I don’t see a problem in demanding a binding to attribute 0, the problem is that the ATI driver doesn’t do this automatically, which I would regard as a driver bug.
It’s entirely possible that this is an unintended driver bug. It still makes immediate mode harder to use (and immediate mode is for rapid prototyping and so forth, so it shouldn’t be hard to use).
Mhh, I think I understood it, but I see there no real problem. Not such a big problem which would justify to remove/change immediate mode (IM) and break backward compatibility.
The shader will not automatically bind anything to attribute 0 because immediate mode has a compile-time dependency on which attribute is attribute 0. As such, it requires that the user bind something to attribute 0 manually.
But the driver should bind something to attribute 0, because the issue is an issue of the IM, not of automatic attribute binding.
For the IM automatic binding is of no real use anyway because of the compile-time depency. So automatic binding is only usefull for vertex arrays and therefore the driver should bind something to attribute 0. This makes no difference for immediate mode but a huge difference for vertex arrays.
[b]
[quote]I wonder what you want to change about that with a revision,
Among other things, removing immediate mode (or, at least, force the user to specify all valid attributes for each vertex) and getting rid of the silly need for this attribute 0/glVertex nonsense entirely. The thing is, if I don’t use generics, and I don’t use glVertex (I compute it in some way something else, for example), then I don’t get rendering, even though the vertex shader is perfectly valid.
[/b]
[/QUOTE]Ok, this is the only place where the attribute 0 thingy has a problem. But why not using generics? I think in the near future with standard use of glsl generics will be more used than conventional attributes or uniforms.
The application design will shift to data driven designs and there you don’t want to have built in states but only parameter specs and data bindings to this parameters.
I can live with the demand of a binding to attribute 0, but therefore the driver should bind something to it automatically. If you want to use outdated features like IM or conventional parameters you have to live with the restrictions Imo this don’t justify to break backward compability.
[b]
[quote] I don’t see a problem in demanding a binding to attribute 0, the problem is that the ATI driver doesn’t do this automatically, which I would regard as a driver bug.
It’s entirely possible that this is an unintended driver bug. It still makes immediate mode harder to use (and immediate mode is for rapid prototyping and so forth, so it shouldn’t be hard to use).[/b][/QUOTE]What is made harder for the immediate mode (IM)? Because of the compile-time dependency you have to rebind your attribute 0 anyway. And it doesn’t really make a difference if something was bound to attribute 0 before rebinding it or not.
The only way to solve this is probably to remove the immediate mode, but for what benefit?
Imo this don’t justify to break backward compability.