Also this paper indicates that pointer updates should be kept at a minimum, which is exactly what I had in mind here.
In general, I find some of the points made in their paper to be… odd. Like the point about using glDrawRangeElements providing “precious information for the VBO manager.” By the time you call glDrawRangeElements, any VBO management work ought to be long finished. Maybe there’s an issue with paging in/out VBO’s, but you should page the whole thing in if it’s going in, not pieces of it.
And why is deleting a buffer with glDeleteBuffers a “heavyweight operation”? Is there any real need for it to be any heavier than calling glBufferDataARB with NULL?
Also, why are memory management operations being done in glPointer calls (which, for some reason, they call glVertexArray calls)? Indeed, what memory management needs to be done there? We’ve already selected the VBO to be used. If it isn’t in memory, it should have been paged in when we selected it. And, even if it is paged in with glPointer calls rather than binding, this operation is one that we understand is going to be needed. Like using a texture, we understand that we may incur a performance penalty when we request an infrequently used VBO.
Indeed, I feel that using lots of smaller buffers is better than one big one. If you can’t see your entire level at once, and you’re not drawing what you can’t see, then the memory for non-visible objects may not be in video memory; it may have been paged out to AGP or even system memory. Granted, if you have a sudden need for it, you incur a hit, but you’ll get a hit on textures too. In one giant VBO, the driver can’t page pieces of it out, so you have to keep the entire VBO in the appropriate memory. The extra memory can go to actually visible objects and textures, so you get less paging.
OK, an implementation could break up a giant VBO, but that would require knowing just how much of the VBO we are going to be using in any particular draw calls.
[This message has been edited by Korval (edited 11-27-2003).]