Unity Profiler Tool

I had a look at the CPU profiler in Unity today as prep for my new job. Below is a super quick overview of the tool.

To open the profiler, go to Window > Profiler. This opens a new window showing a timeline of frames and a list of functions for each frame.


To view the current frame, click the current button in the top right. To view a specific frame, click on it in the graph. This will pause the game and give you information for that frame. The total ms cost for the frame is shown in the middle of the window. The lines on the graph show some target ms costs such as 33 and 16.


The list of functions allow us to see the time in ms for each function, as well as the percentage of the total frame time that that function uses. The self version of these shows the cost of the function without its children. The calls column shows how many calls to that function happen in the frame.

GC alloc shows how much garbage collection happens for that resource. Garbage is memory set aside to store data that is no longer in use – GC refers to the process that frees up this memory for use. If this happens too often it can hit performance, so worth keeping an eye on.

To get more information on child functions, we can run deep profiling by using the button next to record at the top of the window. Below, I’ve ran it to get more information on culling. Without deep profiling, I could see that this cost was related to culling lights, but with it on, I can see that its specifically linked to single directional shadows (common sense should have told me that lighting culling cost was associated with shadow casting, but data is always good!).


The profiler has a bit of an overhead – so make sure that you use the statics view with the profiler off to get the actual fps and ms per frame cost before profiling. Any logging functions that you may be using are part of debugging will also be fairly heavy. 3


Applying BCn Compression to Old Textures

As I mentioned in my last post, I’m interested in how BCn compression would have affected Presence, the game I made for my honours project at uni. (If you’re interested in experimental games you might want to check it out – download it here:http://amesyflo.itch.io/presence)


One of the things I’m kicking myself about over this game is the use of 16-Bit alpha for grass billboards. I had a framerate issue with transparency drawcalls, so ended up making the grass shader unlit to counterbalance this. I think that using 1-bit alpha would have given me the same results, but with better visuals.

Screenshot 1

Converting to BC1 from 16-bit png produced a very similar image, and halved the memory size of the file. My only complaint is that there is a little grey outline around the opaque section.


I also had a go at compressing hand painted textures, compressing this tree texture using BC1. I thought that I may have issues and have to move up to BC7, but I was happy with this result. Admittedly, if I was to do a real optimization pass on this game, the first thing I’d do with this texture is sort out the use of space on the UV map, but this is just an experiment.

tree comparison

I was going to import these textures into UE4, to check how I could reduce shader compilation times and memory. However, UE4 only accepts .dds files in a very particular format, designed for cubemaps, as compression is done in editor.

Default UE4 compression is very clever, in that it switches between DXT5 and BC5 depending on whether DX11 is being used. So basically, I was already using these types of files without knowing it!

I was going to give my 1-bit grass a go, but I haven’t found a way to compress to 1-bit BC1 in UE4. From the googling I’ve been doing on this subject, it looks like 1-bit alpha is unsupported in the engine.*


This is disappointing, as I thought I could further optimize GPU performance and GPU/disk memory for this wee game. Back to the drawing board I guess…


*I’ve posted on the forums and facebook/twitter about this, so if any new info comes up I’ll do another blog post about it!