PerfHUD ES has a good online manual that I’m not trying to replicate. The manual explains the UI, graphs and knobs. The purpose of this article is to introduce the tool to people that aren’t aware of it as well as to provide more details behind the directed tests section. Specifically, how to make your game faster based on the results you get from the directed tests.
To enable perfhud, in a shell run:
adb shell setprop debug.perfhudes 1
Then fire up your game, launch perfhud and connect to your device.
The frame debugger is so incredibly useful and awesome that it’s hard to describe it all. Here are the top reasons.
When you see every single draw call and exactly what it is drawing it is amazing. You will discover things that you didn’t know were in your scene, things that shouldn’t be visible and other amazing stuff.
Yes, you can fully inspect geometry. This can be incredibly useful for validating your mesh frustum culling. You can even take a peak at games that you don’t have source to and reverse engineer special FX!
With the texture viewer, you can validate mipmaps and check your texture compression. Seriously, amazing.
You can view all the shaders used in your game in this tab. You can see exactly which draw call(s) use them, how expensive the shaders are and can even replace the shaders on the fly.
I found this incredibly useful when tracking down expensive shaders. I would simply hot-replace a shader with a barebones shader to see if my performance increased.
The directed tests area is where you’ll solve most of your performance problems. The test methodology here is:
If your FPS made a noticeable increase, then you now know what area your problem is in. If not, continue to the next test. We’re not going to cover all of these because frankly as someone who uses a game engine, I’ve never found the last 5 options helpful in solving performance issues. For each of these checkboxes, we are going to answer 2 fundamental questions:
Note that performance is a very complicated subject. Anytime you see the word is replace it with is most likely and imagine me making little quotation signs in the air with my hands.
Replaces all game textures with a texture measuring 2 pixels x 2 pixels.
If this increases your framerate then your bottleneck is most likely in the texture unit. Look at eliminating this bottleneck by the most common methods:
Stops drawing to the screen by ignoring all DrawArrays and DrawElements calls. Essentially simulates having the fastest possible GPU that could ever exist. This is a good test to determine whether you might be CPU bottlenecked.
There are certainly 2 sides to the draw call coin. If FPS does not improve when checking this, you have a CPU bottleneck. If you are CPU bound then you need to take a good look at your code. Basically stop here, you need a different set of profiling tools to help you find the code at fault. Look to your debugger or do a simple pause test to track down the offending code and then apply optimization recommendations for your specific language.
If FPS improves then you have a GPU limitation. Some of the other tests will hopefully narrow down which specific GPU bottleneck you have. If you’ve exhausted the other GPU tests without any improvement, then you may fall into 2 additional cases.
You are simply drawing too much geometry. You should try to:
You are trying to draw too much in a single frame. You should:
Prevents calls to eglSwapInterval from locking the framerate. This allows seeing the true framerate of your game rather than, for instance, a max of 60 fps. On mobile, this option has not been very helpful to me.
If vsync is making a significant difference, then you can look to your engine docs to determine whether it can be disabled. There’s always the visual tradeoff here (screen tearing vs slight fps increase) on the PC. I know that on iOS, you cannot disable vsync. I am unsure if you can disable vsync on Android, it may be device or vendor specific.
Replaces all fragment shaders with a simple and fast fragment shader.
If your fps improves then your fragment shaders are too complex. If you are working in a game engine like ShiVa 3D then this means that you are doing a little too much in terms of materials and effects:
Where Ignore Draw Calls just waits for draw calls and throws them on the floor, Null Viewport still renders everything but at an infinitesimally small size.
Drill down into specific tests Blending, Fragment Shader, 22 Textures. If none of these are increasing your framerate, look at draw calls, polycount or disabling post-processing effects.
Prevents all alpha-blended drawing. Arguably one of the most handy checkboxes. Not only does it let you see if you are getting hit by overdraw, but it also visually shows you the areas where overdraw is happening in your game.
Uhh, get rid of alpha blending! This could mean: