VBO and new Nvidia driver issue

I don’t know what happened, but when I was on the 45.43 drivers, I would get ~35-40fps on a 130K tris landscape. Now that I upgraded to the 52.16 drivers, I’m getting as much fps as without having VBOs, sometimes even 2-3 frames less (which is about 15fps).

Did something change in the new driver version? I’m guessing I did something wrong for setting up the VBOs and the new drivers are at fault with it.

Here’s a code snippet I’m playing around with right now, hopefully someone can help shed some light on this.

// Assign vertex mem
glBindBufferARB(GL_ARRAY_BUFFER_ARB, 1);
glBufferDataARB(GL_ARRAY_BUFFER_ARB, cMesh->mNumVerts * 3 * sizeof(float), cMesh->mVData, GL_STATIC_DRAW_ARB);

// Do same for tex coords, normals, colours

// Assign index mem
glBindBufferARB(GL_ELEMENT_ARRAY_BUFFER_ARB, 6);
glBufferDataARB(GL_ELEMENT_ARRAY_BUFFER_ARB, cMesh->mNumFaces * 3 * sizeof(short), cMesh->mFData, GL_STATIC_DRAW_ARB);

// Now assign the pointers
glBindBufferARB(GL_ARRAY_BUFFER_ARB, 1);
glVertexPointer(3, GL_FLOAT, 0, 0);

// etc…

// Draw specially for VBOs
glDrawElements(cMesh->mRenderType, cMesh->mNumFaces * 3, GL_UNSIGNED_SHORT, 0);

// Clean memory used for next object
glDeleteBuffersARB(6, buffer); // 6 in total to clean

// repeat above code for all objects in the scene

[This message has been edited by theghost (edited 12-06-2003).]

Stupid question, but, do you allocate the buffer each time as you render. If so, do not do this. Also, try to reduce the number of glBindBuffer calls.

Yeah, I am, I figured I was suppose to. If I have 100 objects to render, I don’t want to have to create 100x6 buffers to store all the objects, I doubt my video card would actually be capable of storing all that. I just want to allocate the memory for the specific object, render it, then free the memory for the next object (pretty much what I did for VAR back in the day)

Originally posted by maximian:
Stupid question, but, do you allocate the buffer each time as you render. If so, do not do this. Also, try to reduce the number of glBindBuffer calls.

Neither of these are particularly bad. For “stream” data, you should allocate every frame.

And you don’t need to go overboard reducing the number of glBindBuffer calls. This is not particularly low performance. Unfortunately the VBO whitepaper give inaccurate advice on this point.

Thanks -
Cass

Whoops, my bad. Yeah, I switched it to a dynamic based memory call and managed to get 2x improvement. Still though, I use to get 40fps with VARs. Something is still missing.

Also, I think I’m starting to realize the differences between VBOs and VARs, but what I don’t understand is if you’re going to make an object static and keep data in the video memory, why not just use display lists? They are practically the same thing (meshes are assumed to be static), but easier to implement in my opinion because there’s less function calls and no VBO extension dependency.

[This message has been edited by theghost (edited 12-06-2003).]

Heh, silly me, forgot a simple issue in the code. It’s now rendering at 43 fps, equal to that of the VAR performance. Everything’s back to normal now =)

Originally posted by theghost:
Heh, silly me, forgot a simple issue in the code. It’s now rendering at 43 fps, equal to that of the VAR performance. Everything’s back to normal now =)
What was it?

I was deleting the buffers after each object being rendered when I shouldn’t have (unlike VARs where you had to flush the content every time). So I just moved the deletion of the memory to the destructor of the render class and only free the memory once my program terminates. This operation is quite expensive to do at runtime, so by removing it I gained an extra 10fps.