Jump to content
  • Advertisement
Sign in to follow this  
CyberSlag5k

Terrible VBO performance

This topic is 4818 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Now that my VBOs are finally working (thanks again everyone), I have a question about their performance. If I run my program using display lists or plain old vertex arrays, it runs pretty fast. The display lists are faster than the VAs, but not by much and both look pretty good. However as soon as I enable the VBOs in a larger object, things start crawling. I go from something like 30 frames per second to a frame every 1 or 2 seconds. Someone suggested it might be the size of the objects that are killing the performance, and going back and reading all of my old posts about VBOs, that seems to be a general consensus: VBOs don't like super big objects. To further support that theory, the VBOs work fine (no better, no worse than the display lists) on the two smaller objects I have. I tried it on a 36 polygon box and a 3800 polygon cow (yes, a cow). However as soon as I moved it up to a model with about 35,000 polygons, it starts crawling. Now I know all of the evidence points to the size of the objects, and worry not fellow board crawlers, while you're reading this very post I shall be splitting my object up into about 8 different VBOs to see if that helps, but the thing that gets me is that the vertex arrays have no problem with objects that size. Isn't a VBO just like a VA only with the data already stored in speedy VRAM, AGP transfer free? So shouldn't things get faster and not slower? The video card I'm working with isn't the greatest, an MX440 with only 64MB of RAM, but is it even remotely possible that I'm actually using that much memory? The file for the biggest object is only about 5MB. So my question, while I attempt the obvious solution, is would there be anything, other than the size of the object, that would be adversely hindering the legendary performance of the VBO extension? And the other question is, why can the VA's handle it just fine while the VBO's are dying? And as a matter of fact, don't display lists store the data in VRAM as well? The display lists run even better than the VAs (the object's geometry is static so that's not too unbelievable), with the same object stored in their memory as the VBOs. Hmm....compelling. Thoughts?

Share this post


Link to post
Share on other sites
Advertisement
That *is* pretty strange.
I just wanted to let you know that 'size doesn't matter'.
I use VBOs for objects containing about 17k triangles.

how are you setting up your VBOs?

Share this post


Link to post
Share on other sites
Two things come to mind from my own experience.
1 - Are you using mipmapping?
2 - Are you clearing the entire display using glClear(GL_COLOR_BUFFER_BIT...), or are you just clearing the depth buffer?

If you use mipmapping and only clear the depth buffer, you'll find there's a reasonable speed boost in comparison to rendering things using full-detail textures and clearing the entire display. At any rate, it seems strange that you're getting 1-2 frames per second, considering I get the same speeds on my GeForce 2 mx-200 (64MB, like yours) when I'm rendering 2093058 triangles using vertex arrays, and when I cut it down to ~32k triangles, it runs perfectly (by my standards)...

Share this post


Link to post
Share on other sites
Although size generally might matter once you get over the 'unsigned short' mark (videocards are generally optimal with unsigned short as index type) you're not at that mark yet.

Share this post


Link to post
Share on other sites
Hmm, it can't be size, because i have rendered well over 300,000 triangles at 90-110 fps, using VBOs. Can you post some relevent code? I doubt this, but i must ask, are you initialising the extention every frame?

EDIT: typos

[Edited by - DerAnged on March 16, 2005 11:17:01 AM]

Share this post


Link to post
Share on other sites
Thank you for your responses everyone.

Quote:

I just wanted to let you know that 'size doesn't matter'.
I use VBOs for objects containing about 17k triangles.


Cool, though I don't run into trouble until I try the object with 32,000 triangles. That's the third smallest object I have, the others at 36 and 3800.

Quote:

1 - Are you using mipmapping?
2 - Are you clearing the entire display using glClear(GL_COLOR_BUFFER_BIT...), or are you just clearing the depth buffer?


1 - Nope
2 - Yeah, I clear the entire display each frame: glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT)

Disabling the clear on the color buffer doesn't help any (and really trips out my display).

Quote:

Although size generally might matter once you get over the 'unsigned short' mark (videocards are generally optimal with unsigned short as index type) you're not at that mark yet.


Actually I kick the crap out of the unsigned short limit on most of my models. Only a handful are sub 65,000 triangles, so I'm using unsigned ints. Still, the slowdown takes place at 32,000 (and probably lower), which is well within the range of an unsigned short (thought it's still being called with an unsigned int).

Quote:

Hmm, it can't be size, because i have rendered well over 300,000 triangloes at 90-110 fps, using VBOs.


That's certainly good to know. I might hit that range eventually.

Quote:

Can you post some relevent code?


Gladly.

VBO setup (done at initialization):

eglGenBuffersARB(2, buffList);

pglBindBufferARB(GL_ARRAY_BUFFER_ARB, buffList[0]);
pglBufferDataARB(GL_ARRAY_BUFFER_ARB, sizeof(struct _Vertex) * numVerts, vertList, GL_STATIC_DRAW);

pglBindBufferARB(GL_ELEMENT_ARRAY_BUFFER_ARB, buffList[1]);
pglBufferDataARB(GL_ELEMENT_ARRAY_BUFFER_ARB, sizeof(unsigned int) * numInd, index, GL_STATIC_DRAW);



Rendering:

pglBindBufferARB(GL_ARRAY_BUFFER_ARB, buffList[0]);
glNormalPointer(GL_FLOAT, sizeof(struct _Vertex), BUFFER_OFFSET(0));
glVertexPointer(3, GL_FLOAT, sizeof(struct _Vertex), BUFFER_OFFSET(12));

pglBindBufferARB(GL_ELEMENT_ARRAY_BUFFER_ARB, buffList[1]);
glDrawElements(GL_TRIANGLES, numInd, GL_UNSIGNED_INT, BUFFER_OFFSET(0));



Quote:

I doubt this, but i mus ask, are you initialising the extention every frame?


Heh, nope.

When would someone use GL_STATIC_READ, by the way? I figured it'd be a good thing to use for the index VBO as it doesn't contain actual geometry. And what about the GL_DYNAMIC_DRAW and whatever the other one is? Is that for if your vertex array's values are going to change (like with animation)?

Thanks for everyone's help so far. It's pretty much agreed upon that this is not a size thing, then?

Share this post


Link to post
Share on other sites
GL_STATIC_READ would be used if you planned to readback the infomation, this could cause the driver to keep the data in AGP or even system ram to allow for the readback, so probably not advised.

A quick look over the spec. gives that GL_STATIC_DRAW is probably your best bet, as you'll not be reading back data and not respecifying it... you could try GL_STREAM_DRAW, however thats basically the same thing

Share this post


Link to post
Share on other sites
Quote:
Original post by DerAnged
What graphics card?
How's your speed with just vertex arrays?


GeForce MX440 64MB RAM

Display lists are currently the fastest but not by much. Vertex arrays are almost as fast as the display lists. Hardly noticably slower. Like 25-30 frames per second, I would guess.

Share this post


Link to post
Share on other sites
Quote:
Original post by CyberSlag5k
Quote:
Original post by DerAnged
What graphics card?
How's your speed with just vertex arrays?


GeForce MX440 64MB RAM


Boom, i had numorous problems with that card! This is why mine have a test, if VAs are faster than VBOs it usees hem instead, just becasue of my experiance with that card.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!