A game that delivers a stable 60 fps on a Pixel 7 can drop to 18 fps on a Redmi Note 9 — and that's not because the phone is "weak." It's because the Adreno 618 and the Mali-G52 process the same shader differently, and no one checked the behavior on Mali before release.
We analyze cases like this every day and know how to turn a slideshow into smooth visuals. Over the course of our work, we have tested more than 50 projects — from hyper-casual titles to open-world RPGs.
Graphics performance testing is about understanding hardware differences and making sure a game doesn't lose its audience.
What the work includes
| Stage | Result |
|---|---|
| Project analysis and build collection | Device matrix, test scenarios |
| Baseline profiling | Frame time, draw calls, overdraw, memory per each device |
| Iterative optimization | Atlasing, LOD, GPU Instancing, occlusion culling, Shader LOD |
| Re-testing | Before/after metrics comparison, identification of new issues |
| Report and team training | Documentation, logs, access to reports for 2 months |
Why does the game lag only on devices with Mali GPU?
The Mali architecture uses tile-based deferred rendering, where overdraw and high-precision shader instructions can cause performance drops. For example, mediump precision in textureCubeLod can trigger a software fallback. We identify such cases using Mali Graphics Debugger.
Where the real performance issues hide
Draw calls and batching. 200 draw calls on a mobile device is a red zone. UI via Canvas in Overlay mode with multiple child canvases, each of which overrides sorting, is guaranteed to break all batches. Result: 80 draw calls just for the HUD, which can be reduced to 5–8 with the correct hierarchy.
Overdraw. On mobile GPUs (tile-based deferred rendering), overdraw kills performance faster than on desktop GPUs. Rendering one pixel 4 times in a row is 4 times more work on the GPU.
Particle systems with Additive blending, UI layers without culling, and transparent meshes are typical sources. RenderDoc visualizes overdraw as a heatmap right in the viewport.
Thermal throttling. Mid-range Android devices after 3–5 minutes of intensive gameplay reduce CPU/GPU clock speed by 20–40% due to overheating. This does not reproduce on an emulator.
Therefore, a sustained performance test is only on real hardware, at least 20 minutes of a gameplay session.
How to build a device matrix for testing?
Testing on a single “representative” device is not enough. The minimum matrix for a mobile project:
- Low-end (target floor): Qualcomm Snapdragon 460/Adreno 610, Mali-G52, 3 GB RAM.
- Mid-range (main audience): Snapdragon 700 series/Adreno 618-619, Mali-G76, 4–6 GB RAM.
- High-end (flagship): Snapdragon 8 Gen 2, Apple A16, 8+ GB RAM.
iOS separately: iPhone SE 2 (A13), iPhone 12 (A14), iPhone 14 Pro (A16) — three generations, three different Metal behaviors.
Why doesn't testing on an emulator replace real hardware?
The emulator does not reproduce thermal throttling — it uses PC resources without restrictions. Moreover, the emulator does not emulate the tile-based architecture of Mali and PowerVR, so overdraw and shader issues can go unnoticed.
Only on a physical device can you measure the real FPS budget, thermal throttling drops, and battery behavior.
Tools and Methodology
Main workflow: Unity Profiler → Frame Debugger → Memory Profiler → platform-specific tools. Unity Profiler provides a CPU breakdown by threads and a GPU timeline, but the GPU timeline does not work correctly on all devices.
On some Android devices, the Profiler via ADB shows zeros in the GPU block. In this case, we use native tools:
- Adreno GPU Profiler (Qualcomm): detailed breakdown by pipeline stages, HSR efficiency, shader cycle counts.
- Mali Graphics Debugger (Arm): similarly for Mali architectures, plus bandwidth visualization.
- Xcode Instruments + Metal Debugger: for iOS/Metal — a mandatory tool.
- RenderDoc — cross-platform frame capture with a full state inspector for analyzing shader and batching issues.
For automated benchmarking — Unity Performance Testing Package. It lets you write tests that measure metrics (frame time, GC allocations, draw calls) and preserve a baseline.
How we do it
- Initial analysis: we study the build, identify target devices, and agree on the matrix.
- Baseline profiling: on each device we record frame time, draw calls, overdraw, memory.
- Bottleneck identification: we find the problematic scenes (match start, explosion effects, open spaces).
- Iterative optimization: texture atlasing, LOD groups, GPU Instancing, occlusion culling, Shader LOD.
- Re-testing: after every change — measurement on all devices.
- Validation: sustained performance check (20+ minutes) and a report with recommendations.
| Testing scope | Estimated timeline |
|---|---|
| Profiling of a single scene, 2 devices | 3–5 days |
| Full game profiling, matrix of 6 devices | 2–3 weeks |
| Testing + optimization + validation | 4–8 weeks |
Contact us to discuss the details and get your project evaluated. Get a consultation from an engineer with experience optimizing for any GPU.