cancel
Showing results for 
Search instead for 
Did you mean: 

Archives Discussions

cryph
Journeyman III

glVertexAttrib?f ignored on AMD?

I have observed the following in OpenGL programs I have been writing for OpenGL 4.2 using core, forward-compatible profiles and running on AMD. Suppose, for example, I have a large number of vertices for a triangle strip, all of which are in the same plane, I want to specify the plane normal once and render as:

glDisableVertexAttribArray(normalVectorIndex);

glVertexAttrib3f(normalVectorIndex, fixedNormalDx, fixedNormalDy, fixedNormalDz);

glDrawArrays(GL_TRIANGLE_STRIP, 0, numPoints);

When I do this on NVIDIA machines, I get exactly the results I expect.  However when I run the same code on AMD platforms, the glVertexAttrib3f call seems to have no effect. (And of course this is true for all variations glVertexAttrib3fv, etc.) I have re-read the OpenGL Specification that describes glVertexAttrib, and I am convinced I am using it correctly. Is this a known problem with AMD drivers?

0 Likes
1 Solution
gsellers
Staff

Hi,

Sorry for the delay. We have been investigating and as far as we can tell, this is related to using the vertex attribute at location zero as a static attribute. We'll try to get a fix into an upcoming driver. In the meantime, you can try a couple of workarounds:

1) Explicitly ensure that you don't use attribute zero by setting the vertex attribute locations with glBindAttribLocation before the program is linked.

2) Set the locations of any attributes that might be static to non-zero in the shader by using a layout (location = n) qualifier on the input declaration.

Even if you only have one attribute, you can still bind it to a non-zero location (leaving location zero unused). If our root cause is correct, either of these should resolve your issue. If you still see the problem after applying these workarounds, let us know and we'll dig deeper.

Cheers,

Graham

View solution in original post

0 Likes
3 Replies
gsellers
Staff

Hi,

Sorry for the delay. We have been investigating and as far as we can tell, this is related to using the vertex attribute at location zero as a static attribute. We'll try to get a fix into an upcoming driver. In the meantime, you can try a couple of workarounds:

1) Explicitly ensure that you don't use attribute zero by setting the vertex attribute locations with glBindAttribLocation before the program is linked.

2) Set the locations of any attributes that might be static to non-zero in the shader by using a layout (location = n) qualifier on the input declaration.

Even if you only have one attribute, you can still bind it to a non-zero location (leaving location zero unused). If our root cause is correct, either of these should resolve your issue. If you still see the problem after applying these workarounds, let us know and we'll dig deeper.

Cheers,

Graham

0 Likes
cryph
Journeyman III

That seems to be exactly the problem. I used the layout and everything seems to work as expected.  Thanks for getting back to me with this fix. I really appreciate being able to get away from this bug!

Jim

0 Likes
crjin
Staff

In amd driver, if developers do not specify the layout location through either glBindAttribLocation() or write "layout (location=index)" in shader source, driver will default set color attribute location to zero, vertex attribute location to one (for example it is a simple application). And spec mentioned that "Vertex2*, Vertex3*, are Vertex4* commands are completely equivalent to the corresponding VertexAttrib* command with an index of zero".

Hence, if developers want to assume color attribute value (index is 0) using glVertexAttrib*(), the function will cannot be worked.


So it is better to check attributes location or specify layout location before assuming value using glVertexAttrib*().


Best wishes!

Crystal

0 Likes