Display lists memory overhead?

I’m writing a massive model rendering engine, and I was planning to make heavy use of display lists. Before I dig in, though, I’d like to know what kind of memory overhead a display list introduces, and what happens if not all display lists can be kept in RAM (the scenes I have to deal with can contain upwards of 1 million polygons).

FIY, the engine will have to run on standard PC hardware, so there won’t be any dedicated memory for display lists. Also, there will be display list nesting to about 5 levels deep.

Does anyone know more about how and where display lists are stored? Thanks,

Tom Nuydens
VRcontext (www.vrcontext.com)

Display lists storage area and format depend on the board manufacturer drivers.
You cannot know where or in which format they are stored, AFAIK.

[This message has been edited by Ingenu (edited 10-11-2000).]

I originally wrote my app to use display lists until I hit memory problems.
When the app ran out of memory it hammered the hard disk and the frame rate
dropped to 0.1 fps. Also the time it took to generate the display list increased significantly when it ran out of memory. I think the problems started at about the 1 million poly mark.

This was on a standard P.C. with 128mb of ram.

Because the implementation of display lists is completely hidden, it’s impossible to tell how they will perform (except with empirical evidence).

Very big DLs are also tough, because of extra memory management burden they place on the driver. You may get good/better performance than rolling your own vertex arrays, but it’s unlikely. Particularly if you use vendor-specific extensions like NV_vertex_array_range and NV_fence.

Thanks -

A possible solution, though not on every situation is to use nested display lists. In this way some display lists will be reused and you wont need to have a huge display list.

Antonio www.fatech.com/tech

Thanks for the comments, everybody!

Maybe I can elaborate a bit on what I wanted to do. I have an octree, where each leaf node contains around 1000 polys. I figured I’d create a display list for every node (not just the leaves), so that if I figure out that a node is entirely visible, I can render it in one go without having to traverse further down to leaf level. So the leaves would contain display lists containing the geometry, and the other nodes would just encapsulate the lists of the leaves that are below them.

If using such a large amount of display lists will bog down my drivers, I could use vertex arrays instead - but I’d want to find a good way to handle the nesting, so I don’t have to walk all the way down to the octree leaves all the time. Any ideas on this?


Speaking of display lists, If I have a simple object made of 50 triangles, and I usually render 1-10 of them on the screen. Should I use a display list for it? Right now I’m just drawing them with normal gl calls.


Unless you’re planning to implement some scheme to determine visibility, like octtres then display lists won’t hurt, and they will most likely improve the performance.

Antonio www.fatech.com/tech