Roots of Display List Overhead

Moderator
Posts: 522
Joined: 2002.04
Post: #1
What are the reasons behind there being a lot of overhead for using display lists? If a display list has been created and the system has a lot of VRAM at its disposal, what's left generating overhead for glCallList()? The graphics card should have all that it needs sitting right there, right?

Here is the only discussion I was able to find about it:
http://developer.apple.com/graphicsimagi...gdata.html
http://www.idevgames.com/forum/showthread.php?t=7992

Can anyone point me to some reading material to learn about this more in depth?

Thanks
-Jon
Quote this message in a reply
Member
Posts: 198
Joined: 2005.01
Post: #2
A friend at the local IGDA group told me that there are issues in OSX with using display lists where it will sometimes not actually cache it like you expect, and it can actually turn out to be slower than just sending the primitives again. One of those links alludes to that. Wish I could remember exactly what it was. Annoyed We've got a meeting coming up next week, I can ask him about it again.

Cryptic Allusion Games / Cryptic Allusion, LLC
http://www.cagames.com/
Quote this message in a reply
Member
Posts: 198
Joined: 2005.01
Post: #3
Ok, here is the deal... I asked my friend about that, and he said the primary thing that causes slow display lists (at least in theory) is nested display lists. Like if you make list A, and then while making list B, you call list A. He said that OpenGL display lists are implemented in OSX by using object buffers, where nesting doesn't really make a lot of sense. So.. it ends up basically replaying the raw primitives instead of using the nice cached data on the video card.

He also told me that after some tests he's not sure he believes all that. Grin But that was the issue in theory.

HTH...

Cryptic Allusion Games / Cryptic Allusion, LLC
http://www.cagames.com/
Quote this message in a reply
Member
Posts: 156
Joined: 2002.11
Post: #4
I've created both display lists and VARs to hold my models. Rendering with VARs is almost twice as fast as with the display lists in my case.
Quote this message in a reply
Member
Posts: 198
Joined: 2005.01
Post: #5
My friend also said that. Smile Sorry, forgot to mention it.. he converted their stuff from display lists to vertex/object buffers and it was a massive improvement. Apparently it's also possible to do nice things too like only changing a few vertices and having the video card suck that new info in automatically (and also vs having to re-upload it).

Cryptic Allusion Games / Cryptic Allusion, LLC
http://www.cagames.com/
Quote this message in a reply
spaceb
Unregistered
 
Post: #6
Interesting! I like vertex arrays better than display lists anyway, since their contents aren't set in stone once they're created. Now I know there's absolutely no reason to use display lists...
Quote this message in a reply
Member
Posts: 184
Joined: 2004.07
Post: #7
A not-completely-related but something I came across recently that I thought would be useful to mention:

Sometimes you may find that's somewhat important to remember with large arrays of vertex positions or vertex data is that the card will have caching problems if your triangles or triangle strips access vertices from that array in a seemingly random order. It can be worth it to duplicate data in order to make sure a lot of your arrays are accessed in more or less linear order. The reason I mentioned this is that I was debugging some vertex array code and wrote the same version sending immediate mode commands to a display list, and the result was actually faster because all the data was suddenly in order.
Quote this message in a reply
Member
Posts: 144
Joined: 2004.07
Post: #8
FCCovett Wrote:I've created both display lists and VARs to hold my models. Rendering with VARs is almost twice as fast as with the display lists in my case.

A couple of standard questions pertaining to this:
- How many vertices per DL/model are we talking about here?
- This is static geometry right? (no building a new DL every few frames)
- How many models are you rendering a frame (guess, as long as it's close) (glCallList() can start to hurt after a while, glCallLists() is quite a bit better if you can use it).

Thanks.
Quote this message in a reply
Member
Posts: 156
Joined: 2002.11
Post: #9
I tried that with low-poly (about 100) and high-poly models (10k), just a couple of models at a time. The models are comprised of sub-groups (2 or 3 in some cases), and there's one display list for each group. The results were pretty consistent. I didn't build display lists while rendering. Both the vertex array and the display lists were created at the time of loading the models.
Quote this message in a reply
Luminary
Posts: 5,143
Joined: 2002.04
Post: #10
did you make sure to follow apple's tips on building efficient display lists?
Quote this message in a reply
Member
Posts: 156
Joined: 2002.11
Post: #11
If you are asking me, I would say I am following 60% to 80% of what that papers says.

"First, you'll get the best performance when using more than 16 vertices per list."

The majority of the display list have more than 16 vertices, except when the model itself is very simple and has a low poly count.


"Second, in order to make the driver's job easier, provide consistent data for each vertex in a list. For example, provide normal, color, and vertex data for each vertex rather than leaving out color or normal for some vertices."

Done.


"Third, it is very important that you provide all attributes that may be dynamic within a single draw command between glBegin and the first glVertex. For example: glBegin, glVertex, glColor, glVertex cannot be optimized but glBegin, glColor, glVertex, glColor, glVertex can be optimized."

Also done, but I am leaving color out of the display lists.


"Fourth, as with all OpenGL drawing, it is very desirable to have as few state changes as possible within a display list. If you can group together your GL_TRIANGLES, GL_QUADS, GL_POINTS, and GL_LINES of similar mode and state, the display list optimizer may be able to batch them together for more efficient drawing."

Also done, although I am using a different order (GL_POINTS, GL_LINES, GL_TRIANGLES, GL_QUADS). I am not sure the order matters though.


"Finally, decomposing strips and fans into triangles and quads can also allow for more behind the scenes display list optimization."

My models don't use strips or fans, so I guess this tip doesn't apply.
Quote this message in a reply
Post Reply 

Possibly Related Threads...
Thread: Author Replies: Views: Last Post
  RTS / 2D Overhead Terrain SethWillits 3 4,920 Nov 17, 2007 08:46 PM
Last Post: Skorche
  Display list overhead TomorrowPlusX 4 4,107 Dec 20, 2004 02:13 PM
Last Post: TomorrowPlusX
  how small is a "small" display list? Diplomtennis 5 3,989 Oct 31, 2004 10:38 AM
Last Post: Hog
  display list generation honkFactory 8 3,461 Mar 13, 2003 11:39 AM
Last Post: honkFactory
  AGL and display list problem kingofsquirrels 2 2,789 Feb 16, 2003 04:18 PM
Last Post: kingofsquirrels