I'm getting some really strange behavior when using attributes of the GL_INT_2_10_10_10_REV format in my OpenGL application. It could be related to this issue. I'm testing this on a Radeon R7, running the 21.5.2 driver on Windows 10. I believe it's a new bug, because it broke the application I was working on after I updated my drivers.
The bug is triggered by using the GL_INT_2_10_10_10_REV format for a vertex attribute and using just the xyz-components of that attribute — either by declaring it as a vec3, or by declaring it as a vec4 and then extracting the xyz parts explicitly. The bug causes other, unrelated vertex shader outputs to become corrupted.
I've got a small program that reproduces the bug (download here). It's a stand-alone .exe with 223-line C++ source included. (Requires a C++11 compiler, SDL2, and GLEW to build.) The program renders the classic three-color OpenGL test triangle. The triangle vertices have position and color attributes, which are set up like so:
glVertexAttribPointer(0, 4, GL_INT_2_10_10_10_REV, GL_TRUE, 8, (void*) 0); // Position.
glVertexAttribPointer(1, 4, GL_UNSIGNED_BYTE, GL_TRUE, 8, (void*) 4); // Color.The triangle is rendered twice, first with a shader that assigns the position directly to gl_Position, like so:
layout(location=0) in vec4 aPosition;
layout(location=1) in vec4 aColor;
out vec4 vColor;
void main()
{
gl_Position = aPosition;
vColor = aColor;
}The second triangle is rendered with an otherwise identical shader that uses only the xyz parts of the position attribute, setting w to 1:
gl_Position = vec4(aPosition.xyz, 1.0);The input vertices all have a w-coordinate of 1, so the behavior of the two shaders should be identical. The actual behavior, on my machine, is that the first triangle renders correctly, but the second triangle is completely red:
Running the program in RenderDoc, I get a black triangle instead:
From RenderDoc's mesh viewer I can tell that the input vertex data looks okay, but in the vertex shader output for the second triangle, the colors are all zero!
I would guess it's some general bug involving the way GL_INT_2_10_10_10_REV attributes are fetched or decoded; this is just the simplest way I've found to reliably trigger it.
My workaround for now is to always declare attributes of that type as vec4, and to forgo any swizzling or conversion to vec3 in the vertex shader. I would really like to see this fixed though — if nothing else so that nobody else has to be tripped up by this.
