How to determine size of memory available for VBO's

Can anybody tell me how I can determine the size of memory available for vertex buffer objects (VBO’s). I need to know the size so I can allocate some for VBO’s and leave some for textures. I’m programming on linux.

There is no such function in OpenGL that would tell you what the limit is. OpenGL will tell you that you ran out of memory (if you do) but that’s it.

So can I just request buffers of say 64MB chunks, until the allocation request fails and then I’ll know what the size is, even though I haven’t tried to write anything to them.

So can I just request buffers of say 64MB chunks, until the allocation request fails and then I’ll know what the size is, even though I haven’t tried to write anything to them.
You could, but that’d be incredibly error-prone.

An implementation is not required to put buffer objects in any particular location. Video memory, system memory, AGP, etc, the implementation can put them anywhere. More intelligent implementations may report, under your method, that 4GB (32-bit address space) of memory is available.

Your best bet is to not care. Pick a specific limit on the total size of your buffer objects and stick to it.

You can get an estimate of the total video memory through your platform’s API (in the case of Windows, that would be IDXDiag/WMI). With the total memory in hand, you could then develop a sensible allocation strategy. Graphics memory is generally a shared resource, so at any one time VBOs, FBOs, textures, shaders, and so on may occupy graphics memory in fluctuating proportions, depending on the application’s usage patterns; and in the case of eviction, one or more objects may need to be moved to or from AGP memory or even system memory. To make matters worse, this same memory is shared among all applications running on a given system (although this can be alleviated somewhat for fullscreen applications). In short, because of the inherently volatile nature of memory allocation, coupled with driver optimization policies, such a request would be impractical and arguably useless to honor. This impracticality only seems to be magnified in the face of further memory virtualization in the future.

I think some professional grade cards have memories dedicated to various resources, such as textures. But even in such a case, given that the driver can pull from AGP/system memory, which itself is a shared commodity, leaves one wondering what would be the “total” at any one point in time.

Ok. So I’ll just pick a value like 256MB and use that. Thanks for all your inputs.

If you’re using index buffers as well, you can do some approximations of what a good vbo size would be. Indices in index buffers should be 16 bit if possible, to save space and do faster memcopies, …
So your VBOs should only contain 65535 different vertices. Ideally your vertex-size (xyzw+normals+texcoords+colors+…) should be a multiple of 32 bytes, so probably add some dummy data if it’s not. Multiplying vertex-size with 65535 gives a good idea of how big a vbo in your app could be. This results in (relatively) small VBOs with a size about 12MB when using a lot of vertex-attributes. This worked out really good in my applications, but it always depends on the current scenario. 256MB is definitely too big of a size, just consider the case, that this huge VBO has to be moved from graphics memory over the bus into system-memory (AGP or whatever), because your running out of memory on the card…

Keep in mind that switching the buffer is cheap, calling glVertexPointer(…) is not.

Sorry. When I said 256MB of VBO’s I meant total. My application uses VBO’s of approximately 1MB each, and I wish to allocate anywhere between 100 and 400 of them. So I’ll start at say 100 and move to 200 and profile it to see how the performance is.

You could always ask the user too.