This is questionable.
This is what nVidia said. If you find it “questionable”, question them. Until they say that it isn’t the case, then it is, as far as I’m concerned.
While possibly true, I have found vbo performance to equal regular va when using streaming.
Which is hardly surprising because you’re streaming. You’re generating data per-frame in some fashion, so you’re required to do a copy operation. As such, you can only go so fast.
Also, from nVidia’s document, it seems that their glMapBuffer call for streaming buffers just allocates some system memory, rather than giving you a direct pointer to the actual memory. This means that streaming can’t be faster than standard arrays since you aren’t writing directly to the buffer memory itself.
If your data is quite small one large vbo may not work. I deal mainly with very large models,few models per scene. Perhaps, arb should modify the vbo so that you can map only a portion of the vbo, the portion you will change. In that case, write or streaming will be best.
This would require that they perpetuate the idea that using VBO like VAR is a good idea. It is not. One of the primary problems VBO’s are supposed to solve is getting buffer management out of the users hands and into the driver’s hands.
Synchronization issues are still present with vbo. If you try to render to a vbo(write to it, map it, whatever) you will cause errors. I tested this thoroughly.
That’s not a sync error. That’s either an error in your code or an error in the implementation in question. In either case, it has nothing to do with the VBO spec.
The api is the same for all, but you need special handling. Saying stop trying to someone is not constructive.
It’s far more constructive than complaining about something that is, by definition, implementation dependent.
Finally, who made Carmack boss of the graphics universe.
People who keep buying games/engines made by Id Software. Like it or not (and I don’t), that gives him clout that we don’t have. And it is his choices in how to use VBOs that we will be expected to follow.
Fortunately, he’s usually pretty reasonable in using an API, so I don’t expect his VBO usage to be totally off the beaten path.
If ARB had done its job,
then functionality of vbo would work similarly across all platforms. Performance would not be the same, but at least the way it worked would be uniform. If opengl cannot get vendors to implement standards in platform consistent manner, then it has a serious problem.
There is a difference between performance and functionality. Functionality is what a spec defines; not performance. The standard doesn’t prevent an implementation from being faster in certain usage patterns of the API. Just like the spec doesn’t prevent an implementation from punishing the user for pathological (though legal) use of the API.
For example, the whole VBO-as-VAR thing. This is a legitimate usage pattern for VBO’s. The behavior of this pattern is well understood, and all implementations of VBO should be able to function with it. How fast this is must always be implementation dependent. For some implementations, like nVidia’s where bind-equivalent actions incur some overhead, the VBO-as-VAR is faster than multiple VBOs. For other implementations where bind-equiavlent actions are just like any other state change, the VBO-as-VAR paradigm is, at best, no faster than normal.
The point is that expected performance is, and must always be, implementation dependent. The best the spec could ever do is give guidelines about what the “fast” path should be.
If we need to wait for D3 to have realiable abd predictable performance VBO. I Prefer to keep using VAR and Vertex objects until D3 comes out! Because the MAIN advantage of VBO is missing!
The primary purpose of the VBO extension is to provide for a cross-platform solution to vertex transfer that gives the driver the flexibility to manage buffer memory as it needs to. VBO effectively solves that purpose. Performance is, and has always been, implementation dependent.
You can get reliable performance out of VBOs today. You may not get optimal performance out of all implementations, but if you use the VBO API reasonably, then all implementations should be reasonably fast. Maybe not as fast as possible, but decently fast.
If you want to keep using extensions like VAR and the multitude of VAO extensions, good for you. Just don’t complain when ATi pulls the plug on VAO. And don’t complain that you have to use VAR/VAO; you have a perfectly viable alternative.