openglintelnvidiaopengl-3vertex-array

VAO and element array buffer state


I was recently writing some OpenGL 3.3 code with Vertex Array Objects (VAO) and tested it later on Intel graphics adapter where I found, to my disappointment, that element array buffer binding is evidently not part of VAO state, as calling:

glBindVertexArray(my_vao);
glDrawElements(GL_TRIANGLE_STRIP, count, GL_UNSIGNED_INTEGER, 0);

had no effect, while:

glBindVertexArray(my_vao);
glBindBuffer(GL_ELEMENT_ARRAY_BUFFER, my_index_buffer); // ?
glDrawElements(GL_TRIANGLE_STRIP, count, GL_UNSIGNED_INTEGER, 0);

rendered the geometry. I thought it was a mere bug in Intel implementation of OpenGL (because it is clearly stated in GL_ARB_vertex_array_object (and even in GL_OES_vertex_array_object) that element array is part of the saved state), but then it occured on mobile NVIDIA Quadro 4200. That's no fun.

Is it a driver bug, a specs bug, or a bug somewhere in my code? The code works flawlessly on GeForce 260 and 480.

Anyone had similar experience?

What is also strange is that GL_EXT_direct_state_access does not have a function to bind an element array buffer to VAO (but it does have functions to specify vertex attrib arrays, and hence array buffers). Are the GPU manufacturers screwing the specs and cheating on us, or what?

EDIT:

I originally didn't intend to show any source code because I believed it was not necessary here. But as requested, here is the minimal test case that reproduces the problem:

static GLuint n_vertex_buffer_object, p_index_buffer_object_list[3];
static GLuint p_vao[2];

bool InitGLObjects()
{
    const float p_quad_verts_colors[] = {
        1, 0, 0, -1, 1, 0,
        1, 0, 0, 1, 1, 0,
        1, 0, 0, 1, -1, 0,
        1, 0, 0, -1, -1, 0, // red quad
        0, 0, 1, -1, 1, 0,
        0, 0, 1, 1, 1, 0,
        0, 0, 1, 1, -1, 0,
        0, 0, 1, -1, -1, 0, // blue quad
        0, 0, 0, -1, 1, 0,
        0, 0, 0, 1, 1, 0,
        0, 0, 0, 1, -1, 0,
        0, 0, 0, -1, -1, 0 // black quad
    };
    const unsigned int p_quad_indices[][6] = {
        {0, 1, 2, 0, 2, 3},
        {4, 5, 6, 4, 6, 7},
        {8, 9, 10, 8, 10, 11}
    };
    glGenBuffers(1, &n_vertex_buffer_object);
    glBindBuffer(GL_ARRAY_BUFFER, n_vertex_buffer_object);
    glBufferData(GL_ARRAY_BUFFER, sizeof(p_quad_verts_colors), p_quad_verts_colors, GL_STATIC_DRAW);
    glGenBuffers(3, p_index_buffer_object_list);
    for(int n = 0; n < 3; ++ n) {
        glBindBuffer(GL_ELEMENT_ARRAY_BUFFER, p_index_buffer_object_list[n]);
        glBufferData(GL_ELEMENT_ARRAY_BUFFER, sizeof(p_quad_indices[n]), p_quad_indices[n], GL_STATIC_DRAW);
    }

    glGenVertexArrays(2, p_vao);
    glBindVertexArray(p_vao[0]);
    {
        glBindBuffer(GL_ARRAY_BUFFER, n_vertex_buffer_object);
        glEnableVertexAttribArray(0);
        glVertexAttribPointer(0, 3, GL_FLOAT, GL_FALSE, 6 * sizeof(float), p_OffsetInVBO(0));
        glEnableVertexAttribArray(1);
        glVertexAttribPointer(1, 3, GL_FLOAT, GL_FALSE, 6 * sizeof(float), p_OffsetInVBO(3 * sizeof(float)));
        glBindBuffer(GL_ELEMENT_ARRAY_BUFFER, p_index_buffer_object_list[0]); // red
    }
    glBindVertexArray(0);

    glBindVertexArray(p_vao[1]);
    {
        glBindBuffer(GL_ARRAY_BUFFER, n_vertex_buffer_object);
        glEnableVertexAttribArray(0);
        glVertexAttribPointer(0, 3, GL_FLOAT, GL_FALSE, 6 * sizeof(float), p_OffsetInVBO(0));
        glEnableVertexAttribArray(1);
        glVertexAttribPointer(1, 3, GL_FLOAT, GL_FALSE, 6 * sizeof(float), p_OffsetInVBO(3 * sizeof(float)));
        glBindBuffer(GL_ELEMENT_ARRAY_BUFFER, p_index_buffer_object_list[1]); // blue
    }
    glBindVertexArray(0);

#ifdef BIND_BLACK_QUAD_ELEMENT_ARRAY_BUFFER
    glBindBuffer(GL_ELEMENT_ARRAY_BUFFER, p_index_buffer_object_list[2]);
    // bind the buffer with the black quad (not inside VAO, should NOT be seen)
#endif // BIND_BLACK_QUAD_ELEMENT_ARRAY_BUFFER

    // [compile shaders here]

    return true; // success
}

