FRANCESCO CARUCCI: 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.
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.