I also tried using glVertexAttribPointer without VAOs and it simply didn't work.
How about a simple pseudo code example? :)
Vertex Array Object + Direct State Access
To go one wiki page further, under glVertexAttribPointer: "GL_INVALID_OPERATION? is generated if no vertex array object is bound."
The following thread is also relevant, but nobody explicitly says anything like "yes, I've fallen back to older GLSL and non-generic attributes":
http://www.gamedev.net/topic/649916-valve-opengl-tips-and-tricks/
Author
To go one wiki page further, under glVertexAttribPointer: "GL_INVALID_OPERATION? is generated if no vertex array object is bound."
The following thread is also relevant, but nobody explicitly says anything like "yes, I've fallen back to older GLSL and non-generic attributes":
http://www.gamedev.net/topic/649916-valve-opengl-tips-and-tricks/
Also, here http://www.opengl.org/wiki_132/index.php/Vertex_Rendering#Prerequisites
VAO is mandatory. Just not for people who are using compatibility mode with deprecated functionality apparently.
Upon slightly more careful reading of the Red Book it seems this is the case... well played GL, well played.
I guess this will make sense once the ARB_multi_bind extension is common as you can use VAOs for VB attributes (types, stride etc) and use multi-bind to replace all the buffer bindings in one shot... either based on the performance and usage case issues I'd pretty much only use it for that right now; bind the attributes to a VAO (probably drag it around with my materials/shaders) and just over write the buffer bindings as required.
I guess this will make sense once the ARB_multi_bind extension is common as you can use VAOs for VB attributes (types, stride etc) and use multi-bind to replace all the buffer bindings in one shot... either based on the performance and usage case issues I'd pretty much only use it for that right now; bind the attributes to a VAO (probably drag it around with my materials/shaders) and just over write the buffer bindings as required.
ARB_vertex_attrib_binding also helps make VAOs make more sense - you can set up your formats, layouts, strides, etc in a VAO and then just bind the VAO and replace the buffers as required. This is a better match to the common usage pattern of having the same vertex format but different buffers.
Unfortunately vertex attrib binding is not commonly supported either (thanks a lot, AMD and Intel).
The first 3 functions mentioned in the OP are part of ARB_vertex_attrib_binding and are documented with that extension.
Author
ARB_vertex_attrib_binding also helps make VAOs make more sense - you can set up your formats, layouts, strides, etc in a VAO and then just bind the VAO and replace the buffers as required. This is a better match to the common usage pattern of having the same vertex format but different buffers.
Unfortunately vertex attrib binding is not commonly supported either (thanks a lot, AMD and Intel).
The first 3 functions mentioned in the OP are part of ARB_vertex_attrib_binding and are documented with that extension.
Luckily I'm targeting OpenGL 4.3+ so I have access to ARB_vertex_attrib_binding as a core feature.
So, it turns out that you might want to be using VAOs after all....
http://www.openglsuperbible.com/2013/12/09/vertex-array-performance/
Which makes me wonder what Valve were doing to come to their conclusion, or maybe NV's Linux drivers just suck more than the Windows ones in this respect (NV benchmark pretty poorly in the above link too compared to AMD)
http://www.openglsuperbible.com/2013/12/09/vertex-array-performance/
Which makes me wonder what Valve were doing to come to their conclusion, or maybe NV's Linux drivers just suck more than the Windows ones in this respect (NV benchmark pretty poorly in the above link too compared to AMD)
The linux drivers for both AMD and Nvidia aren't as mature as their windows counterparts. It might be that it's just a collection of performance tips relating specially to linux. There is no viable alternative to VAOs though, which is why we are all so confused. You can't skip VAOs because you often have 300 VBOs with the same attribs, and attribs aren't remembered for VBOs, or anything else, except VAOs.
Note: I have had better performance on Linux overall though!
OpenGL is a bit ...-backwards sometimes.
You ideally just "enable" your 5 attribs, and then proceed to render 300 VBOs. You can't. It sucks. 
Instead I have to create 300 VAOs, with 5 "enabled" attribs each. Then render 300 VAOs.
The madness stops at GL 4.x (from superbible):
"However, these functions were introduced in OpenGL 4.3 and so may not have widespread support just yet, whereas VAO has been in core OpenGL since version 3.0"
What were they thinking?
So, it turns out that you might want to be using VAOs after all....
http://www.openglsuperbible.com/2013/12/09/vertex-array-performance/
Which makes me wonder what Valve were doing to come to their conclusion, or maybe NV's Linux drivers just suck more than the Windows ones in this respect (NV benchmark pretty poorly in the above link too compared to AMD)
I would like to see his benchmarks when he is not redundantly calling glEnableVertexAttribArray() and glDisableVertexAttribArray().
L. Spiro
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
