VBO's and Memory Management / Paging

Hi all!

We’re recently ran into some problems which might be related to VBOs.
Most of our geometry is allocated with GL_STATIC_DRAW_ARB. Afaik our own malloced geometry data can be freed afterwards, so obviously the driver stores a copy of the data.
I wonder if the data is the paged by the driver to/from video/agp mem into normal mem or does it always reside in video/agp mem. Say, we have 256 MB gfx mem, and 150 MB vbo data, and 40 MB textures. Are both textures and vbo data cached the same way or is vbo data prioritized?
Somehow our program gets slower and slower with the amount of vbo data allocated?
Maybe someone can give us some hints?

Thanks in advance!

Gordon

If the data doesn’t fit into memory which gives fast access (AGP, video) your behaviour sounds as if buffers are either paged or simply not moved and the additional ones are in slower host memory.
Check your system BIOS for the AGP aperture size, increase it if you think you have enough system RAM.
Try if reducing the screen resolution frees up more video memory space.
Do you really need 150MB at once? Could you STREAM_DRAW it instead.

Thanks Relic.
I am going to further investigate this. AGP Aperture is at 256 MB. And no, the 150 MB are not needed at the same time. I am just curious where the driver stores the data, if texture data and vertex data do share the same memory and if so, if texture or vertex data have priority.

The intention is that VBOs are treated like textures. The driver is supposed to optimize which parts of which buffers in are in graphics memory at once. Some drivers are better at that than others. My gut feeling is that the driver may be choking on a single 150MB VBO. What might be happening is that, as available on-card space becomes limited, the driver is forced to move the entire buffer on and off the card. That flushing sound is your performance going down the toilet.

You might try breaking the large VBO into several smaller VBOs (if possible) and see what sort of difference that makes.