The above code creates a vertex buffer containing three quads, red one, blue one and black one. Then it creates three index buffers that point to the individual quads. Then two VAOs are created and set up, one should contain red quad indices and the other should contain blue quad indices. The black quad should not be rendered at all (assume BIND_BLACK_QUAD_ELEMENT_ARRAY_BUFFER is defined).

void onDraw()
{
    glClearColor(.5f, .5f, .5f, 0);
    glClear(GL_COLOR_BUFFER_BIT);
    glDisable(GL_DEPTH_TEST);

    glUseProgram(n_program_object);

    static int n_last_color = -1;
    int n_color = (clock() / 2000) % 2;
    if(n_last_color != n_color) {
        printf("now drawing %s quad\n", (n_color)? "blue" : "red");
        n_last_color = n_color;
    }

    glBindVertexArray(p_vao[n_color]);
#ifdef VAO_DOESNT_STORE_ELEMENT_ARRAY_BUFFER
    glBindBuffer(GL_ELEMENT_ARRAY_BUFFER, p_index_buffer_object_list[n_color]); // fixes the problem
#endif // VAO_DOESNT_STORE_ELEMENT_ARRAY_BUFFER
    glDrawElements(GL_TRIANGLES, 6, GL_UNSIGNED_INT, 0);
    glBindVertexArray(0);
}

This clears the viewport to gray and renders either blue or red quad in repeating manner (it also prints which one). While this works on desktop GPU, it doesn't work on notebook GPU (black quad is rendered unless the VAO_DOESNT_STORE_ELEMENT_ARRAY_BUFFER macro is defined. Undefining the BIND_BLACK_QUAD_ELEMENT_ARRAY_BUFFER macro makes the quad blue, as the blue index buffer is bound last. But it doesn't render the red quad no matter what.

So the way I see it, it's either a fatal misconception in my understanding of how should VAO work, a bug in my code, or a driver bug.

Full source
Binaries (windows, 32 bit)


Solution

  • After some time, I found out this was actually kind of my bad. The laptop with the mobile NVIDIA Quadro 4200 graphics card was set so that all the apps would run on the Intel graphics by default, even when the laptop was in the performance mode. I don't understand why would someone want to do that, as then there was no way for any application to use the more powerful GPU from OpenGL (it was still possible to use it for OpenCL as there is explicit device selection, also maybe for DirectX - that would explain why some games ran smoothly).

    Nevertheless, the described errorneous behavior is just a bug in Intel drivers, that's all there's to it. Intel drivers do not save ELEMENT_ARRAY_BUFFER_BINDING. There.

    I'm sincerely sorry for asking the question, as there was no way to give a good answer without knowing the above.