As mobile games continue to pursue higher visual quality, GPU performance optimization has become increasingly important. Differences between mobile GPU architectures and performance levels can also make GPU bottlenecks difficult to diagnose.
GameOptim's GOT Online GPU Mode uses GPU Clocks as a primary indicator of GPU pressure. When GPU Clocks × Target FPS >= GPU Maximum Frequency × 80%, the frame is identified as GPU Bound and highlighted in pink. This indicates that the GPU is spending a high number of clock cycles processing the current frame, making it difficult to sustain the target frame rate.
Once a frame is identified as GPU Bound, developers can further examine metrics such as GPU Shaded, GPU Primitive, Overdraw, bandwidth, and Shader Cycles to identify the underlying source of GPU pressure.
This article covers seven common GPU performance issues that can be identified through these metrics.
New users can get 2 hours of free GOT Online testing time after completing registration.
Introduction
A GPU Bound frame does not directly tell you what is causing the rendering workload. The actual bottleneck may come from excessive geometry, high Overdraw, memory bandwidth, complex shaders, or inefficient resource usage.
Therefore, GPU optimization should not stop at identifying GPU Bound frames. Developers need to break the workload down into more specific metrics and determine which rendering resources or operations are contributing most to the GPU cost.
The following seven issues are common areas worth investigating.
What Does a GPU Bound Frame Actually Mean?
In GOT Online GPU Mode, GPU Clocks are used as a primary indicator of GPU performance.
A frame is classified as GPU Bound when:
GPU Clocks × Target FPS >= GPU Maximum Frequency × 80%
These frames are highlighted with a pink background.
GPU Bound indicates that the GPU requires too many clock cycles to process the current frame. In other words, the available GPU clock cycles within the target frame interval may not be sufficient to maintain the target frame rate.
However, GPU Bound is only a symptom. Developers still need to determine why the GPU workload is high.
Metrics such as GPU Shaded, GPU Primitive, Overdraw, bandwidth, and Shader Cycles can help narrow down the underlying cause.
Could Excessive Mesh Density Be Increasing GPU Pressure?
Observed in 93% of the analyzed cases.
Mesh rendering density can help determine whether a mesh contains more geometric detail than is necessary for its on-screen size.
Rendering density represents the number of mesh vertices within an average area of 10,000 pixels (100 × 100 pixels).
If the value is above 1,000, the mesh may be unnecessarily complex for the size at which it is rendered.
When the minimum rendering density of a mesh remains above 1,000, its vertex count is likely too high. Developers can consider:
- Reducing the mesh polygon count
- Applying LOD
- Reviewing the asset's rendering lifecycle and usage
- Using culling when the resource does not need to be rendered
The appropriate solution depends on how the asset is actually used. A mesh that is rendered frequently may benefit from geometry reduction or LOD, while a resource that is rarely visible may be a better candidate for culling.
Are Too Many Invisible Primitives Being Submitted to the GPU?
Observed in 92% of the analyzed cases.
Rendering primitives are another important source of GPU workload.
A high primitive count can indicate overly complex models, but it can also result from large terrain or architectural meshes that have not been properly divided. In such cases, relatively few triangles may eventually be visible, while many primitives are still submitted to the GPU.
GOT Online's Primitive metrics distinguish between:
- Total Primitives: The total number of primitives submitted to the GPU, which is generally close to the number of rendered triangles reported by the engine.
- Visible Primitives: The triangles that remain after GPU-side culling and participate in rendering.
For a typical 3D scene, a visible primitive ratio around or above 50% can be considered a useful reference point, since many models will have roughly half of their triangles removed due to back-face culling.
If the visible primitive ratio becomes very low from certain camera angles, developers should investigate large models that are being submitted to the GPU unnecessarily.
Whenever possible, unnecessary objects should be culled on the CPU side so that fewer primitives need to be submitted to the GPU.
Is High Overdraw Increasing the Fragment Workload?
Observed in 91% of the analyzed cases.
Overdraw occurs when the same pixel is rendered multiple times, increasing GPU workload.
For opaque objects with an appropriate rendering order, Overdraw should ideally remain close to 1. In practice, transparent objects such as particle systems and UI elements are often major contributors to high Overdraw.
GOT Online GPU Mode provides two different Overdraw measurements.
The first is Hardware Overdraw, calculated from Fragment Shaded divided by the hardware resolution. This measurement includes post-processing and operations such as BlitCopy, Copy Depth, and Copy Color.
The second is the traditional Overdraw measurement, calculated by replacing the rendering shader and measuring the accumulated pixel intensity. This typically focuses on scenes or UI and does not include post-processing or BlitCopy operations.
The two measurements may therefore differ. If the difference is significant, developers should investigate whether post-processing or full-screen BlitCopy operations are contributing to the additional workload.
An Overdraw heatmap can further help locate the visual sources of high Overdraw.
For example, if an explosion effect produces a significantly brighter region in the heatmap, the effect is likely contributing substantially to the frame's Overdraw.
Possible optimizations include:
- Limiting the maximum number of particles in the particle system.
- Keeping only important particle effects on mid-range and low-end devices.
- Reducing the screen coverage of particle effects, since larger coverage areas are more likely to produce overlapping pixels and higher Overdraw.
Could High Memory Bandwidth Be Causing GPU Pressure?
Observed in 88% of the analyzed cases.
High GPU read and write bandwidth can contribute not only to GPU workload but also to device heat generation and power consumption.
Bandwidth can generally be divided into read bandwidth and write bandwidth. Read bandwidth often accounts for a significant portion of the workload, including texture and vertex reads.
Several areas are worth investigating.
Are Texture Compression Formats Appropriate?
Using an appropriate texture compression format can reduce the amount of texture data that needs to be transferred and therefore help reduce bandwidth consumption.
Is Mipmap Enabled Where Appropriate?
For 3D scenes, enabling Mipmap for material textures can reduce bandwidth at the cost of some additional memory usage.
Are Texture Sampling Settings Too Expensive?
Anisotropic filtering and trilinear filtering can introduce additional sampling costs on mobile devices.
Texture sampling first attempts to access data from on-chip cache. When the required data is not found, a cache miss causes the GPU to access system memory, increasing read bandwidth.
Additional texture samples required by trilinear or anisotropic filtering can increase the probability of cache misses and therefore increase bandwidth usage.
Are RenderTexture Operations Increasing Bandwidth?
Operations such as:
- Bloom upsampling and downsampling
- Blur
- Depth of Field
- Copy Color
- Copy Depth
- Anti-aliasing
can all have a significant impact on bandwidth.
Is the Rendering Resolution Too High?
Reducing the rendering resolution to 0.9× or lower reduces the number of pixels involved in texture sampling and can also reduce RenderTexture load/store operations.
This can ultimately reduce bandwidth.
Bandwidth and power consumption are also closely related. As a rough reference, 1 GB/s of bandwidth may correspond to approximately 80–100 mW of power consumption. Developers can therefore compare bandwidth trends with power consumption trends when investigating excessive battery drain.
Is Shader Complexity Too High?
Observed in 87% of the analyzed cases.
Shader complexity is another important factor during the fragment stage.
Shader Cycles represents the number of GPU clock cycles spent executing shaders. GOT Online also provides more detailed metrics, including:
- Shader Arithmetic Cycles
- Shader Interpolator Cycles
- Shader LoadStore Cycles
- Shader Texture Cycles
These metrics help developers determine which part of shader execution is contributing most to the workload.
For example, high Arithmetic Cycles may indicate excessive mathematical computation, while high Texture Cycles may point toward texture-related shader workload.
Developers should pay particular attention to shaders applied across large screen areas. A complex shader used across a large building or terrain surface can produce substantial overall cost simply because of the number of pixels affected.
Transparent materials also deserve special attention because they can combine complex shaders with high Overdraw, causing the shader to be executed for a large number of pixels.
Tools such as the Mali Offline Compiler can also be used to inspect shader instruction counts and clock cycles for further shader analysis.
Are Some Textures or Meshes Loaded but Never Rendered?
Observed in 83% of the analyzed cases.
A rendering utilization of 0% means that a texture or mesh was loaded into memory during the test but was never submitted to the GPU for rendering.
There are several possible explanations.
Are Too Many Resources Being Loaded?
Some resources may be loaded into memory but rarely used or never used.
Developers should check the actual usage of these resources and determine whether they need to remain loaded.
Did the Test Cover the Relevant Content?
A resource may have a low utilization simply because the test did not reach the gameplay content where the resource is used.
This can happen with:
- Large scenes
- Special story events
- Preloaded effects
- Rare gameplay paths
In this case, a more comprehensive test process is needed. Ideally, teams should automate scene and gameplay traversal and run longer tests to cover as much content as possible.
Are Mipmap Levels Being Used Efficiently?
Observed in 82% of the analyzed cases.
One useful metric is the sampling rate of Mipmap Level 0.
If Level 0 is sampled less than 20% of the time, the texture may be larger than necessary for its actual usage.
For example, a 1024 × 1024 texture may technically have a high resolution, but if Level 0 is never sampled and 96.15% of pixels are sampled from the 128 × 128 Mipmap level, the original texture resolution may be unnecessarily high.
By examining the resource's rendering lifecycle, developers can determine where the texture is used and which Mipmap levels are actually sampled.
If 96.15% of sampling occurs at Mipmap 3 or higher, reducing the texture from 1024 × 1024 to 128 × 128 may be a reasonable optimization to consider. This can reduce memory usage and improve loading efficiency without significantly affecting the rendered result in the observed usage scenario.
How Should Developers Prioritize GPU Optimization?
GPU optimization rarely has a single root cause. A GPU Bound frame may be the result of geometry complexity, invisible primitives, Overdraw, bandwidth, shader complexity, or inefficient resource usage.
A more effective workflow is to:
- Identify GPU Bound frames.
- Examine GPU workload trends.
- Determine whether geometry, Overdraw, bandwidth, shaders, or resources are contributing to the workload.
- Locate the specific assets or rendering operations responsible.
- Evaluate the impact of each potential optimization.
- Prioritize changes based on their actual contribution to GPU pressure.
This approach allows developers to move from "the GPU is too busy" to a much more actionable question:
"Which rendering workload is consuming the GPU budget, and what can we change?"
GOT Online GPU Mode provides these metrics in one analysis workflow, helping developers investigate GPU bottlenecks from multiple perspectives.
What Should Unity Developers Take Away?
- A GPU Bound frame identifies GPU pressure, but not its root cause.
- High mesh density and excessive invisible primitives can indicate inefficient geometry submission.
- Overdraw should be investigated carefully, especially for transparent effects, particles, and UI.
- Texture settings, RenderTexture operations, and rendering resolution can have a significant impact on bandwidth.
- Shader Cycles can help identify which part of shader execution is responsible for high shader cost.
- Resources with low or zero rendering utilization should be checked for unnecessary loading or incomplete test coverage.
- Mipmap sampling statistics can reveal textures whose resolution is higher than their actual rendering requirements.
FAQ
Q1. What does GPU Bound mean in GOT Online?
A frame is classified as GPU Bound when GPU Clocks × Target FPS >= GPU Maximum Frequency × 80%. It indicates that the GPU is consuming a high number of clock cycles and may not have enough available cycles to sustain the target frame rate.
Q2. Does a GPU Bound frame tell you what is causing the bottleneck?
No. GPU Bound identifies GPU pressure but does not directly identify the root cause. Developers should further analyze metrics such as GPU Shaded, GPU Primitive, Overdraw, bandwidth, and Shader Cycles.
Q3. How can high Overdraw be reduced in a mobile game?
Common approaches include limiting particle counts, reducing the screen coverage of transparent effects, and disabling less important effects on lower-end devices.
Q4. Why should developers check visible versus total primitives?
The comparison can reveal whether many primitives are being submitted to the GPU but subsequently removed through GPU-side culling. A low visible primitive ratio from specific camera angles may indicate that large models should be better split or culled earlier.
Q5. How can developers identify oversized textures?
Mipmap sampling statistics can help. If Mipmap Level 0 has a very low sampling rate, the texture resolution may be higher than necessary for its actual usage. Developers can inspect the resource's lifecycle and sampling levels before deciding whether to reduce its resolution.
Q6. Can reducing rendering resolution help with GPU bandwidth?
Yes. Lowering rendering resolution reduces the number of pixels involved in texture sampling and can reduce RenderTexture load/store operations, which can help lower bandwidth.
Top comments (0)