Arm Mali Best Practices Guide
A guide designed as a quick-reference for development on Mali GPUs. It assumes that the reader is familiar with using the underlying APIs.Read now
Unified Vulkan Samples
A central location where anyone can access Khronos-reviewed, high-quality Vulkan code samples in order to make development easier and more streamlined for all abilities.View on GitHub
Arm Mali GPU Datasheet
A quick reference datasheet that covers all GPUs from Mali-T720 through to the latest Mali-G78. Available in PDF format through the link below.Download the PDF
Arm Mali GPU Performance Counters
These guide explains the performance counters found in the Arm Streamline tool's profiling templates for the Mali GPUs.Performance Counters
These recommendations aim to provide the best practices for Mali GPUs, however real-world applications can be complicated and there are always exceptions to this generalized advice. We highly recommend making measurements of any applied optimizations to check they are performing as intended on your target device(s).
Graphics processing can be represented as a pipeline of processing stages that includes the application, the graphics driver, and the various hardware stages inside the GPU itself. Most stages follow a strict architectural pipeline, with outputs from one stage becoming the inputs into the next. Compute shaders are the one exception to this strict pipeline, as they simply write results back to resources stored in system memory, and therefore their outputs can be consumed by any stage in the pipeline which can consume those resources.
This guide is structured with topic ordering following this pipeline. Each topic provides recommendations which should be applied to processing running in that that pipeline stage. There are some generic topics such as shader program authoring advice which can apply to multiple pipeline stages; we've split these out into dedicated sections at the end of the document.
For each best practice topic we provide an explanation of the recommendation, and actionable do and don't technical points which should be considered during development. Where possible we also document the likely impact of not following the advice, and possible debugging techniques which could be applied.
We provide relatively terse advice in this document for sake of brevity; for example, "Don't use discard in fragment shaders". There are inevitably cases where you will need to use a feature which we do not recommend using, some algorithms simply require it. Don't feel constrained by our advice to never use a feature, but in these cases at least start your algorithm design with the awareness that there might be an underlying performance implication for that algorithm that you should keep an eye on.