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.
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).