Does anyone have any numbers on the speed of vertex arrays relative to compiled displaylists?
I have a textured mesh with 1900 elements, referenced by 8000 indices and when rendering using glDrawElements() it takes ~250 units (95% of which is spent in the glDrawElements() call).
When rendering the same mesh as a compiled displaylist it takes ~25 units (1/10th).
This is on a GF2. Is this normal or did I screw up something?
If you aren’t using vertex_array_range_NV or compiled vertex arrays, then this makes quite a bit of sense. From what I understand, standard OpenGL vertex arrays have to transfer data when glDrawElements is called and not return until the data is copied. This data is not necessarly rendered at this moment, so it will likely have to be copied again into the hardware from this intermediate buffer.
Hence the point of vertex_array_range_NV. Essentially, you have direct access (especially since you allocated it) to the buffer. When you call glDrawElements(), all the hardware has to do is copy over your indicies and pull the data, as needed, from your vertex_array_range asynchronously.
Besides, NVIDIA’s own performance FAQ said that regular vertex arrays would be slower than display lists.
So what are people using for meshes with vertices that change every frame (skinning, etc.), short of using blended vertices in hardware (which I can’t do right now)?
If you need your vertices to change, feel free to use vertex_array_range_NV too. As long as you make sure to copy vertex data sequentially (and adhere to the pointer alignment requirements), you should get (according to NVIDIA) better than display list performance.
I’ve been reading about that extension and I think I’ll give it a try, looks like it can give me my speed-boost… hehehe…