glDrawElements slower than glColor* + glVertex*

In the attempt to get a speed increase by removing the overhead of hundreds of glcolor* and glvertex* calls, I started using vertex arrays with a single call to glDrawElements to draw a triangle strip. I repeat this 10 times a frame(reload the vertex buffer then call glDrawElements). To my surprise, this actually draws slower!!! I get the same behavior with and without hardware acceleration. Anyone know why?!?!?!

J

All depends on the driver’s optimizations.

Sometimes, if a format hasn’t been optimized in a driver, the driver will effectively convert your vertex array call into internal immediate mode calls. (Yuck!)

  • Matt

Yes, that’s what I am guessing is happening(yuck! is right).

This leads me to believe there exist no options to optimize this code(display lists are out of the question). Someone please tell me I’m wrong

J

Matt -

Just re-read your post. By “format” do you mean float/double/byte/etc? Is it possible there’s a better way to specify my vertex data to allow this to be optimal?

thanks

J

Also the used arrays should play into it, like if you’re using the Normal array or all the others. At least that is, if I’m following Matt correctly.

All I’m using is the color array and vertex array. Are you saying the number of arrays I use should make a difference?

Everything – the arrays in use, the data type for each array, and the number of components for each array. Sometimes also the stride.

  • Matt

Alright…the natural question that follows:

What can I do to get this optimized???

J

I can help you if it’s NVIDIA HW, but if not, not much I can do. I’d need to know the specific format you are using, the HW, the driver version, and the DrawElements parameters.

  • Matt

Also make sure that you fill your vertex
buffers correctly, because it is uncached
memory and writes are VERY EXPENSIVE (but
works out OK if you write serially, dword
or qword size chunks at a time).

If you’re re-filling the geometry ten times
a frame, it seems your vertex buffer is too
small. Ideally, you’ll be able to allocate
enough vertex buffer space to hold your
entire geometry, load it once at scene
prepare, and then just issue indexed drawing
commands, not touching the vertex data at
all (same goes for color, normals, texcoords
etc).

Uhhh… I didn’t see anything about VAR, so I’m assuming that’s not being used here.

Unless it is, this is plain old cached system memory…

  • Matt

bgl:

what do you mean by “fill my buffers correctly”. You mean just because the time it takes to write into the buffers? Right now I’m looking only at the time to draw using vertex arrays vs. immediate mode. Not looking at the overhead of filling the buffers. Also - If I understand Matt correctly, he is correct. My vertex and color array are in system memory. I’m trying to optimize my code for software rendering(and it must be multi-platform) which is why I’m not using any extensions and also why I’m using OGL. Maybe it’s not the best way, though. What I’m working on is a 3d-type graph which has ten plots of ~2000 data points(thus 4000 verticies for drawing triangle strips for each plot)…I don’t know what the optimal size of a vertex array is, but I figure 40,000 verticies may be too large. Then again, maybe because I’m working in software this is all moot.

J

[This message has been edited by drumminj (edited 11-17-2000).]