OpenGL profiler & display lists

Moderator
Posts: 434
Joined: 2002.09
Post: #1
I just added display lists to my game and got a nice speedup. However, the OpenGL Profiler now reports that 95% of the time [in OpenGL calls] is being spent in glCallList. Sounds good, but it doesn't give me much to work with for future performance improvements. I think the display list mechanism will prevent me from seeing how much of the time is being spent on various types of operations _within_ each call to the display list.

Now reducing the number of polygons being displayed at a given time is the most obvious speedup, and I am working on that. But it would be nice to know if I hit some bottleneck with a particular function so I can learn what to avoid. I suppose I could turn off display lists for now, then turn them on again after other tuning efforts. Does anyone have any other suggestions or techniques for dealing with this?

I'd also welcome pointers to any other hints for using the OpenGL profiler effectively. (Beyond the obvious strategy, that is, which is to look at where all the time is being spent in the function stats and then try to reduce where it will do the most good.)

Thanks!

Measure twice, cut once, curse three or four times.
Quote this message in a reply
Luminary
Posts: 5,143
Joined: 2002.04
Post: #2
Whilst 95% of your GL time may be being spent in display lists, that means little... has the amount of time you spend in GL gone up or down?

Display lists on Jaguar can be very fast, in that they'll do things like put vertex data in VRAM. Just be aware that if you're doing things in a silly order you can make the display list compiler drop back to stupid mode.

Also be aware that the overhead of a glCallList is quite large. If you can call multiple lists at once glCallLists is better, but for small amounts of geometry you may be better off avoiding using a display list. Profile Wink
Quote this message in a reply
Moderator
Posts: 434
Joined: 2002.09
Post: #3
Quote:Originally posted by OneSadCookie
Whilst 95% of your GL time may be being spent in display lists, that means little... has the amount of time you spend in GL gone up or down?


Time spent in OGL calls is about the same (the application is in a tight loop, most of the time is spent drawing.) Frame rate is much higher with display lists (though I can think of a parallel change I was forced to make that might also have improved the speed.) But to improve further I may need to know where glCallList is spending all it's time. Should I add vertex arrays? Is something inefficient in my texture or lighting code? Can't say, the display lists hide it all.

For now I've got some obvious optimizations to try that will reduce the total number of polygons drawn (lod, limit the viewing distance.)
Quote:
Just be aware that if you're doing things in a silly order you can make the display list compiler drop back to stupid mode.
How would I know? I may be in stupid mode already! I'll search around for info about how to use display lists effectively, particularly under Jaguar. I imagine Apple has a tech note, or probably there was a discussion about it on Apple's OpenGL mailing list.

Thanks for the feedback!

Measure twice, cut once, curse three or four times.
Quote this message in a reply
Mars_999
Unregistered
 
Post: #4
Are you calling a lot of functions in your lists? If so you might have maxxed out the CPU. I did.

Are you doing things like this?
Code:
//list generation stuff and setup already done

for(int y = 0; y < 256; y++)
{
for(int x = 0; x < 256; x++)
{
//maybe a glBindTexure()??
glBegin(GL_TRIANGLES);
glTexCoord2f(); glVertex3f(); glNormal();
glTexCoord2f(); glVertex3f(); glNormal();
glTexCoord2f(); glVertex3f(); glNormal();
//are you using multitexturing???
glEnd();
}
}

If that is kind of what your code looks like in the display list than you could be running out of CPU. That is a lot of function calls and you might be doing more than that if you add in other features.
Quote this message in a reply
Moderator
Posts: 434
Joined: 2002.09
Post: #5
Quote:Originally posted by Mars_999
Are you calling a lot of functions in your lists? If so you might have maxxed out the CPU. I did.


It's very possible. I am drawing lots of fairly simple objects (spheres) but there is also lighting and normals for each vertex of each sphere. (Soon, textures as well.) I tried it a few ways so far:

1- creating a gluQuadric each time I wanted to draw a sphere (pure laziness while I got the graphics running for the first time)
2- creating a display list for a single sphere with normals and lighting; calling it for each sphere drawn
3- creating a single display list to draw all spheres in the scene

The last was an experiment to see what overhead I was getting with calling a simple display list thousands of times, but 2 was still faster than 3.

I don't know how efficient gluQuadric spheres are when put in display lists; it's possible I could get a speedup by creating my own vertex array representation of a sphere with normals and texture coordinates. Something to look into, especially as I hope to move away from perfect spheres if time allows. I may even find that drawing the array without a display list is faster. But for now, I'm accepting the "lazy" speedup of using a display list and will break down the drawing further if time permits.

In my experiments, the game slows down linearly with the number of polygons I'm drawing. So I'm getting speedups currently by reducing the level of detail when the spheres are far away, and fogging out and clipping out spheres that are even farther away.

Quote:
If that is kind of what your code looks like in the display list than you could be running out of CPU. That is a lot of function calls and you might be doing more than that if you add in other features.
I think it's similar enough to what I'm doing that it might be worth comparing notes, though I'm not going vertex-by-vertex because I'm using a single GLU call to draw the sphere.

