One VAO takes more time than more than 40 put together despite being simpler

I was running visual studio's CPU profiling tool when I noticed that of my RenderScene call, my skybox was taking up 30% of the frame time.

This is particularly weird, as as you can see the Object3D::draw call is much less, and I have just one Skybox and 35 Object3Ds.

I went in further and found that glBindVertexArray was taking all of the time. What could be causing this? The VAO in question is defined here:

    glGenVertexArrays(1, &thisVAO);
glBindVertexArray(thisVAO);

//Setup the Vertex buffer
glGenBuffers(1, &vertsVBO);
glBindBuffer(GL_ARRAY_BUFFER, vertsVBO);
glBufferData(GL_ARRAY_BUFFER, sizeof(float)*3*36, skyboxVertices, GL_STATIC_DRAW);
glVertexAttribPointer(0, 3, GL_FLOAT, GL_FALSE, 0, (const GLvoid*)0);
glEnableVertexAttribArray(0);


and the Skybox Draw call here:

//Shader uniform setting....
// ... set view and projection matrix

//Actually draw the skybox
glBindVertexArray(thisVAO);

glActiveTexture(GL_TEXTURE0);

glBindTexture(GL_TEXTURE_CUBE_MAP, textureID);

glDrawArrays(GL_TRIANGLES, 0, 36);


Here is visual studio's take on the draw call:

VAOs for Object3D have 5 VBOs and an elements buffer, as opposed to skybox's one VBO, and skyboxVerticies has 96 entries in it for 36 verticies. Most meshes for object3Ds are 1000+ verticies plus, and the Terrain has 48,000. Anything obvious I am missing? The vertex co-ordinates are very large, would that affect the call time for glBindVertexArray()?

#version 330 core
layout (location = 0) in vec3 aPos;

out of TexCoords;

uniform mat4 projection;
uniform mat4 view;
uniform vec4 clipPlane; // The Plane Clipping
uniform int usePlane; // PLane bool

void main ()
{
TexCoords = aPos;
gl_Position = view * vec4 (aPos, 1.0);
}


Edit : Changing the order has changed things completely, It appears the first glBindVertexArray() per frame has significant overhead (30% of each frame), regardless of shader or vertex array size. Why is this? How can I fix it?

• Whats your frame time? 30% could mean anything. The driver might need to flush some draw calls before new state changes and commands can be buffered or your profiler was just unlucky. – tkausl Feb 23 '19 at 1:56
• About 10ms per frame, varies a little depending on what physics is doing. And it does this consistently – Figwig Feb 23 '19 at 2:03
• How simple is the skybox shader? – HolyBlackCat Feb 23 '19 at 9:03
• Added the skybox vertex shader to question. Fragment shader is literally 3 lines – Figwig Feb 23 '19 at 15:13