Has anyone used the application OpenGL Profiler that is provided with the jaguar developer tools?

If so, I'm wondering if the frame rate is acutally correct. I had an application running at about 40 frames per second, until I changed the function that draws terrain to just calling a glList. Now it's 100 frames per second. My computer is decently fast, but a difference of 60 frames per second with just a display list? I don't know..

The frame rate is pretty accurate (±5 or so in my experience). If your terrain was 10K triangles or so that kind of improvement from a display list wouldn't surprise me. If it was 1K, I might still believe it.

I'll agree with OSC. Changing from immediate mode to a display list would make a huge difference.

Wade

OpenGL profiler is probably the best tool you have available when writing gl stuff. It is one of the main things that makes the Mac the best platform for opengl development

Can somebody give a short explanation on how to really use the OpenGL Profiler or point to such information. I have tried it a few times but I have to say I'm not sure how I should use it really to get any useful information from it. I can see what calls my app makes and such but how do I use it to improve performance?

KenD

It tells you where you're spending all your time (turn on function stats); either call the functions that are using all your time less, or find a more efficient way of rendering that doesn't involve them at all.

It has heaps of stuff. You just have to experiment...

Function Stats list all the function calls, how often they are called and the time spent in each, just like any other profiler. Will tell which calls you are spending the most time in.

Function Trace lists all gl function calls in order and their arguments. Use it to check that you are calling what you expect in the order you expect with the values you expect. It is surprising how often your app isn't doing what you thought.

The driver graph shows you your driver resource usage in realtime. Use to check texture vram usage, agp usage, hardware wait times ( parallelism, or lack of), etc.

Breakpoints allows you to set breakpoints on gl calls and then query the state before and after the call. Makes very interesting reading.

I have looked at the function stats and from that I have been able to replace some less efficient calls with better ones. But as henryj says, I just need to jump in and experiment more with it.

On a related note: Shikari is pretty interesting too. Can be quite shocking sometimes to find out how many stalls a function can have.

KenD

Shikari is an excellent tool. You should have both open together when doing os x dev. Shikari assumes a level of assembler knowledge though to get the best from it.

Yeah, the assembler part is no problem but some functions just show up as unknown. I don't remember the exact wording right now but they aren't shown with the function name. This is a bit annoying especially when it's one of the functions that uses most of the CPU time and tracking down which one it is is not a simple task.
Don't know if this is a Shickari bug but I saw somewhere that it could be caused by inlined functions. Haven't tried to find out if that is the case though.

But I have cleaned out quite a lot of stalls with the help of Shikari. By reorganizing the code a little you can help the compiler to do a better job.

KenD

Ahh... for some reason now, my app isn't running in OpenGL Profiler. I'm getting a exit status of 11. What is that?

I think that's a segfault... it means you applications crashed, probably because you blew a boundary somewhere. Run it through a debugger, and hope for the best. HTH!