VBO max vertices?

Ive been running a simple test program with VBO’s on my system

When i have 3300 vertices passed into the VBO i get 85FPS.

WHen i have 3350 vertices passed into VBO i get 40FPS.
As i increase the vertices from there the FPS falls off dramatically so that its actually less than no VBO above 8000 FPS

Is there a way to find a limit. If i have 10000 vertices will making 3x3300 buffer object work better than the one 10000 vertices buffer objects

thanks

The answer seems to be no. I just did a test.

I got a few more vertices sqeezed in. I made 2 buffer objects of size 2200 vertices. When i make it 2300 vertices, the frame rate drops in half again. All floats.

It seems it looks for contiguous video memory blocks.

This sucks. I thought i could get a 10 Meg block of video memory for my vertex array. i have a 128Meg video card asus ati 9559. Would a 256 Meg card help?

Thanks

we never get answers to these questions. all we need is a vendor representitive to give an answer.
But the only solid solution is to benchmark at runtime - find the sweet spots the first time you run on a hardware config.

This seems strange, as I have successfully used way more vertex data on an even slower and less “feature-rich” ATI card.

It seems some (or all) h/w is only optimized for up to 64K vertices, but as you’re nowhere near that limit, and you yourself mention the card could be out of contigous space for the VBO, perhaps something of the following could work:

Test with no textures uploaded, to get a baseline of VBO speed (I created a grid of triangles forming a quad, and tested with indices in both main mem and VBO to get a reasonable understanding of my h/w).

Allocate the VBO(s) before uploading textures, perhaps increasing the chance the VBO memory is both resident and contigous.

I did a test with no textures, just vertex and color pointer data. Same result. I have an Ati RAdeon 9800 Pro 128MegDDR

Originally posted by Joe Montana:
I did a test with no textures, just vertex and color pointer data. Same result.
Then there’s something to work from.

First: are both the vertex and color data in a VBO of their own? Are both vertex and color data aligned? You do enable respective client state only after the arrays are specified (preferred order is AFAIK to first specify *Pointer() and then enable the client state)?

And, sorry for asking the obvious, but with such abysmal performance I feel I must ask: you are 100% sure you’re using h/w the ICD and not the MS?) software implementation (though even that wouldn’t stall to this extent I think, coming down to only around 120-240K (!) vertices/s)?

Final suggestion (perhaps this should have been my first suggestion): d/l and test the ATI Radeon terrain demo (comes with src. obviously).