Originally posted by Korval:
[b]Sure. If all your application does is throw vertices at the card, then this is possible.
However, most programs that render 3D graphics tend to do more than that. CAD and other graphics creation apps need to be listening to the mouse and doing other tasks. Games, obviously, have tons of other stuff they can be doing.[/b]
That’s why I specified my points the way I did. Including the ifs and reasons.
If I condense them further, can you agree to these basic points?
1)Copying the data to a VBO is never free.
2)Modifying a vertex array in system memory is much faster than modifying VBO contents.
3)VBOs don’t make vertex processing itself faster.
4)VBOs consume card memory.
These aren’t obscure, irrelevant issues. If I wanted to go there, I would have told the fairy tale of reduced local bandwidth consumption and consequently higher effective fillrate (especially with active blending) if you don’t put your vertex data in card memory. As a matter of fact, this is both correct and entirely irrelevant in practice.
OTOH the above points are not irrelevant in practice.
So, unless you’re just making a graphics demo, you want all the CPU time you can get.
Maybe I want to make a graphics demo, and maybe I don’t. You shouldn’t need to care. All I wanted to do was point out a few pitfalls that may or may not be a problem for an application. It just depends. It always does.
However, as I pointed out, you’re always going to benifit from VBO’s. At the very least, you claim some CPU time that you can use to make your app more responsive/use that new physics system/better collision detection/etc.
<=>
Pathological use of the API is pathological use of the API, whether it is VBOs, textures, or anything else. If you’re doing something stupid, you can always expect bad performance.
How does that mix? If I can misuse VBOs in a way that reduces performance, how can VBOs always benefit me? You’re contradicting yourself.
I agree that the usage model behind that link is just wrong. Which brings me back to the reason why I initially posted to this thread. Had the implementor of this “stupid” usage model known that “copying the data to a VBO is never free”, he might have understood earlier why it didn’t work out, and could have chosen to do things differently.
If Hellhound planned on doing the same thing, after reading pure unconditional praise about VBOs, that would not have been stupid, because he asked expecting good advice, and no one told him about the potential issues.
I have a pet project that doesn’t benefit from VBOs either. I know that for a fact, because I have a VBO path in there that I can just turn on with the flick of a preprocessor macro, and it has always been worse than plain system memory arrays, or even “mutated” immediate mode (mutated := glVertex3fv), on every driver I’ve tried, practically since the VBO extension was first officially released up until today. I’m entirely certain that I didn’t just make it all up.
I really don’t get what’s going on here, Korval. You’re not going to prove me wrong by telling me what requirements, in your opinion, a “proper” application should have.