Vertex array object

SO what is the consensus so far? Worth the time or waste of time? This is for GL2.1 RC not GL3.0 RC…

Waste of time, if you ain’t got it :wink: You do not gain any speed up so far.

Depending on your architecture it is however extremely easy to plug in, i only had to modify 10 lines of code. So, if you are bored, you could implement it in the hope, that it will give you a speed up in the future.

Jan.

I’m not a fan either. For the speed improvement side we might haven’t used a good testing method. What I’am more concerned is more the feature side. I doesn’t provide anything more than my “display list state object” so what’s the point of it? If display lists are really been removed so we need other macro immutable state objects for blending (or a shader :D), depth and stencil test and the rasterizer.

Well I keep the code … because … well I keep it.

I wonder would this make a bigger difference in situations where you were calling 1000’s of different glVertex* and glBindBuffer calls each frame?

Can you post more complete source, or a repro app?

@jeffb: Did you manage to attach element buffer in VAO on your side?

I can certainly reproduce it in a sample.

yes, it works for me.

On which graphics card ? nVidia ?

I have just updated my drivers to 182.05 one and it seams to work now. I was using 180.xx drivers …

Just a bug I guest!

Just to clarify a few things about what you were talking here:

Both the OpenGL 3.0 specification and the ARB_vertex_array_object extension says that both ELEMENT_ARRAY_BUFFER and ARRAY_BUFFER bindings are part of the VAO as well as the VertexAttribPointer specifications. This makes sense. Anything else is just a driver bug. In my case on ATI, Catalyst 9.7 drivers don’t even generate a VAO for me when I use GenVertexArrays. Maybe there are also some problems with the NVIDIA drivers as well.

The main purpose of this feature is to reduce CPU and driver time by not having to issue several GL commands. Any rooms for optimization based on this feature for a particular vendor is beyond the scope of this extension. It is meant to reduce required GL calls and simplify the framework and I think that’s achieved. And of course, it’s very easy to adopt it :slight_smile:

Correction: VAO DOES work with Catalyst 9.7 but GLee was screwed up. I hate these libraries. I searched a lot to find windowing and extension libraries that supports OpenGL 3.0+ contexts. I heard that GLFW and SDL both support 3.0 context creation but only using the latest SVN code. First I’ve tried SDL but didn’t manage to compile it under Windows. Next tried GLFW which has support for 3.0 context creation but it was not working. So I’ve corrected GLFW and now it works. For extension library I used GLee first but as I said it sucks, because for some reason VAO was not working on it (yes, and of course I also had to modify it a bit to work with 3.0+ contexts). Finally now I’m using the corrected version of GLFW and GLEW as extension library and till now everything looks fine. Sorry if I’m off-topic but maybe you can also take advantage of this information :slight_smile:

I’m using GenVertexArrays on my Ati card:


GLuint vao;
glGenVertexArrays(1, &vao);
glBindVertexArray(vao);

GLuint buffer;
glGenBuffers(1, &buffer);
glBindBuffer(GL_ARRAY_BUFFER, buffer);

// adding data to the array buffer with glBufferSubData

glVertexAttribPointer(
    0,
    sizeOfAttrib(0),
    GL_FLOAT,
    GL_FALSE, 
    strideOfAttrib(0),
    offsetOfAttrib(0)
);
	
glVertexAttribPointer(
    1, 
    sizeOfAttrib(1),
    GL_FLOAT,
    GL_FALSE,
    strideOfAttrib(1),
    offsetOfAttrib(1)
);

// drawing

glBindVertexArray(d_vao);
glEnableVertexAttribArray(0);
glEnableVertexAttribArray(1);
glDrawArrays(GL_TRIANGLES, 0, 6);
glDisableVertexAttribArray(0);
glDisableVertexAttribArray(1);

Works like a charm at least with Linux Ati Catalyst 9.6 and 9.7, perhaps I already used it on 9.5 (Radeon HD4870).

[edit]Yes, I used the same code on 9.5 as well, I remembered that I mailed AMD about it back than, because on 9.5 it didn’t work if I selected a forward compatible context (only with non-forward compatible context). Problems were solved in 9.6.[/edit]

Remember to move the glEnableVertexAttribArray calls to you VAO initialization unless you’re planning to enable different attrib arrays for different draw calls.

thnks to all for helping

Will do that, I think I’ve tried it in one of the first Ati OpenGL 3.0 drivers, but it didn’t work back than (or I missed something). Haven’t looked back on it since.

glBindVertexArryay take runtime error:

Unhandled exception at 0x00000000 in DEngine_Test2.exe:
0xC0000005: Access violation.

my code for working with it is:


GLuint temp;
glGenVertexArrays(1,&temp);

if ( temp == 0 )
{
 DLogger.Log("can not create VAO");
 return;
}

glBindVertexArray(temp);
glBufferData(GL_VERTEX_ARRAY,m_uStride,vertics,GL_STATIC_DRAW);	

I’m using VBOs in a -more or less- modern ACER notebook (5612) and I noticed no improvement at all. Then I came to realize that graphic cards in notebooks usually work with shared system memory. ¿Does that mean VBOs won’t give any improvement at all on any notebook?

no, problem is not in the, data saved in VRAM or RAM

vbo’s are fast because they dont use system bus for sending data, this is true for shared ram’s and vram