VBO performance

Vbo really only takes effect when you have a huge amount of data, plus NV cards dont seem to take full effect of it, at least in my experence they haven't, in my new terrain engine, I get around 300 fps on my GFFX and the same for if I dont use VBOs, however, on my radeon 9800, I get 1200 Fps with Vbos, and 400 without, so many factors play roles.

For a start, at such high fps it becomes largely irrelevant. You probably aren't throughputting enough vertices to notice a difference.

I second that. Vertex buffer object is only useful when you're vertex-limited, which doesn't seem to be a problem at such framerates where clearing and swapping play certainly a more important role than vertex throughtput.

Moreover there are many ways to get the same performance with immediate mode than VBO's. If the driver is clever enough, it will optimize the pipeline so that you just get the same hardware operations.

make sure u are testing in a small window eg 100x100 (then hopefully u should see a difference)

Sorry for the necro, but, are vbos the only way to keep more than one vertex array (or whatever array) in video memory at one time?... cause that sounds kinda crappy, probably mostly because i had heard there are alternatives to using extensions, and that those are much faster than extensions (jsut what i heard, please correct me if im wrong)
-Dan

---------
new to OGL

Quote:

Original post by vincoof Moreover there are many ways to get the same performance with immediate mode than VBO's.

Uh...not unless you use your VBOs moronically. The point of VBO is getting vode card memory, and basically to cut down AGP bus traffic. With immediate mode you've got function overhead, AGP bus traffic, and unknown size constraints. All of those problems vanish with VBOs.

Quote:

Original post by Ademan555 Sorry for the necro, but, are vbos the only way to keep more than one vertex array (or whatever array) in video memory at one time?... cause that sounds kinda crappy, probably mostly because i had heard there are alternatives to using extensions, and that those are much faster than extensions (jsut what i heard, please correct me if im wrong) -Dan --------- new to OGL

There are no non-extension rendering methods that are faster than VBO. In theory, display lists could equal the speed of VBO, since they could allow you to store geometry in video memory; but in practice, this isn't usually the case. And obviously in fill-rate limited scenarios, the difference between VBO/display lists/standard VAs is insignificant.

BTW, VBO isn't just an extension; it's part of the OpenGL 1.5 core specification. But if you'd rather use the 10-year-old OpenGL 1.1 spec for everything then feel free.

Quote:

Original post by benjamin bunny BTW, VBO isn't just an extension; it's part of the OpenGL 1.5 core specification. But if you'd rather use the 10-year-old OpenGL 1.1 spec for everything then feel free.

It has been my experience that it is a bad idea to rely on people having updated their drivers when writing software for the "non-hardcore" audiences. The same reason it often still makes more sense to use DirectX 8 instead of 9 for many applications.

Quote:

Original post by benjamin bunny BTW, VBO isn't just an extension; it's part of the OpenGL 1.5 core specification. But if you'd rather use the 10-year-old OpenGL 1.1 spec for everything then feel free.

My system is still running OpenGL version 1.4.1. This is probably because I'm too lazy to update the drivers, but the point is that there are people who you'll find running a stupid OpenGL 1.1 implementation even today.

Quote:

Original post by haro Quote: Original post by benjamin bunny BTW, VBO isn't just an extension; it's part of the OpenGL 1.5 core specification. But if you'd rather use the 10-year-old OpenGL 1.1 spec for everything then feel free. It has been my experience that it is a bad idea to rely on people having updated their drivers when writing software for the "non-hardcore" audiences. The same reason it often still makes more sense to use DirectX 8 instead of 9 for many applications.

Obviously you'd fall back to standard VAs if VBO is not available. That's certainly what I do in my programs. It's not particularly difficult to do with the VBO interface like it is. Similarly for other features. ie, I use vertex programs for skinning, but only on supported hardware; otherwise I fall back to the CPU. There's no reason why a program should require more than OpenGL 1.1; but it's a good idea to use the features if available.

So there is an alternative to ARB vbos, 1.5 vbos right? first, is there any speed gain, and second, how would one get a newer version? and are they graphics card vendor specific? because if not, it woudlnt be too tough to redistribute it with your app (assuming its on a cd or such)
-Dan

the VBOs in the 1.5 spec ARE ARB_vertex_buffer_object, there is no difference from a programming pov (on windows anyways), its basicaly a case of if you get the 1.5 spec they will be mentioned.

how would being on another operating system change that?

meh, i wasnt very clear about that was I.
On windows everything post 1.1 has to be accessed as an extension, so if a feature is core or not doesnt matter, you still have to access it the same way.
On linux the lib/h files tend to be kept up to date, so instead of accessing it as an extension its part of the core API and you dont have to do anything to get at it.

So, on windows, if a thing is core or not is doesnt matter, on linux (and probably OSX as well) it will change things.

well, i guess my question is more, how will it change :-D, im hoping to port stuff to linux eventually, and out of curiousity id like to know how it changes, in general
thanks
-Dan


ps: i dunno if you know that, it is kinda asking a lot, but thanks if you can answer

Well this part is kinda off-topic and, anyway, has been discussed many times before. If you can't find the information you need over web (which would be surprising), feel free to start another thread in order to keep this one on-topic. Thank you.