We have just released Mobile Studio 2020.3, our suite of profiling tools for Android application development. This is a milestone release, delivering the final piece in a set of quality-of-life improvements we have been talking about since launching the Studio at GDC 2019.
Up until now, Streamline and Graphics Analyzer have relied on helper scripts to set up the connection to the target device. These scripts allow the user to specify the target application to be profiled, push our tooling components to that application’s data directory, and perform any other device configuration needed for that tool. They have served as a useful stopgap. It is far easier to use the script than run the commands by hand, but we appreciate that forcing users to run command-line scripts was far from an ideal experience.
Well, no more. In this release developers using the host tool can simply select their application from a list of debuggable applications in the host tool GUI, and click to connect. No more terminal windows and no more scripts, at least for interactive use. See the new flow in action here:
The Vulkan API was designed with the concept of tooling layer drivers – API interceptors that can be injected between the application and the underlying graphics driver to add API-aware tooling functionality. Android 10 extended this support to add layer drivers for OpenGL ES, which is a fantastic addition that really makes developing OpenGL ES tooling easier and more reliable. All of our tooling for Android 10 onwards now implements API monitoring using these standard layer driver mechanisms.
The challenge here is supporting older Android devices – most developers we talk to are still targeting devices running Android 8 and 9 for their game minimum requirements. In earlier Mobile Studio releases this causes a fork in the workflow for Graphics Analyzer, requiring the user to make two application builds. Profiling an OpenGL ES application on Android 9 or earlier requires the application build to integrate our interceptor library into the application at build time. Profiling on Android 10 or later requires that the application does not do this and uses the layer approach. Having to manage two builds, and remember to pick the right build for the device you are profiling on, is a hassle we thought you could all do without.
In this release of Graphics Analyzer, we are pleased to announce that there is no longer a need to integrate any GA components into your application at build time. All you need is a debuggable application build. We will use layer drivers in Android where we can, but if that is not available, we can now inject the OpenGL ES layer at runtime using the Android debug interface. From a user point of view, you now need only manage a single build configuration, no matter what you are doing.
For this release we’ve exposed some more information about the Mali GPU configuration of the target device, and these are now available as variables in custom expressions.
$MaliConstantsShaderCoreCount
$MaliConstantsL2SliceCount
$MaliConstantsBusWidthBits
The Mali GPU templates have been updated to use these where appropriate, which corrects one long-standing graphing bug for Mali GPU stall rate. On earlier releases large Mali configurations with multiple L2 cache slices would over-state the stall rate, as it was being scaled by the slice count. Now it is being correctly normalized.
Our Performance Advisor reports have been designed to focus on the critical performance metric for graphical workloads, allowing developers to focus on the important behaviors and avoid getting swamped in detail.
In previous releases, we only supported a fixed report, showing our hand-picked metrics. We have had a number of requests for more (or fewer) charts in these reports, so this release allows developers to use a custom chart template that can select any of the counters available in the Streamline capture.
This release sees some minor, but useful, quality-of-life improvements for the Mali Offline Compiler.
Compiling Vulkan shaders from a SPIR-V binary now requires considerably less typing. The tool can now automatically identify that the input file is a SPIR-V binary, as well as the shader type and entry point name that binary uses. This command in 7.2:
malioc --spirv --vertex -n foo .\samples\vulkan\shader-entrypoint-foo.vert.spv
… becomes just this in 7.3:
malioc .\samples\vulkan\shader-entrypoint-foo.vert.spv
In addition, we have made some improvements to make it easier to integrate Mali Offline Compiler into multi-tool pipelines. You can now specify “-” as an input file, which will tell the tool to read from stdin, rather than a file on disk. You can now specify “-o/--output” as an output file, which will tell the tool to write to a file on disk, rather than stdout.
-o/--output
For this release we have also bought and tested two more devices, which have been added to our supported devices page (https://developer.arm.com/mobile-studio/devices):
Outside of Arm Mobile Studio we are also happy to announce the release astcenc 2.2, the latest version of our ASTC texture compressor. Highlights for this release includes:
For more information see the release GitHub release page.
Keep up date with the latest tools news, blogs, and training materials using our latest news stream.
Download Arm Mobile Studio 2020.3
> In this release developers using the host tool can simply select their application from a list of debuggable applications in the host tool GUI, and click to connect. No more terminal windows and no more scripts, at least for interactive use
Thank you Pete! That's a long-waited improvement :)