Have you tackled this problem yourself? Vertex arrays seem to be the most often recommended solution; I was using display lists because I read that the data can get stored by OpenGL in an internal, partially processed format so you should theoretically lose some of the overhead of the function calls. (Also, it's an easy conversion to add display lists to working code.) I'll try them in combination if time allows.

Which leads in a roundabout way to my original question about using the profiler effectively. If the CPU is maxed out and the card isn't, probably the typical scenario for inexperienced OpenGL programmers like me, I obviously want to find ways to offload the work. How do I tell who's bottlenecked? I'm taking profiler snapshots as I go so I may be able to learn some of this on-the-fly, but hints are always appreciated.

Measure twice, cut once, curse three or four times.
Quote this message in a reply
Moderator
Posts: 434
Joined: 2002.09
Post: #6
Incidentally, Mars_999, I just found your latest comments in the OpenGL Performance thread, so no need to recap that here. I'll add VARs and VBOs to the list of things to play with, as time permits.

Measure twice, cut once, curse three or four times.
Quote this message in a reply
Mars_999
Unregistered
 
Post: #7
If you are playing around with spheres using gluSphere() I don't know for 100% but think you will not be able to use them with vertex arrays or VBO's. You will have to come up with an algorithm to make a sphere and store that data in either vertex arrays or VBO's. If you plan on doing serious OpenGL programming I suggest getting to know vertex arrays and when Mac gets them VBO's. If I remember right the rule is arrays should be as fast as display list or faster. Display lists are nice for expensive state changes. e.g. Matrix, ect...
Quote this message in a reply
Moderator
Posts: 434
Joined: 2002.09
Post: #8
Quote:Originally posted by Mars_999
If you are playing around with spheres using gluSphere() I don't know for 100% but think you will not be able to use them with vertex arrays or VBO's. You will have to come up with an algorithm to make a sphere and store that data in either vertex arrays or VBO's. If you plan on doing serious OpenGL programming I suggest getting to know vertex arrays and when Mac gets them VBO's. If I remember right the rule is arrays should be as fast as display list or faster. Display lists are nice for expensive state changes. e.g. Matrix, ect...


Thanks for the tips. You are right, gluSphere doesn't expose the innards so you can't get vertex arrays out of them. But spheres aren't hard to generate; there may even be an example in the red book. I just didn't want to be bothered with calculating normals and texture coordinates myself until I'm further along with the game itself. Fingers crossed, I'll revisit vertex arrays soon and toss out the GLU code.

Measure twice, cut once, curse three or four times.
Quote this message in a reply
Mars_999
Unregistered
 
Post: #9
Quote:Originally posted by MattDiamond
Thanks for the tips. You are right, gluSphere doesn't expose the innards so you can't get vertex arrays out of them. But spheres aren't hard to generate; there may even be an example in the red book. I just didn't want to be bothered with calculating normals and texture coordinates myself until I'm further along with the game itself. Fingers crossed, I'll revisit vertex arrays soon and toss out the GLU code.


Hehe yeah making a sphere with glu is extremely easy. But coding one yourself now thats another story! Lots of math. I don't know for sure because I haven't looked into the code for gluSphere() but if they don't use vertex arrays or a display list you could stand to gain speed by coding your own sphere algorithm.

Have fun! I know I am. Terrain engine is moving along nicely. Muahahhaah
Quote this message in a reply
Moderator
Posts: 434
Joined: 2002.09
Post: #10
Quote:Originally posted by Mars_999
Hehe yeah making a sphere with glu is extremely easy. But coding one yourself now thats another story! Lots of math.


Turns out it's a classic application for a subdivision algorithm so there's an example in the Red Book. (Actually, the straight icosohedron code in chapter two would be more than sufficient because I don't need my objects to be very smooth.) Texture coordinates are the only difficulty, and I think I can tackle that. But first I have some culling optimizations to do...

I _am_ having fun, as long as I don't think too hard about the impending deadline and the other tasks left to do. Your comments are most appreciated.

Measure twice, cut once, curse three or four times.
Quote this message in a reply
Post Reply 

Possibly Related Threads...
Thread: Author Replies: Views: Last Post
  display link to drive opengl loop? alloca 21 8,848 Jan 21, 2009 10:56 PM
Last Post: arekkusu
  Display Lists and Obj. File Loader Problems merrill541 0 1,935 Oct 17, 2008 06:42 PM
Last Post: merrill541
  Is the profiler lying/can GL use previous binds/will... Jones 50 15,967 Sep 26, 2006 03:53 PM
Last Post: akb825
  OpenGL profiler 3.2 - 0.0 Frame Rate? kelvin 0 2,488 Mar 3, 2006 01:21 AM
Last Post: kelvin
  Display Lists or Vertex Arrays with texturing seven 6 3,797 Oct 17, 2005 09:24 AM
Last Post: seven