I have a bunch of textured triangles that I want to draw. The triangles make use of indexed vertex, and texture coordinates (glVertexPointer…). At this moment I’m using glDrawElements() with GL_TRIANGLES to render them. Would it be worth the effort of rearranging the vertex and texture information so that I can use glDrawArrays() instead? is glDrawArrays() a lot faster?
Greetings,
Quite the contrary, I think. To name just one thing: if you use indexed arrays, you can exploit the vertex cache on T&L cards.
I found a 10% slow down using glDrawArrays over normal intermediate mode.
I find this strange. Thought you’d have at least saved some thousands of function calls.
On hardware T&L cards, glDrawArrays should be faster than glDrawElements IF
The reasoning being that with drawElements, if the verticies dont stay in the cache long enough to be reused, you need to transform them anyway (just like with glDrawArrays) but now you ALSO consume bandwidth transferring the indicies.
I will admit I havent verified this, but by my logic this should be the case (unless there are hardware design issues that would dictate otherwise).
Originally posted by Tim Stirling:
I found a 10% slow down using glDrawArrays over normal intermediate mode.
This is strange. The only explanation I might have is:
In D3D, if you submit polys in small enough quantities, the runtime will hold onto your verticies until it has enough polys and then make a single “call” to the hardware. In this case, this can be an advantage because a kernel mode transition can be quite expensive.
If it is the case that the openGL driver also provides this type of batching for immediate mode calls, it might end up batching more efficiently that you and thus perform better.
Of course you could also be doing something horribly wrong in your code.
DrawArrays should certainly be faster than immediate mode in most circumstances. It should be faster than DrawElements in all cases where there is little or no vertex reuse.
To analyze further, I’d need more information.
I am glad people are taking an interest with this now. I posted a load of strange speed tests in the beginers forum a few weeks ago and got no real explanation. The test may not have been the best and most acurate, FPS for drawing a 10000 array = 20000 triangles. It was drawn with a variety of methods and most returned fairly normal results but there were a lot of strange ones. One was the fact that using GL_QUADS was nearly twice as fast as using a GL_TRIANGLE_STRIP to draw each individual quad of the array. Another vary surprising thing was that a single call to GL_TRIANGLES to draw the lot in a Display List was a lot slower than if it wasn’t in a display list! . I tried with/without texturing and in wireframe and solid and the results were fairly consistent.
I did get a good speed increase using glDrawElements though. I also have someone elses speed test program and it also shows a 5% decrease in performance using glDrawArrays. These tests may not be very acurate or I might not be implementing it very well so I might make another better test program once I have finished making my octree class. Oh and the gfx card is a TNT2 m64 32MB with the latest Nvidia drivers. One last question; What is the best OpenGL optermisation you can do with an octree- Display List would have to be per a leaf, glDrawArrays could work, as could glDrawElements. But then there is the problem of sorting the textures but also I want to sort the geometry types so I can have a single call to GL_TRIANGLES, GL_QUADS etc. I would also want to draw front to back order to maxamize the z buffer efficiency. I don’t really know what should be done.
[This message has been edited by Tim Stirling (edited 05-24-2001).]