I am designing a resource manager that handles all uploading of data to the video card. In OpenGL, I am doing this with VBO's. I started with a simple slot structure where I fragment a large part of VRAM into differing buffer sizes, and when the program requests some video memory, it locks the smallest buffer that will fit the requested size and returns a pointer to the memory. There were two ways of implementing this: when initializing video memory, create one large (32 meg) vertex buffer and virtually break it up with offets and such. Or I could create a vertex buffer per slot, so there'd be around 70 smaller buffers. I seemed to get better performance by initializing one large buffer and using it, which seems obvious because there is no buffer binding and it is freely usable. However, and this may be due to my lack of understanding, I'm a little worried about using one huge buffer. When the video card runs out of memory, does the driver start swapping memory with system memory, so there might be a time when it swaps out the WHOLE vertex buffer (32 megs!) and swaps it back? Obviously this would be drastically reduced with using many smaller buffers. Just curious if it is a legitimate concern, and if it is a good plan to use one large buffer.

Rule of thumb :
One large buffer = bad.
Lots of small buffers = bad.
Numberous medium sized buffers = best idea.

Theres a section on VBOs in the OpenGL performance guide pdf and video in my sig below...

Hey phantom! Thanks for the tip... especially for the paper, I've seen it before but had lost the link. I'll have to skim through it. Unfortunately, the best approach for VBO's is the hardest to implement. Now I have to make some medium sized buffers, virtually split those into blocks, and also keep track of which buffer is currently being using compared to which one is requested.

It also puts a bottleneck in the program since now everything has to be sorted first by buffer, then by shader, etc. Oh well. I guess it's all about playing around and testing.