PDA

View Full Version : OpenGL Profiler


Nick
2005.03.28, 10:22 PM
I'm trying to use the profiler to fine tune my program and figure out why my program runs at 14fps normal and 20-22 when zoomed in (there's no drawing of the player mesh when zoomed in). I don't see why the numbers are so slow considering my use of display lists.

Can someone help explain the statistics window and others in the profiler so I can figure out what I should look for and be worried about? Right now I just see a bunch of numbers that really don't mean much to me.

OneSadCookie
2005.03.28, 10:29 PM
Start with Shark, you don't even know that OpenGL is your problem yet. That will tell you a) how much CPU time you're using ( less than 100% is bad ;) ) and b) which functions are taking all your time. If it turns out that you are using all the CPU time and the top most expensive functions are in GL, then it's time to break out the OpenGL profiler.

Nick
2005.03.28, 11:18 PM
Well in Shark I found that 32.4% of my time is being spent on something called gldGetString and 8.2% on gldUpdateDispatch and 7.8% on gldGetQueryInfo all coming from ATIRadeon9700GLDriver. What does this mean and how can I take care of this? Or is this not a bad thing? Quite frankly, optimization sucks and it confuses me.

Nick
2005.03.28, 11:21 PM
Spoke to soon. After opening a ton of trees, I found my Mesh::Draw() function to be the first mentioned. Here's the code for it so I'm not sure how to optimize it.


void Draw()
{
glPushMatrix();
glTranslatef(translate.GetX(),translate.GetY(),tra nslate.GetZ());
glRotated(rotateAngle,rotate.GetX(),rotate.GetY(), rotate.GetZ());
glScalef(scale.GetX(),scale.GetY(),scale.GetZ());
glCallList(list);
glPopMatrix();
}


Any suggestions? It's called every frame for rendering but maybe that's not how I should do it.

Nick
2005.03.28, 11:57 PM
The program points to my glCallList(list) as being 99.9% of the problem. It says "This function is relatively long, but it has a large number of samples in its function prologue and/or epilogue. This means that the function might have an early exit condition. To improve performance, have calling functions check for the early exit condition themselves before making a call to this function." That doesn't make sense to me. What does that mean?

OneSadCookie
2005.03.29, 12:09 AM
it does sound like glCallList is taking a lot of time.

How many triangles are in your list?

How many times are you calling glCallList each frame?

arekkusu
2005.03.29, 01:24 AM
( less than 100% is bad ;) )
While this is probably true in this case, it's not a truism.

If you're GPU limited, you should be using as little CPU as possible.

OneSadCookie
2005.03.29, 02:00 AM
really, you should be shooting for 100% CPU and 100% GPU usage on your minimum spec hardware, for "action" games at least. If you're not using 100% of both, you can either do more work (better AI or physics, or prettier graphics), or one is a bottlneck holding the other back, and you need to do some optimization.

obviously, you're never going to manager 100% CPU and 100% GPU usage on all hardware, particularly not once you turn on vsync, but it's a good target to aim for.

wadesworld
2005.03.29, 02:28 AM
gld calls are generally a red herring in Shark. That is to say, Shark doesn't really have any way to profile the OpenGL driver. So until you've looked at absolutely every other part of your application, ignore the gld stuff. Once you're sure OpenGL is your problem, use OpenGL profiler, not Shark to optimize the OpenGL.

Wade

arekkusu
2005.03.29, 04:15 AM
If you're not using 100% of both, you can either do more work, or one is a bottlneck holding the other back.
That's true, if your app is a moving target.

I was thinking of an application where, for example, I know I must blend 10,000 fullscreen quads on top of each other every frame.

Nick
2005.03.29, 08:45 AM
gld calls are generally a red herring in Shark. That is to say, Shark doesn't really have any way to profile the OpenGL driver. So until you've looked at absolutely every other part of your application, ignore the gld stuff. Once you're sure OpenGL is your problem, use OpenGL profiler, not Shark to optimize the OpenGL.

Well everything that even has a percent leads back to that function with the weird 'early exit' message. What does that message mean?

And how do I use profiler? Shark was nice to use but I don't understand why my program doesn't really run in profiler.

Nick
2005.03.29, 09:14 AM
In profiler, I found that CGLFlushDrawable is like 98% of everything. That's great. What does that mean? I never made a call to that function so I'm not sure how to optimize it. Any advice?

OneSadCookie
2005.03.29, 03:09 PM
CGLFlushDrawable is SwapBuffers. Spending all your time there usually means that you're rendering too fast for the graphics card...

Nick
2005.03.29, 06:02 PM
really? What can I do to fix that? I'm only rendering the scene once per frame with vsync on so it's limited. I'll try some things. Advice, please?

OneSadCookie
2005.03.29, 06:47 PM
ah, vsync. Try turning that off for debugging purposes.

Nick
2005.03.29, 09:56 PM
Well I've tried a bunch of things. I turned off vsync but that didn't help framerates or debugging with Shark. OpenGL profiler crashed when I tried to use it so I decided to upload the file and see if anyone can help me out (and get a sneak peek at the work we've been doing). There's a preference text file with in the zip where you can change the screen dimensions, choose fullscreen, and choose vsync. Just be careful to keep the formatting of the file the same. It does check for proper window sizes so it shut down if you give it incorrect screen dimensions.

You can download it here thanks to DanLab and his generous donation of webspace to my need. Thanks A Ton! (simreality.playmacgames.com/The%20City.zip)