Jump to content
  • Advertisement
Sign in to follow this  
kRogue

OpenGL optimal VBO usage?

This topic is 3715 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

Hello all, I have read on posts here at gamedev.net, that one gets better performance out of VBO's if one creates VBO's of about 1-4MB in size, thus rather than have one VBO per mesh, one combines several meshes data into 1 VBO. In my situation I am also talking about static VBO's, i.e. those VBO's fro which the data does not change. Now my question: what kind of performance increase have people seen in combining into a few VBO's? I ask because at developer.nvidia.com, there is no mention of an optimal VBO size, or more vs fewer VBO's are better. There is mention to make VBO's before textures, that do use GL_UNSIGNED_SHORT for indexing and that binding VBO's is cheap, but glVertexPointer() and like functions are more expensive (so in that case one can easily argue to combine geometric information of a fixed mesh into one VBO and use an interleaved format, but to take advantage of that then one has to use the "opengl" names for vertex shader attributes, as I don't think there is an analogue for interleaved formats for named attributes, ala glVertexAttribPointer). At any rate to ask: 1) what kind of performance increase have people seen, if any, in using just a few large VBO's for many meshes rather than a simplistic 1 VBO per mesh behavior? 2) what kind of performance increase have people seen, if any, in using one VBO to hold different attribute and then using glInterleaved like calls, instead of having say one VBO per attribute and using multiple glVertexAttrib, or one VBO for all attributes and using glInterleaved like calls)? Note that implementing 2) is often quite easy, but implementing 1) is a real hassle.

Share this post


Link to post
Share on other sites
Advertisement
Sorry KRogue,

I can't answer any of your questions, because I am lacking the experience. The only thing I can do is to raise the general confusing :-P

I am struggling with the same problems and I am always happy to see that I am not alone =)

To 1)
My VBO-Performance is not too good, I tried a 1Mio triangle batch and performance went not well (without any shading).

So today I queried:
glGetIntegerv(GL_MAX_ELEMENTS_INDICES, &MaxElementsIndices);
glGetIntegerv(GL_MAX_ELEMENTS_VERTICES, &MaxElementsVertices);

And guess what, the results were:
4096 for both !!! *loooooll* ????

Is this for real ? What can I batch with THAT ? That sounds not so much like BATCHING in my ears, rather than SPLITTING !!??
Tell me that this is a bad joke. I am using a GF6800LE 128MB.

Btw. I need to batch up a lot of small primitives like rectangles, circles, polygons, so I have to fit many shapes (not meshes) into a single buffer for performance reasons. I know its a hassle. But then again with 4096 indices one can not batch too many primitives ;-)

To 2)
In theory I know cache utilization will be worse, but it won't kill you. I would suggest just do it, but again what do i know ?


My frustration with OpenGL + Documentation is constantly growing, I begin to believe that it may be possible that it is just too complicated for me. The unfortunate thing is I need to come up with a vbo-policy rather quickly for my work. Otherwise I would give it a rest.

I am tired, I will go now and implement *something* working...
Sorry for not giving the answer you are expecting - I have read the very same posts as you, but can't talk from experience :-)
Frederick

Share this post


Link to post
Share on other sites
Hey kRogue,

maybe this OpenGL.org thread is of interest for you, maybe you've already read it =) :
VBO layout of attributes

There is a lot about optimal cache utilization, vbo usage etc. Unfortunately the end of thread is disturbing to me, one of the participants has the same problem as me, a maximum batch size of 4096 indices - unfortunately the problem remains unresolved. This is a direct contradiction to the best practice of creating large batches, isn't it ?

Share this post


Link to post
Share on other sites
Hi,

On my GeForce 8700M GT, I get 1048576 for both (this value is 2^20)... me thinks that there is a driver bug when it reports 4096(=2^12) for both. One thing I do know is that one should use 16bit indices in the glDrawRangeElements calls, which means you can have up yo 65536 distinct vertices for one glDrawRangeElements call. This I do, I also re-order the indices to prime the vertex cache.

But this all does not address the initial question, what kind of performance gains are there with 1 large VBO for many objects vs one (or several) VBO's for each objects...again, since indices have to be 16bit integers it is inadvisable to bind the one huge VBO and call glVertexAttrib once and rely on funky indices to do the right thing, so for each mesh one has to call glVertexAttrib which, according to nVidia docs is pricier than binding a VBO.




Share this post


Link to post
Share on other sites
Quote:
Original post by kRogue
On my GeForce 8700M GT, I get 1048576 for both (this value is 2^20)... me thinks that there is a driver bug when it reports 4096(=2^12) for both.

Err, I got 150,000 for indices and 2048 for vertices on a 8800GT! Is that realistic?

Quote:
Original post by kRogue
[...] since indices have to be 16bit integers it is inadvisable to bind the one huge VBO and call glVertexAttrib once and rely on funky indices to do the right thing, so for each mesh one has to call glVertexAttrib which, according to nVidia docs is pricier than binding a VBO.

Not necessarily. Using 2MB somewhere between the advised 1MB to 4MB, and dividing that by 65536, you'll get 32 bytes per vertex. E.g. 12 bytes for the position, another 12 bytes for the normal, and 8 bytes for a single texture, and you've already summed up to 32 bytes.

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.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!