[THEME MUSIC PLAYING]
SCOTT CARBON-OGDEN: Hello, everyone.
Welcome to this talk about the Android Game Development
Kit and our new Adaptability Pillar.
I'm Scott Carbon-Ogden, a product manager working
on Android games and graphics.
Joining me today is Peiyong Lin, a staff software engineer
on Android games who'll be talking you through the latest
adaptability additions.
Charlie Stokes, a staff development
relations manager at Arm, has also
kindly agreed to join us today.
He'll be sharing some cool demos of these technologies
in action.
But before we get to all that, I'm
going to start by refreshing your memory on the Android Game
Development Kit and letting you know about some
of our most exciting updates.
As a reminder, the AGDK is a range of tools and libraries
to help you develop, optimize, launch,
and iterate high quality Android game titles.
Everything in the AGDK follows three key tenants--
it's all code built for gaming, all of our libraries are
intended to be used in C or C++, and have been built and tested
with performance in mind.
We intend to reduce fragmentation.
The tools and libraries we're going to show you today
work across many different Android SDK and NDK levels.
And lastly, these are tools that were
built by Android for Android.
These features will be enhanced by future Android platform
updates.
They'll be updated before new versions of Android land
and they're backwards compatible,
having undergone extensive testing.
Thus far, we've introduced three key areas of game development
where the AGDK can help.
Firstly, we have a variety of integrated workflow tools
to make Android development efficient.
For example, the Android game development
extension for Visual Studio.
Then there are C and C++ development libraries to make
games easier to build, debug, and maintain.
For example, game activity which can help you reduce your ANRs.
And lastly, we have focused on performance optimization
to improve your games performance, both pre-
and post-launch, such as with the Android GPU Inspector.
So AGDK launched in July 2021, and the response
has been truly great.
Almost one third of games now use some element
of the Android Game Development Kit,
whether it be integrating the frame pacing API,
using the game development extension, or one
of our many other features.
We've heard and shared many great stories
users' [INAUDIBLE] with these products.
Cat Daddy switched "NBA 2K" to use game activity and reduced
ANRs by 35%.
You can learn more about that in Victor
and our team's talk on the AGDK libraries.
Last year, we also talked about how "The Witcher"
used Android Performance Tuner to increase
device reach by 10%.
But there's still so much more left to do.
So we made extensive improvements
to our existing AGDK suite, which I'll run through now,
and then we'll talk about the whole new area
that we're adding in after that.
Let's start with our updates to the Android Game Development
Extension Visual Studio, also known as AGDE.
We first released AGDE in 2019 to address the need of native
C++ Android game developers who use Visual Studio
as their primary IDE.
Since then, we continuously improved the tool
adding more and more features.
Most recently we've exposed instrumented profile
guided optimization in the IDE.
This feature gives your code a boost
but tuning it based on the way your code actually
executes at runtime, deprioritizing edge cases
and outliers.
Most developers can expect to see a 5% improvement in CPU
cost, and depending on the workload,
you may see even better results than that.
We've also added Ninja Build Support to our latest release.
We wanted to give users the ability to easily open
their project in Android Studio so you can get the benefit
of it's rich support for Java, Kotlin, and JNI,
such as being able to have same session Java and C++ debugging,
editing your Gradle build, and analyzing and upgrading
your Gradle dependencies.
With Ninja, you can easily open your AGDE projects
in Android Studio.
Address Sanitizer, or ASAN, is a feature
that helps you debug memory issues in your game.
Normally, these are difficult to figure out
because you only find them when your game crashes,
not when the memory overwrite or misuse actually
occurs in the first place.
ASAN allows you to build your app with guards and checks
in place to help you find the error when it happens.
In the latest version of AGDE, we
switched over to a new lower level control channel.
This allows us to put multiple simultaneous device
connections.
This should help improve debugging and device control
reliability when you have Android Studio open
alongside Visual Studio.
For example, when you're debugging Java language
and native code at the same time.
And finally, we're now releasing AGDE
as a Visual Studio extension package, or VSIX.
This should reduce the size of distribution
and make it easy to install and manage from inside Visual
Studio itself.
If Visual Studio is a core part of your normal development
environment, we strongly encourage
you to check out AGDE, and we're always looking for feedback
on ways we can make it even better,
and better support our game developer community.
We've also updated all our libraries
based on your feedback.
Now, they should be more powerful and easier to adopt.
You can find out more about the specifics in Victor
and our team's on the AGDK libraries.
Writing your own JNI can be a pain.
It can be frustrating, lead to memory leaks, ANRs,
or even crashes.
Yet on Android, many of you have to use the Java programming
language to access various system settings or third party
libraries.
To make things easier for you, we're
releasing a new tool that takes in a Jar file
and generates a source code in either C or C-sharp.
This Apple code is just a lightweight interface
for accessing the Java language code
without needing to write, debug, and maintain your own JNI.
It's available now as a beta, so try it out.
We'd love your feedback.
So those were the updates to our existing pillars,
but we wanted to expand the AGDK to solve more developer
problems.
We've heard your consistent feedback over the years
that it can be hard to tune your game to the diverse Android
ecosystem.
Every device has a unique performance profile
and a different thermal situation.
For example, being out in the sun in a plastic case
leads to a very different performance situation
to being in a cold, dark room.
To help address this, we're also adding a whole new section
to the AGDK--
adaptability.
So what do we mean by adaptability?
We mean tools and libraries to understand and respond
to changing performance, thermal, and user
situations in real time.
The key elements of our adaptability suite
are the ADPF Hint API, which helps the OS ramp up and ramp
down CPU frequency based on what's going on in your game;
the ATP Thermal API that gives your games signals
about how close you are to being thermally throttled;
Game Mode API, which advises you about the user's preference
for performance or battery; and lastly, the Game State API,
which lets you tell the OS about what
you're doing so that it can adjust to meet your performance
needs.
Unlike the other elements of the AGDK,
several of the adaptability elements
include direct system calls so you will have OS dependencies.
Now, I'll pass it to Peiyong to go into a little more detail
on these tools and libraries.
PEIYONG LIN: Thank you, Scott.
Hello, I'm Peiyong and I'm going to walk you
through our adaptability framework APIs.
Let's start with ADPF.
If you haven't heard about it, ADPF
is the range of APIs that allow applications
to respond to and influence performance characteristics
in Android.
Let's first take a look at the PerformanceHint APIs.
Typically, schedulers have very little information
to determine strategy effectively
without additional information passing from the upper stack.
The PerformanceHint APIs are to tell the OS about the target
and CPU duration of the workloads
so that the scheduler can deploy a more effective strategy,
reducing frame drops and improving power efficiency.
Also, ADPF is more aware of the call topographies
and much more reliable than games taking
a guess with set affinity.
And as an example, here's how a default Linux scheduler
would behave when the workload comes in and out.
The CPU governor can take all the way up
to 200 millisecond to ramp up to maximum frequency
from idle state, or back down to lowest frequency
when the workload is completed.
So to use PerformanceHint APIs, you
will need to use PerformanceHintManager first
by identifying threads that complete a workload,
and then figure out the CPU duration for the workload.
Typically, this ties to the framework
that your game targets, and then call
the PerformanceHintManager.Session
API to create a hint session for the workload.
As an example, threads that fulfill a workload
could be the main thread of the game,
and the dependent worker threads, in IO
and/or the audio threads.
The PerformanceHint APIs are currently
used across the Android graphics stack and Chrome.
We have seen drastic improvement on both sides.
It is also available in the latest Unity.
Besides the PerformanceHint API, we also
have a fixed performance mode that you, as developers,
can turn on through an ADB command, which
will set the upper bar and the lower bar of the CPU's GPU
frequency to allow reproducible profiling
and performance debugging.
So performance hints APIs are to influence the Android OS
with by reacting and monitoring performance
characteristics of Android.
The thermal APIs will allow you do to so.
There are two major APIs that you, as developers, should
take a look at if you care about thermal and thermal throttling.
The first API is a callback through power manager
that allows you to get notified when the thermal throttling
state has changed.
For example, when the device starts
to have moderate thermal throttling
from the previous light thermal throttling state.
The second API provides and estimate
of thermal headroom the device currently
has before it hits severe thermal throttling.
The returned value is a non-negative number
about how much of the thermal envelope is in use
or will be in use within the forecast time.
And 1.0, by definition, is severe throttling.
These two APIs are also available through
a thermal manager in NDK.
OK, so let's take a closer look at the on thermal status
changed listener API.
There are essentially three stages of thermal status
that us developers will know--
No thermal throttling, some thermal throttling
but has not significant impact on the performance,
and significant throttling that impacts the device performance.
But then when you receive a call back about the device hitting
any of the significant throttling,
the performance of the game has already suffered,
and it takes bigger efforts to turn things around.
So what you, as developers, will want to do
is to constantly monitor the thermal headroom
and check how close the device is to severe throttling,
and you will want to make sure you reach
a stable balance beneath 1.0.
So projecting what that means into a graph.
Over the time, as users play the games,
the device temperature starts to go up
and starts to run into thermal throttling.
If games don't monitor the thermal headroom,
no actions are taken ahead of the time,
and the performance starts to degrade, which
impacts the user experience.
But if games monitor the thermal headroom,
especially monitor how fast the thermal headroom
is moving, the workload can be adjusted dynamically
by the games and hence avoid being severely throttled,
maintaining a sustainable user experience.
Typically, you, as developers, will
want to monitor the throttling status
with the callback and the API and adjust the rendering
resolution, and/or reduce the frame rate
in order to recover from or avoid thermal throttling.
So now, you know about what ADPF is and the shapes of the APIs.
Does it really benefit your games?
I'm going to hand over to Charlie from Arm
to talk about Arm's integration with ADP.
CHARLIE STOKES: Hi, I'm Charlie Stokes, staff developer
relations manager at Arm.
Here, we're focusing on mobile CPU performance
and how we, along with Google, can help you improve
the performance of your games.
"The Adventures of Dr. Arm" is a research game built in house
at Arm, made in Unity.
The game was built to be like modern mobile phone games
to model their behavior on mobile phones
and allow us to test how different technologies might
work on a game on Arm devices.
The sort of thing that we included in the game
to mimic the workload a mobile game might go through
during play includes particle effects--
dust, mist, smoke, and fire effects--
lighting effects, post-processing effects--
like bloom, depth of field--
screen space ambulance occlusion, and motion blur.
All of these add up to be an intense workload
for a game on mobile.
These features help enhance the atmosphere and experience
of a game, but are not essential to game play.
We included adaptive performance in the game through the APIs
that Google gave us and integrated them into the game.
We had two different modes to switch between,
a scenario where adaptive performance was switched on
and one where it is off.
We compared the two play modes and put them side-by-side.
As you can see from this video with adaptive performance
enabled, when the workload started to get intense,
adaptive performance was able to maintain the frame
rate on the game.
It also brought down the temperature of the phone.
In comparison, when adaptive performance was switched off,
the game was not able to maintain the frame rate
and the temperature of the phone rapidly climbed.
Adaptive performance provides the benefit
of having the game's art, lighting, and post-processing
effects but also scales back effects in the times
of peak demand from the device.
When throttling was imminent, we turned off
effects in Dr. Arm that were included mostly
to enhance the mood of the scene,
but this did not impact game play.
You can see this here in the differences
between visual effects prior to throttling and then
with adaptive performance on.
This can also be seen with changes to post-processing
as well.
This is also shown in the thermal measurements
taken during game play.
These graphs were taken during a play of Dr. Arm.
With no adaptive performance enabled,
we can see an average of about 55 degrees Celsius for the skin
temperature.
We can also see that about two minutes into game play,
the device enters a severe thermal state
that it never recovers from.
In comparison, with adaptive performance enabled,
the temperature of all mobile processors
drops, indicating performance improvements
and the skin temperature of the phone
drops to about 45 degrees Celsius.
The thermal state of the device then remains light.
Moving on to performance-- here we have a range of CPU cores
from Arm that were tested during this run.
The bars on the graph show the average duration
the core was active through runtime.
The color indicates the frequency for that duration.
Overall, we see large net performance improvements.
There's a large reduction in the amount of work
being done on the big cluster, as well
as keeping the mid-range CPU cluster at a lower frequency.
This shows major gains in the performance of the system
and game projects on Android.
PEIYONG LIN: Thank you, Charlie.
Besides ADPF, we have other adaptability tools,
the Game Mode APIs and the Game State APIs.
The Game Mode APIs were introduced
in Android 12 that allows games to understand the user's
performance preferences between performance and battery saving.
The goal of using the APIs is to ensure
your games deliver a stable frame rate while still
fulfilling users' needs.
You will want to make sure you check the user's intention
during onResume and interpret the user's intention
into the gaming experiences.
For example, if a user wants to battery save,
the game may need to run at lower frame
rates, such as 30 fps.
With the lower graphics fidelity.
If left unimplemented, OEMs may intervene upon your game.
For example, reducing the rendering resolution
or throttling the frame rate.
The game state APIs cab be used to inform us
about the game state.
This will allow the OS to have actual information
to optimize the scheduling strategy.
An example to use, game state APIs
to cause that games the API in game manager.
This example informs the OS that the game is loading contents.
So we walked through all the tools
that make up the adaptability pillar, which
help your games deliver sustainable performance
across devices.
If you would like to learn more about the tools,
check out g.co/android/agdk.
Thank you for watching.
Thank you.
Happy computing.
[THEME MUSIC PLAYING]