Tyrrrz's picture

Is it normal for VBO to not scale well with numbers?

Right now i store all vertices/texture data in separate VBO for every entity and then draw said VBOs every render update.
Besides that, i'm currently still using FFP for transforming, scaling, rotating, coloring, etc.

So, yeah. I've did some tests with different number of entities (which were 4 vertex polygons).
1 entity - 4000 fps
2 entities - 2500 fps
3 entities - 2200 fps
5 entities - 1800 fps
15 entities - 500 fps
35 entities - 100 fps
100 entities - 15 fps

As you can see, FPS drops down VERY rapidly. It didn't happen when i used display lists (although i couldn't reach 4k fps, it handled well with many entities on screen).
So SHOULD 100 vbos really slow down the process this much?

My entities are meant to have their VBOs updated from time to time (so its DYNAMIC_DRAW) but i also tried to prevent update calls and/or settings STATIC_DRAW which gave no change in performance.

I really wouldn't like to merge all my data into one VBO, so i'm hoping i just do something wrong.

Rephrasing the question: Can 100 untextured plain quads with separate VBOs crash my performance so much?


Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
the Fiddler's picture

This appears to be low, but it's hard to make concrete suggestions without more details and/or code. It appears that you are hitting a performance wall at around 30 entities and then performance degrades linearly:

Is your dataset really untextured plain quads? In that case why use separate VBOs? Create one and draw all your quads using that.

Other than that, the typical suggestion is sort your entities by material (shader), texture, vertex buffer and then draw in batches. The fewer GL.Bind* calls you make, the faster it will run.