Android Studio Profiling (Android Game Developer Summit 2018)
Articles Blog

Android Studio Profiling (Android Game Developer Summit 2018)

September 7, 2019

My name is Francesco. I’m a former game developer. Been in the trenches for
a few years, about 15. And as Bill mentioned, tools
are important, as important as– at least for me, a game
is as good as the tools you use to make it. As I said, spent so many nights
waiting for tools to finish something or waiting
for a profiler to capture a frame that if
I don’t get a good tool, working on a game
becomes unbearable. And the less time you
spend profiling, debugging, creating assets, the more
time you can spend at the pub, if you’re from England– I work there– or you can
spend polishing the game. It’s probably a better
use of the time. We get this. That’s why we’re working a
lot on Tools now in Google. A lot of my time is literally
spent pacing in the office back and forth– we need good tools. We need good tools. We need good tools. People are getting
tired of this. But one of the outcomes
is that we now have– shut up– we now have a native
profiler in Android Studio, a native C++ profiler. It’s a profiler as every
profiler that you know. For now, it exists
in Android Studio. We also have System
Trace, which lets you have a more holistic view
of the entire system running. You can see the processes. We’re going to see
an example of this. And now, System Trace exists. But good luck using it
from the command line. Now we have it in
Android Studio, integrated with a great UI. And that’s my favorite one. We have it. Graphics API Debugger,
not Google API debugger. It’s about graphics and not
about trying to live at Google. And certainly, you can see every
single draw call in OpenGL, in Vulkan, and
you can replay it. It’s awesome. And it’s my favorite tool. Now as I mentioned, we can
sample native C++ threads. The only limitation is it works
on API 26, which is Android 8. It’s not a big deal. And that’s how it works. Now, I was writing some code,
and I left some debugging log in a inner loop. Raise your hand if you have
never left debugging code in your inner loop. I don’t believe you. Well, that means that, when
I clicked on the button, things got a little bit slow. Come the debugger. You can see there, something
is weird in Java code Piglet, my application
Piglet, because of my kid. And I name things after him. And you can see how I press
the button and the CPU is backed up right there. And yeah, as you would
expect, a lot of time is spent into do something
cool, which was inner loop. It’s a profiler as every
other profiler that you know, but now it exists. And you can do this kind
of stuff, which takes time, instead of trying to guess. Back to System Trace. System Trace is a tool
that is event-based, so it doesn’t sample
as an active profiler. It’s based on events that
fired from the system. It records all these events
and then shows all these events in a common timeline, where you
can see both the application and the system process. Yes. If there’s more than one. And this is very
interesting because you can see what things are running
on the system, in which core, how they are interacting
in an holistic timeline. And it lets you debug slow
frames very, very easily, because it highlights them. If a frame is running,
it’s taking more than 33 milliseconds to run, well,
the UI will show you. In this UI, there’s a lot
of information packed here. You can see this
device dual cores– all the threads. You can reorder threads,
just to have thread that are common together. It’s very useful. You can see that this thread,
too, is visually using a lot of CPU, the bright areas. And you can see there very
interesting information. Most of the CPU is
happening– most of the CPU– time is spent on the
CPU, on the core three. The other cores are
relatively light. How use that information? Well, it depends on what
you are trying to do. But for example,
this will tell me– OK, wait a second. I might get a little better
frame rate if I take this work and it’s spread across
multiple threads. But now, you don’t
have to guess. This will tell you. Let’s look at this
rendered thread. Again, here it’s using
quite a lot of CPU. And you can see other
single tasks that are running on in parallel. This is telling you another
interesting information. You do have a rendered
thread that is separate from the main thread. Good job. Something that generally
you want to do. Now let’s look at this trace. You can see that plain
bitmaps, this particular thread is using a lot of CPU. Fine, that’s all right. But you can also see that
it’s jumping from one core to the other. It’s been scheduled
in different cores. Now, let’s imagine
you’re already hitting your frame rate. So you’re good for
the frame rate. This information could
be used to say, OK, let’s try to set affinity for
this thread to a slow core. And let’s see if we
can save some battery. Or let’s put it on a
fast core, and let’s see if we can save some
battery there this way. Because the work is
finished earlier. So everything can
go to sleep quicker, instead of just jumping around. But the takeaway that
they want from this is you can see it visually
instead of trying to guess, which is what we
were doing before. The red bar means
this is a slow frame. And this tells you
that this frame is taking 200 milliseconds,
which is like more than 33. And something weird
is happening inflate. This might suggest that
some assets have been unpacked during this frame. Might be weird–
something going on there. But again, you see it visually. As I mentioned, this
system records events. You can insert your events
as well, and you record that. For example, let’s imagine
that you have a shadow pass. You want to look at
the shadow pass– in which thread is
running and what is happening, compared to
the rest of the system. Well, you can insert
custom events. And I give you a
nice sculpt trace. Just stick it at the
beginning of a function. And there you are. Its function is recorded. In the future, we’re
going to show in the main UI, also
the Vsyncs, which is very interesting
to see if you are hitting the Vsync with
your threads visually. We now support both 30
and 60 frames per second for if you’re making a racing
game, don’t want to run at 30. Limitations. There’s a limitation on API. It’s API 23 and before. It only runs on single
process for now. But that will be lifted. You can export traces. But you cannot
import traces yet. It’s got to be fixed. Like, it’s weird at this point. It’s got to be fixed. It’s work in progress,
as everything we do. My third one, GAPID. It’s correctly
Graphics Debugger now. And GAPID is for the ones,
the lucky ones, who use picks. It’s the beginning of picks. Getting there. It lets you trace,
capture trace, inspect the trace visually
and replay the trace on the same device. There’s a limitation. It works both on
Vulkan and OpenGL. It works on Android,
and Mac, and Windows. And that’s how it looks. That’s awesome. That’s me being
very happy about it. You can see every single
[INAUDIBLE] what is rendering. The frame buffer lets
you inspect shaders, lets you change the shader
on the fly and replay it on device. Very good if you’re an artist
who likes to use GIF GAPID. As I mentioned, it works
in OpenGL and Vulkan. There are some
limitations there. For example, if I
remember correctly, OpenGL doesn’t let
you capture mid-run. Vulkan does. There are some limitations. But this too is work in
progress, and thank it exists. And they’re improving it. Those limitations will
be lifted eventually. Its all available. System Trace is available now. You can load it in
3.2 in the Canary. There’s a link to the Canary. GAPID if being
released, it’s 1.0. Please give us feedback. And now, everyone says
please give us feedback. We actually do ask for feedback. If you tell me this things
doesn’t work on GAPID, I literally walk to the team,
to the leader of the team, and I start banging on the
desk until they get it fixed. And they did it, so it works. It works totally. If you have any
questions, feel free. Go ahead. AUDIENCE: Can you start and
stop on your Trace [INAUDIBLE]?? FRANCESCO CARUCCI: No. Write me. AUDIENCE: I was wondering
if you can start and stop the Trace programmatically,
just because we have a big game. Sometimes we want to just
look at a particular area of the game. FRANCESCO CARUCCI: No. Write me– my email. And I will file a bug. Can you tell me the
use case for it? AUDIENCE: Yeah. A lot of times, these
graphics systems, they run out of
memory before you’re even into the area of the
game that you want to look at. FRANCESCO CARUCCI:
I see what you mean. Yes, it’s a good point. Write me. AUDIENCE: What kind
of traits are you trying to start and stop? Are you trying to
start and record a CPU trace, or a memory, or– Ah. AUDIENCE: [INAUDIBLE] FRANCESCO CARUCCI: Yes, this
capture multiple frames, by the way. But it can be used to capture– personally, I’m a gigantic fan
of capturing only one frame. Not everyone agrees
with me on this. I do agree with
myself on this one. AUDIENCE: Hi. I actually beat GAPID. Currently for Vulkan, you can
do meta execution capture. So there isn’t an
API in the game, or there isn’t an
API that you can use to programmatically start it. But there’s a button that
you can start and [INAUDIBLE] your point. There’s a certain amount of
shattering that we have to do. So there is a overhead, but it’s
not as much as an entire driver copy. For GLES, we’re working on it. If you want a API to trigger
it, it will be very easy to add. Nice. AUDIENCE: [INAUDIBLE] FRANCESCO CARUCCI:
I didn’t know. Thank you.

Only registered users can comment.

Leave a Reply

Your email address will not be published. Required fields are marked *