Much like the Unity Frame Debugger, this profiler then breaks down to individual frames. However, the big difference between the Unity and Microsoft versions is that this drills down to the DirectX level, which is about as low as you go without going to assembly language and machine code:
Much like the other debuggers, you can break down the program to the various method calls to help find problems. However, this tool is designed around debugging visual problems:
You can select specific frames and break down a captured moment to the draw calls and even the stencils and light calls:
These are really amazing tools, and maybe one day I can use them to figure out how to get 60 frames a second with HoloLens. In all reality, these low-level tools will likely only be used by processor manufacturers and the creators of new 3D engines trying to understand why their backfaces are not culling correctly. Generally speaking, we will stick to the Visual Studio Debugger and may jump into a basic profiler from time to time to try and learn what is taking up so much processing time. Looking at our game In this section, we will look at a few options that can be looked at to fix the problems with this project.
Currently, if you have gone through this project step by step, you are, like me, likely getting 22 frames per second when you play the game on HoloLens. In the HoloLens world, minimum recommended performance is 60 FPS. This number is needed to maintain the illusion that holograms really exist in the world. This goal is a very tall order; 30 is the norm and 45 is pushing it in my experience. Light probes One issue I am currently clearly aware of is due to the change to the quality settings. With the light probes set at 2 instead of Microsoft's recommended 0, and the number of lights in our scene, we are shaving 8 frames per second off. It just looks so bad without it.
There are a few options to potentially fix this:
- Of course, bite the bullet and change the light probes setting to 0
- Take out some of the lights in the scene
- Bake static lighting into the scene
- Alternatively, make our speed indicator an object that changes colors instead of using lights
Unity Profiler Taking a quick run through the Unity Profiler showed me that over 80% of the processing is in HoloLensWaitOnGPU, which means it is happening on the GPU itself. Now, let us have a look at the Profiler:
Selecting the GPU to dig down, we can see that 57.3% of the processing is happening in Graphic.PresentAndSync | Device.Present. From all accounts, this has to do with VSync or Vertical Sync.
In our case, the quality settings of HoloLens has VSync set to don't sync. This should not be affecting us, so let's try looking elsewhere:
Looking at the CPU:46.02msGPU:52.14ms shows us that we are GPU bound. This means that we have a graphics bottleneck on our hands slowing us down; now I know that in the case of this project, the Skeeball machine is a high poly model that has not been optimized, so that's the culprit--the answer to our mystery.
Often when dealing with these types of graphics, bottleneck models being too high in detail can definitely be a problem. Another big issue that can arise is the correct use of shaders.
In our case, HoloLens is considered a mobile device and should be treated as one. I looked at our use of materials and noted that all of them, aside from two, were set to standard. As we are on HoloLens, we should be using HoloLens/StandardFast. Now, this change will not likely fix our issue but will possibly give us a 1 or 2 FPS return.
One potential solution to use, if this was a normal Unity project, would be going to Quality and changing many of the settings:
In many cases, a slow project is quickly and easily brought back up to speed by making a few adjustments. Now, this should only be considered a band-aid; in the end, you will have to do what is being done in the chapter to run the project efficiently. However, in the case of HoloLens, you are stuck with debugging and optimizing because all the quality settings are turned down to begin with:
