A game that runs at 60 fps on Pixel 7 can drop to 18 fps on Redmi Note 9 — and it's not because the phone is "weak". It's because the Adreno 618 and Mali-G52 process the same shader differently, and nobody checked behavior on Mali before release. We deal with such cases daily and know how to turn a slideshow into a smooth picture. Over our work, we have tested more than 50 projects — from hyper-casual to open-world RPG. Graphics performance testing is about understanding hardware differences and ensuring the game doesn't lose its audience.
What's included
| Stage | Result |
|---|---|
| Project analysis and build collection | Device matrix, test scenarios |
| Baseline profiling | Frame time, draw calls, overdraw, memory per device |
| Iterative optimization | Atlas, LOD, GPU Instancing, occlusion culling, Shader LOD |
| Re-testing | Comparison of metrics before/after, identify 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?
Mali architecture uses tile-based deferred rendering, where overdraw and high-precision shader instructions can cause performance drops. For example, mediump precision in textureCubeLod may trigger a software fallback. We identify such cases using Mali Graphics Debugger.
Where are the real performance bottlenecks?
Draw calls and batching. 200 draw calls on a mobile device is the red zone. UI through Canvas in Overlay mode with multiple child canvases, each doing override sorting, will absolutely break all batches. Result: 80 draw calls just for the HUD, which can be reduced to 5–8 with proper hierarchy.
Overdraw. On mobile GPUs (tile-based deferred rendering), overdraw kills performance faster than on desktop. Rendering one pixel 4 times in a row means 4 times more work for the GPU. Particle systems with Additive blending, UI layers without culling, transparent meshes — typical sources. RenderDoc colors overdraw with a heat map directly in the viewport.
Thermal throttling. Mid-range Android devices after 3–5 minutes of intensive gaming reduce CPU/GPU clock frequencies by 20–40% due to overheating. This cannot be reproduced on an emulator. Therefore, sustained performance testing is done only on real hardware, with a minimum 20-minute gaming session.
How to compose a device matrix for testing?
Testing on a single "representative" device is not enough. Minimal 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 does emulator testing not replace real hardware?
The emulator does not reproduce thermal throttling — it uses host resources without limits. Moreover, it does not emulate the tile-based architecture of Mali and PowerVR, so overdraw and shader issues may go unnoticed. Only on a physical device can you measure actual FPS budget, temperature drops, and battery behavior.
Tools and methodology
Core workflow: Unity Profiler → Frame Debugger → Memory Profiler → platform-specific tools.
Unity Profiler provides a CPU thread breakdown and GPU timeline, but the GPU timeline does not work correctly on all devices. On some Android devices, ADB Profiler shows zeros in the GPU block. In such cases, we use native tools:
- Adreno GPU Profiler (Qualcomm): detailed pipeline stage breakdown, HSR efficiency, shader cycle counts.
- Mali Graphics Debugger (Arm): similar for Mali architectures, plus bandwidth visualization.
- Xcode Instruments + Metal Debugger: for iOS/Metal — mandatory tool.
- RenderDoc — cross-platform frame capture with full state inspector for shader and batching analysis.
For automated benchmarking — Unity Performance Testing Package. Allows writing tests that measure metrics (frame time, GC allocations, draw calls) and save baselines.
How we do it
- Initial analysis: study the build, determine target devices, agree on a matrix.
- Baseline profiling: on each device, record frame time, draw calls, overdraw, memory.
- Identify bottlenecks: find problematic scenes (match start, explosion effects, open areas).
- Iterative optimization: texture atlasing, LOD groups, GPU Instancing, occlusion culling, Shader LOD.
- Re-testing: after each change, measure all devices.
- Validation: check sustained performance (20+ minutes) and deliver a report with recommendations.
| Testing scope | Estimated timeline |
|---|---|
| Profiling one 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 details and assess your project. Get a consultation from an engineer with experience optimizing for any GPU.