Graphics Performance Testing Across Devices

Graphics Performance Testing on Various Devices

A game delivering stable 60 fps on Pixel 7 can drop to 18 fps on Redmi Note 9 — and not because the phone is "weak." It's because Adreno 618 and Mali-G52 handle the same shader differently, and nobody tested behavior on Mali before release. Graphics performance testing is about understanding hardware differences and ensuring your game doesn't become a slideshow on devices that represent 30% of your target audience.

Where real performance problems hide

Draw calls and batching. 200 draw calls on mobile — red zone. But the counter itself says nothing about the cause. UI via Canvas in Overlay mode with multiple child canvases each overriding sorting — guaranteed batch breakage. Unity can't combine elements from different canvas override into one batch. Result: 80 draw calls just on HUD that engineer could reduce to 5–8 with proper hierarchy.

Overdraw. On mobile GPU (tile-based deferred rendering: Adreno, Mali, PowerVR) overdraw kills performance faster than on desktop. Rendering one pixel 4 times — 4x more GPU work. Particle systems with Additive blending, UI layers on top of each other without culling, transparent meshes — typical overdraw sources. Unity Frame Debugger shows draw call sequence, but RenderDoc is more visual: it color-codes overdraw as heatmap right in viewport.

Thermal throttling. Mid-budget Android devices reduce CPU/GPU frequency by 20–40% after 3–5 minutes of intense play due to overheating. Emulator doesn't reproduce this at all. So sustained performance test is only on real hardware, and not 30 seconds but minimum 20 minutes of gameplay.

Tools and methodology

Main workflow: Unity Profiler → Frame Debugger → Memory Profiler → platform-specific tools.

Unity Profiler shows CPU breakdown by threads (Main Thread, Render Thread, Job Worker) and GPU timeline — but GPU timeline works correctly not on all devices. On some Android via ADB Profiler shows zeros in GPU block. In this case we use native tools:

• Adreno GPU Profiler (Qualcomm): detailed breakdown by pipeline stages, HSR (Hidden Surface Removal) efficiency, shader cycle counts
• Mali Graphics Debugger (Arm): similar for Mali architectures, plus bandwidth visualization
• Xcode Instruments + Metal Debugger: for iOS/Metal — mandatory tool, no alternatives
• RenderDoc: cross-platform frame capture with full state inspector — used for analyzing shader and batching issues regardless of platform

For automated benchmarking — Unity Performance Testing Package (com.unity.test-framework.performance). Allows writing tests that measure specific metrics (frame time, GC allocations, draw calls) and save baseline for comparison between builds.

In practice: for mobile open-world game we discovered via Mali Graphics Debugger that custom water shader used textureCubeLod with precision mediump, which on Mali-G76 caused sampling artifacts and triggered software path fallback — fps in water area dropped from 45 to 22. Changing to textureCubeLod with precision highp eliminated artifacts but added 8% load. Final solution — simplified water shader for Mali devices via Quality Settings and platform-specific material override.

Device matrix for testing

Testing on one "representative" device is insufficient. Minimum matrix for mobile project:

Low-end (target floor): Qualcomm Snapdragon 460/Adreno 610, Mali-G52, 3 GB RAM. Bottom boundary where game should work acceptably.

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.

Process

Start with baseline profiling at each matrix level. Fix frame time, draw calls, overdraw, memory. Identify problem scenes/situations (usually match start, explosion effects, open spaces).

Then — iterative optimization: texture atlasing, LOD groups, GPU Instancing for repeating meshes, occlusion culling, Shader LOD. After each change — re-measure on real devices.

Cost is calculated after project analysis and required device matrix assessment.