PDA

View Full Version : DL Speed dependent on how compiled?



Furrage
03-12-2002, 09:16 AM
Does the speed of a display list depend on how the image was compiled in it. Say I have a complex image which I have placed in a display list. Will the speed of the DL be affected by the choice of commands I used to draw the image (i.e GL_TRIANGLES vs. GL_TRIANGLE_FAN or GL_QUADS vs GL_QUAD_STRIP) ?

Also, I just wanted to confirm. Can you use vertex arrays to create display lists? If so is there an advantage to using that vs the methods listed above?

Omaha
03-12-2002, 10:09 AM
Yes, I would think that your choice of primitives inside the display list would affect the display list's efficiency just as it would if you do the same calls in immediate mode; you pass more vertices with some of them and thus spend more time.

Also, I think you meant that last question the other way around, as far as "[using] vertex arrays to create display lists." If memory serves, display lists are stored serverside and vertex arrays are stored on the client. You can't enable vertex/texture/whatever errays in display lists, but you can call the draw functions. Subsequent changes to the associated arrays will not appear when you call your vertex-array-drawing display list later, though!

Rob The Bloke
03-12-2002, 12:19 PM
Ultimately display list performance is fast. I've never seen any difference when using GL_TRIANGLE_STRIP, or GL_POLYGON etc. (wirframe or lined versions are the exception) I presume this is due to the graphics hardware splitting the geometry to triangles on input anyway, thus storing the compiled display list will be a minimal set of data to make the object.

zeckensack
03-12-2002, 12:42 PM
Hurrrmmm, I'd say GL_TRIANGLE_STRIP is still the fastest primitive. It would be an utterly stupid driver, if it were any different. Why send three times the geometry data (hog my bus!)when the application has already lined it up nicely.

If you reuse vertices, also have a look at glDrawElements. When you embed it into a display list anyway, you won't have to look into the rather arcane DRE/VAR/CVA stuff to get good performance.

wis
03-14-2002, 03:54 AM
I've made some performance tests yesterday :-) DL with tristrips or VAs (compiled and uncompiled) are equally fast, DL with quads are slower.
DL versus compiled VAs without DL: DL is about 60% faster, for those how care.
I've tested with 256x256 terrain, no culling, on a gf2gts with detonator 21.83, cpu: celeron 950

Furrage
03-14-2002, 05:02 AM
Nice results wis. Thanks everyone.

wis
03-14-2002, 06:37 AM
I think this might be of some interest too...

I've just changed tristrips to quadstrips and got an extraboost from 70 fps to 81 fps!!!

So it seems quads aren't as bad as I thaught http://www.opengl.org/discussion_boards/ubb/biggrin.gif

03-14-2002, 07:39 AM
Originally posted by wis:
DL versus compiled VAs without DL: DL is about 60% faster, for those how care.


Is that Display Lists with Vertex Arrays? Or just straight display lists? I just wanna be sure, because I might stick in some display lists for some of my static geometry if I can get a 60% speed increase http://www.opengl.org/discussion_boards/ubb/smile.gif

wis
03-15-2002, 01:08 AM
To sum up my performance tests with my system:
The fastest way of rendering the terrain was:

Display List with Quad Strips

If the Quad Strips are build with VAs or with glBegin(GL_QUAD_STRIP); ... glEnd(); just doesn't matter.

However I haven't tried GL_NV_vertex_array_range, might be faster, and it's dynamic, but the drawback is: I think only NVIDIA has implemented it in GeForce class.

I strongly recommend you though to do your own perfomance tests (and post them in the forum :-)), because the way of transforming polygons is a very important decision and 60% is what I have measured.

zeckensack
03-15-2002, 01:58 AM
Originally posted by wis:
The fastest way of rendering the terrain was:

Display List with Quad StripsEhrm, quads should be planar, you didn't forget that, eh?

Originally posted by wis:
However I haven't tried GL_NV_vertex_array_range, might be faster, and it's dynamic, but the drawback is: I think only NVIDIA has implemented it in GeForce class.
EXT_draw_range_elements is somewhat similar and available on a wider range of hardware. Performance increases a bit when used in conjunction with EXT_compiled_vertex_array.

wis
03-15-2002, 07:06 AM
no I haven't forget that...

Should I place the ext_compiled_range thing in list or not and does that lead to optimum speed? (if that exists :-) )

zeckensack
03-15-2002, 07:21 AM
Originally posted by wis:
no I haven't forget that...

Should I place the ext_compiled_range thing in list or not and does that lead to optimum speed? (if that exists :-) )

This stuff is really meant for dynamic geometry, not lists which are best used for static stuff.

In theory, you need none of the measures when you're working with display lists. The driver should be able to automatically choose the optimum path - using indexed geometry still helps with display lists though. At least that's what is was like for me, YMMV.

bChambers
03-15-2002, 07:32 AM
Originally posted by Furrage:
Does the speed of a display list depend on how the image was compiled in it. Say I have a complex image which I have placed in a display list. Will the speed of the DL be affected by the choice of commands I used to draw the image (i.e GL_TRIANGLES vs. GL_TRIANGLE_FAN or GL_QUADS vs GL_QUAD?

Doesn't matter. The driver compiles your data into the fastest form for your particular card. (Of course, TRI's vs QUAD's could still make a difference, but GL_TRIANGLES vs GL_TRIANGLE_STRIP should be identical). At least, that's how NVidia does it (see their GL faq) - can't say about other brands, but I would assume it's the same.

...Chambers

wis
03-16-2002, 12:01 AM
Sorry, but that simply isn't true!

DisLis with QuadStrips: 81 FPS
DisLis with Quads: 20 FPS

Optimasation doesn't seem to get so far, Strips are faster than no-strips even in DisLis.
Go and do your own measurements, should take only a couple of minutes and by the way I think one should better do some measures than to believe some fancy FAQs without proving anything!