DEV Community: GameOptim

How Can Unity Developers Identify and Reduce GPU Bottlenecks on Mobile Devices?

GameOptim — Thu, 03 Sep 2026 07:33:25 +0000

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.

A Breakdown of UGUI Performance Bottlenecks: Rendering vs. Logic

GameOptim — Tue, 01 Sep 2026 03:47:15 +0000

When optimizing UGUI, the first question to answer is: where is the cost actually coming from? Without this understanding, optimization efforts are likely to be scattered and ineffective.

Problem / Scenario

Mobile game teams often encounter frame-rate drops and device heating as UI complexity grows. The UI system seems simple on the surface—just images and text—but the underlying cost structure is more nuanced than many developers realize.

The Two Dimensions of UI Performance

UGUI performance cost breaks down into two categories: rendering and logic.

Rendering

DrawCall

DrawCall is primarily a CPU cost. Each draw command issued to the GPU requires state setup and parameter passing. High DrawCall counts directly increase CPU usage.

Benchmark targets from real projects:

Complex MMO-style HUD: under 30 Draw Calls
Combat UI: single-digit Draw Calls

These targets apply when the UI is composited on top of a 3D scene. Full-screen UIs without scene rendering can have a slightly relaxed budget.

Overdraw

Overdraw measures how many times screen pixels are redrawn by UI elements. Every image or button placed on screen contributes. Translucent UIs (common in high-tech visual styles) are especially prone to Overdraw waste since the 3D scene behind must remain visible.

Logic

Three functions account for nearly all UI logic cost:

1. EventSystem.Update

Two components:

Event detection: Every frame, Unity traverses all interactive UI elements to check for intersection with touch points. Complexity scales with the number of interactive elements.
Event callback logic: Code inside onClick and similar callbacks runs within this function (though this is application logic, not UI system overhead).

2. Canvas.SendWillRenderCanvases

This function recalculates vertex data for dirty UI elements. Vertex attributes (positions, UVs, etc.) are stored in C# arrays. When text content changes—or any property affecting vertex positions changes—the arrays must be rebuilt. The data is then transferred to Mesh objects for rendering.

Key insight: This is pure main-thread C# work. The more elements change per frame, the higher the cost.

3. Canvas.BuildBatch / BatchJob

After vertex data is ready, each UI element still has its own mesh. Drawing them one by one would result in an unacceptably high DrawCall count. BuildBatch merges compatible elements into larger meshes.

Batching considers:

Same atlas (texture)
Same material
Depth order in the VisibleList (sorted by Depth → Material → Atlas → Hierarchy priority)
Whether elements overlap
Rendering order adjustments for non-overlapping elements

The batching calculation itself has non-trivial CPU cost. However, a significant portion of BatchJobs can run on worker threads, which helps on multi-core devices.

Key Takeaway

In practice, EventSystem.Update is rarely the primary bottleneck. The usual suspects are:

DrawCall and Overdraw on the rendering side
SendWillRenderCanvases and BuildBatch on the logic side

Knowing which one to target is half the battle. The remaining sections in this series dive into optimization techniques for each area, using a real MMO weapon UI panel as a case study.

How Can Unity Developers Identify the Functions Behind Game Stutters?

GameOptim — Thu, 27 Aug 2026 03:35:37 +0000

Summary

Game stutters are one of the most important performance issues for game developers because they can interrupt gameplay and directly affect the player experience.

GameOptim GOT Online introduces a new Stutter Frame Summary feature that performs deeper attribution across all stutter points in a performance report. It helps developers identify the functions that contribute most frequently to stutters and have the greatest optimization potential.

Introduction

Finding the cause of a stutter is not always straightforward. A performance report may contain many stutter frames, and developers need to understand not only how much CPU time each function consumes, but also how frequently it contributes to problematic frames.

The latest stutter analysis workflow in GOT Online combines stutter frame distribution, CPU time data, function call stacks, and function-level statistics to make this analysis more systematic.

How Can Developers Get an Overview of All Stutter Frames?

The latest stutter analysis page provides information for all stutter frames in the report.

By combining the total CPU time curve in the Stutter Frame Summary with the stutter frame markers, developers can quickly understand the CPU time and distribution of stutter points across the game.

Note: The CPU time curve takes the maximum CPU time from every 10 frames, while stutter frame markers represent the actual CPU time of each individual frame. As a result, the points and lines in the chart may not always align exactly.

This overview provides a starting point for identifying where stutters occur and how CPU time is distributed across those frames.

How Can Developers Analyze Animation and Physics Stutters?

The latest update also adds statistics for animation stutters and physics stutters.

Developers can analyze these two types of stutters in the Key Function Analysis page. The stutter frame data can also be filtered by type, making it easier to locate and investigate specific categories of stutters.

How Can a Call Stack Flame Chart Reveal Stutter Hotspots?

The stutter function call stack flame chart provides a visual representation of function execution across stutter frames.

Developers can use it to examine:

The proportion of time spent by functions across all stutter frames
Function nodes at different call-stack depths
Calling relationships between functions
Hot functions that make a larger contribution to stutter frames

These observations can then be combined with the stutter function list below the chart for more detailed investigation.

How Can You Trace the Same Function Across Different Stutter Frames?

Clicking a function node highlights all function nodes with the same name in the flame chart.

This makes it easier to understand how the same function contributes across the aggregated stutter frames, including its overall proportion and its impact when called by different parent functions.

This is particularly useful when the same function appears in multiple call paths.

How Can You Inspect a Function's Call Relationships?

Double-clicking a function node zooms into its details in the flame chart.

The chart then displays the function's calling and called-by relationships in greater detail. At the same time, the corresponding function stack is automatically expanded in the function stack list.

This allows developers to determine which nodes may have higher optimization value based on their position and contribution within the call stack.

Which Function Metrics Should Developers Prioritize?

The stutter function list provides common metrics such as:

Total time
Total time percentage
Self time
Self time percentage

However, two additional metrics are particularly important when prioritizing stutter optimization:

Distributed Stutter Points indicates the number of stutter frames in which a function was called.

Key Stutter Points indicates the number of stutter frames where the function's total call time exceeded 41.67 ms.

A function with a high number of key stutter points has a significant impact across multiple stutter frames. This can make it a higher-priority optimization target than a function that consumes considerable CPU time but only affects a small number of stutter frames.

How Can Developers Simulate the Impact of Optimizing a Function?

GOT Online also allows developers to deselect a function node and recalculate the Stutter Frame Summary.

This effectively simulates the stutter frame situation after removing the selected function's CPU time.

If subtracting the function's execution time reduces a stutter frame's CPU time to below 83.33 ms, that frame is marked as a green improved stutter frame.

This provides a direct way to estimate how much a specific function contributes to individual stutter frames without requiring developers to immediately modify and retest the code.

How Can This Simulation Help Prioritize Optimization?

Function-node deselection allows developers to visually evaluate the impact of individual functions on stutter frames and simulate the potential result of optimization.

This helps answer an important practical question:

Which function is worth optimizing first?

Instead of prioritizing functions based only on total CPU time, developers can evaluate how many problematic frames a function affects and how much those frames could improve if its execution cost were reduced.

This provides a more targeted basis for optimization prioritization.

How Can Developers Investigate Important Functions Further?

For functions that require additional investigation, developers can open Function Details from the operation column.

The details view provides information about the function's CPU time and call count. Developers can also add the function to a function group for further analysis.

This makes it possible to move from identifying a stutter hotspot to examining the specific function behavior in greater detail.

What Should Unity Developers Take Away?

Analyze all stutter frames rather than focusing on a single frame.
Use stutter frame distribution together with CPU time to identify recurring problems.
Pay attention to Key Stutter Points, not just total CPU time.
Use the call stack flame chart to understand where functions contribute across different call paths.
Use function-node deselection to simulate potential improvements and prioritize optimization targets.

FAQ

Q1. What is the Stutter Frame Summary in GOT Online?

The Stutter Frame Summary aggregates information across stutter frames in a performance report, helping developers understand stutter distribution and CPU time and identify functions that contribute significantly to stutters.

Q2. What does the Key Stutter Points metric indicate?

It indicates the number of stutter frames in which a function's total call time exceeds 41.67 ms. A high value means the function has a significant impact across multiple stutter frames.

Q3. What is the difference between Distributed Stutter Points and Key Stutter Points?

Distributed Stutter Points represents the number of stutter frames in which a function was called. Key Stutter Points represents the number of stutter frames where that function's total call time exceeded 41.67 ms.

Q4. What happens when a function node is deselected?

GOT Online recalculates the Stutter Frame Summary after subtracting the selected function's execution time. If a stutter frame falls below 83.33 ms after the subtraction, it is marked as a green improved stutter frame.

Q5. Can developers analyze animation and physics stutters separately?

Yes. The latest update provides separate animation stutter and physics stutter statistics, which can be analyzed and filtered in the Key Function Analysis page.

How Can You Monitor Specific Functions More Precisely in Complex Game Projects?

GameOptim — Tue, 25 Aug 2026 03:04:52 +0000

Introduction

GameOptim's existing function module classification provides a straightforward and efficient way to locate or monitor performance issues. However, this approach may not provide enough granularity for some large or complex projects.

For example, when a new gameplay feature is introduced during development, developers may need to monitor a specific set of functions related to that feature. This creates a need for more detailed function classification.

The latest version of GameOptim introduces Custom Function Groups, allowing developers to classify functions in a more precise and personalized way.

💡 New users can get 2 hours of free GOT Online testing time after completing registration.

Summary

GameOptim's existing function module classification provides a simple way to locate and monitor performance issues.
Large or complex projects may require more granular function classification for targeted monitoring.
Custom Function Groups allow developers to create more precise and personalized function categories.
A custom function group can contain up to 15 functions.
Once configured, function groups are automatically applied to all reports within the same project.
Developers can view total time, self time, function count, and the function group's share of total CPU time.

Why Do Complex Projects Need More Granular Function Monitoring?

Predefined function module classifications provide a quick way to locate and monitor performance issues.

However, they may not be sufficiently granular for some large or complex projects.

For example, when a new gameplay feature is added during development, developers may want to monitor only the functions related to that feature. In this situation, a more detailed classification of functions can make targeted monitoring possible.

This is the purpose of Custom Function Groups: to allow developers to define function groups based on their specific monitoring needs.

How Can You Create a Custom Function Group?

Project administrators can create, edit, or delete function groups based on their requirements.

After a function group is configured, it is automatically applied to all reports within the same project. Developers therefore do not need to configure the same function group repeatedly for individual reports.

How Do You Select Functions for a Custom Function Group?

On the Custom Function Group editing page, GameOptim can list up to 4,000 functions with the highest total time in the current report.

The list provides two metrics for reference:

Average Total Time
Average Self Time

A custom function group can contain up to 15 functions.

Developers can select functions directly from the list or use the search function to locate a specific target function.

What Performance Data Can You See After Saving a Function Group?

After saving a function group, developers can view the following information in the function group list:

Average Total Time
Average Self Time
Function Count
Function Group / Total CPU Time Percentage

The performance chart also shows the total time of each function group, allowing developers to view the total execution time of different groups.

How Can You Inspect the Functions Within a Group?

Developers can click the Details button in the function group list to view information about the individual functions within a group.

The display rules for these individual functions are consistent with those used for the function group itself, allowing developers to examine the relevant performance data at the function level.

What Is the Practical Workflow?

A typical workflow for using Custom Function Groups is:

Identify the functions that require targeted monitoring.
Open the Custom Function Group editing page.
Review the functions listed from the current report.
Select up to 15 functions or locate specific functions through search.
Save the function group.
Monitor the group's performance data across reports within the project.
Open the group details when individual function information is needed.

Key Takeaways

Existing function module classification provides a straightforward way to locate and monitor performance issues.
More granular function classification can be useful when complex projects require targeted monitoring of specific gameplay features.
Custom Function Groups allow developers to create personalized function classifications.
Each function group can contain up to 15 functions.
Up to 4,000 functions ranked by total time can be listed on the editing page for the current report.
Once configured, a function group is automatically applied to all reports within the same project.
Developers can analyze both group-level and individual-function performance data.

FAQ

When is a Custom Function Group useful?

It can be useful when developers need to monitor a specific set of functions, such as functions associated with a newly added gameplay feature, rather than relying only on broader function module classifications.

How many functions can one Custom Function Group contain?

A custom function group can contain up to 15 functions.

Do I need to configure the function group for every report?

No. Once configured, the function group is automatically applied to all reports within the same project.

How many functions can be displayed when editing a group?

The editing page can list up to 4,000 functions ranked by total time in the current report.

What information is available for a function group?

The function group list displays Average Total Time, Average Self Time, Function Count, and Function Group / Total CPU Time Percentage. The performance chart also shows the total time of each function group.

Why Do Developers Need Cross-Module Performance Dashboards Instead of Separate Reports?

GameOptim — Thu, 20 Aug 2026 09:55:33 +0000

Summary

GameOptim has introduced Custom Dashboard, allowing developers to build reusable dashboards that combine performance metrics from multiple report modules into a single view.

Instead of navigating through separate GPU, runtime, thermal, and power reports, developers can correlate key indicators more efficiently and identify optimization priorities faster.

Why Are Separate Reports Sometimes Not Enough?

Performance optimization isn't about isolated metrics.
When FPS suddenly decreases, the underlying cause may begin with GPU workload, continue through thermal accumulation, trigger CPU frequency reduction, and finally appear as frame instability.
Looking at these reports independently often hides the relationship between them.
Developers need context—not just data.

How Does Custom Dashboard Work?

Project administrators can create reusable dashboards by selecting up to 15 performance metrics from six categories:

Runtime Information
GPU
Overall Performance Trend
Key Function Analysis
Power Consumption
Temperature Change

Once created, dashboards automatically appear across all reports within the same project.

Built-in Templates for Common Optimization Scenarios

To simplify everyday investigations, GameOptim provides several preset templates:

Thermal Throttling Analysis
GPU Pressure & Power Consumption
Snapdragon Vertex Pressure Analysis
UGUI CPU Cost Analysis

These templates are fully customizable and can be adapted to different projects.

Example: Diagnosing Thermal Throttling

Suppose a game gradually loses FPS during gameplay.
Using the Thermal Throttling Analysis dashboard, developers can immediately compare:

FPS
GPU Frequency
CPU Frequency
Temperature

The relationship becomes obvious:
Higher GPU workload increases chip temperature, thermal accumulation triggers CPU frequency reduction, and frame rate eventually drops.
Instead of checking four independent reports, developers identify the bottleneck in one dashboard before moving into detailed GPU analysis.

Additional GPU Analysis Improvements

GameOptim has also updated the GPU Analysis module.
Metrics are now organized into:

Primary Metrics
Secondary Metrics
Reference Metrics

Child parameters now include overview summaries, allowing developers to quickly identify abnormal values without expanding every metric.

Current Limitations

At the moment, Custom Dashboard is available for GOT Online reports.
Support for Unreal Engine reports and Mini Game reports is planned for future updates.

FAQ

How many metrics can one dashboard contain?
Up to 15 metrics.

Can multiple projects share the same dashboard?
Dashboards are automatically reused across reports within the same project.

Are preset templates editable?
Yes. Every template can be customized.

Does this feature replace existing report modules?
No. It complements them by providing a higher-level cross-module view for faster diagnosis.

If you'd like to experience the feature yourself, register for GOT Online on GameOptim and receive 2 hours of free trial access.

How Can Unity Developers Trace Frame-Level CPU Bottlenecks More Precisely?

GameOptim — Tue, 18 Aug 2026 06:47:53 +0000

Introduction

When a Unity game shows a CPU performance anomaly, module-level statistics may not be enough to identify the actual cause. A function can be called repeatedly across consecutive frames, originate from another module, or appear as part of untracked profiling overhead.

The latest GameOptim GOT Online update addresses these cases with frame-level performance analysis, an Overhead breakdown, and cross-module function call tracking. The update also adds Unity Profiler-based rendering metrics, rendering resolution data, and asynchronous loading priority statistics to provide more context during performance analysis.

Summary

Frame-level analysis improves function curve precision to individual frames, making short CPU spikes and abnormal frame ranges easier to locate.
The new Overhead module separates untracked function time and SDK collection overhead from identified module costs.
Cross-module call paths help developers trace functions back to the root functions that actually triggered them.
Unity Profiler-based DrawCall, Batches, and Triangle statistics provide rendering information when OpenGL data cannot be obtained through the SDK.
Additional rendering and loading parameters provide more context for evaluating rendering configuration and scene-loading strategies.

How Does Frame-Level Analysis Help Find CPU Performance Problems?

The Overall Performance Trend section in GOT Online now supports frame-level analysis across its tabs, with function curve precision improved to individual frames.

This is particularly useful when a function is called continuously across multiple frames.

For example, when analyzing the UI module, developers can inspect the performance behavior of a function on each individual frame instead of relying only on a broader trend. The corresponding function stack is also available in the stack information area below the performance curve.

This makes it easier to answer questions such as:

Which specific frame contains the CPU spike?
Is a function consistently expensive across consecutive frames?
Does the abnormal cost occur only within a particular frame range?
Which functions are responsible for the observed cost?

The module timing statistics can also help developers identify relationships between different function modules and narrow down abnormal frames or time ranges more precisely.

Why Is the New Overhead Module Useful?

Module-level CPU statistics do not necessarily account for every piece of execution time.

The new Overhead module in GOT Online collects:

Untracked function execution time
Performance overhead generated by GameOptim's data collection

This distinction is useful when evaluating the actual contribution of different CPU costs to frame performance.

Instead of treating every measured cost as an optimization target, developers can use the Overhead breakdown to distinguish between key performance factors and secondary costs.

This can help avoid spending optimization effort on costs that have little practical impact.

What Can You See Inside Overhead?

After expanding the Overhead module, developers can inspect more detailed timing information for:

Untracked functions
SDK data collection overhead

This information can also help evaluate whether specific data collection modules should remain enabled during a test.

For example, developers can use the collected overhead information to assess the impact of modules such as Resources and Lua memory collection and adjust the profiling configuration when appropriate.

The goal is not simply to minimize profiling overhead, but to make the collection process better aligned with the performance question being investigated.

How Can Cross-Module Call Paths Reveal the Actual Root Function?

A function's performance cost does not always originate from the module where the function is displayed.

Previously, when analyzing the Animation performance page, developers could primarily observe calls under animation-related root functions. If an animation function was called by a root function belonging to another module, developers needed to switch to the corresponding module and inspect its parent function stack.

The updated Overall Performance Trend analysis makes this relationship easier to inspect.

In the Animation performance page, developers can enable "Animation function calls from other modules" from the upper-right corner. This allows animation functions called by functions from other modules to be displayed directly within the Animation analysis.

Developers can also click the call path next to a function name in the function stack to trace the animation function back to the root function that invoked it.

This provides a more complete view of the function call chain:

Root function → Cross-module call → Target function

Instead of optimizing the function where the cost becomes visible, developers can investigate the function that actually initiated the call.

Which New Rendering Metrics Are Available?

The update adds several additional performance parameters.

DrawCall, Batches, and Triangles

The Rendering module now provides DrawCall, Batches, and Triangle statistics based on the Unity Profiler.

This is particularly useful when the SDK cannot obtain OpenGL-related data. Developers can still inspect these rendering metrics during performance testing rather than losing visibility into basic rendering statistics.

These values provide additional context when investigating rendering-related performance behavior.

Rendering Resolution and Interval

The Rendering module also adds:

Rendering resolution width
Rendering resolution height
Rendering interval

These parameters make it easier to monitor the rendering configuration used during a test and correlate rendering settings with observed performance behavior.

How Can Loading Priority Help Analyze Scene Loading?

The Loading module now includes the configured asynchronous loading priority from Unity's Application.backgroundLoadingPriority.

This allows developers to inspect the loading priority configuration when evaluating scene loading time.

Rather than looking only at the final loading duration, developers can also check whether the current loading strategy leaves room for optimization through loading configuration.

What Should You Check First When Investigating a CPU Performance Issue?

A practical investigation flow based on these capabilities is:

Locate the abnormal frame or time range.
Use frame-level analysis to identify where the CPU performance anomaly occurs.
Inspect the function stack.
Determine which functions contribute to the observed cost instead of looking only at module-level totals.
Check cross-module calls.
If the function appears expensive within one module, verify whether it was actually triggered by a root function from another module.
Review Overhead.
Separate identified application costs from untracked functions and SDK collection overhead.
Check rendering or loading parameters when relevant.
Use DrawCall, Batches, Triangles, rendering resolution, rendering interval, or asynchronous loading priority to provide additional context.
Prioritize the optimization target.
Focus on the costs that materially contribute to the performance problem rather than treating every measured value as an optimization requirement.

Practical Recommendations

Problem	What to inspect	How it helps
Short CPU spike	Frame-level function analysis	Identifies the specific abnormal frame
Continuous function cost	Per-frame function curve and stack	Shows how the cost changes across frames
Unclear CPU attribution	Overhead module	Separates untracked time and SDK collection overhead
Function appears expensive in the wrong module	Cross-module calls and call paths	Helps trace the function back to its root caller
Rendering performance is unclear	DrawCall, Batches, Triangles	Provides additional rendering statistics
Rendering configuration may affect results	Resolution and rendering interval	Adds configuration context to performance data
Scene loading takes too long	`Application.backgroundLoadingPriority`	Helps evaluate the configured asynchronous loading strategy

Key Takeaways

Frame-level analysis is useful for short-lived CPU anomalies because it allows developers to inspect function behavior at individual-frame granularity.
Overhead should be separated from application-level costs so profiling overhead and untracked functions do not automatically become optimization targets.
Cross-module call paths matter when the visible bottleneck is not the root cause. Tracing the caller can reveal where the expensive function was actually triggered.
Rendering and loading parameters provide important context when analyzing DrawCalls, Batches, Triangles, rendering configuration, or scene loading.
Effective performance analysis depends not only on finding expensive functions, but also on understanding when they execute, what calls them, and what portion of the measured cost is actually relevant to the application.

FAQ

Does frame-level analysis replace the function stack?

No. Frame-level analysis shows when a function's performance cost occurs, while the function stack provides information about the functions involved in that execution. Using both together provides a more precise way to investigate abnormal frames.

What does the Overhead module include?

The Overhead module includes untracked function execution time and SDK data collection overhead generated during GameOptim testing. These values help developers distinguish measured overhead from identified application module costs.

Why should I check cross-module function calls?

A function displayed under one module may have been called by a root function belonging to another module. Cross-module call paths allow developers to trace the function back to its actual caller instead of investigating only the module where the cost becomes visible.

Can GOT Online show DrawCalls when OpenGL data is unavailable?

The updated Rendering module provides DrawCall, Batches, and Triangle statistics based on the Unity Profiler, allowing these rendering metrics to remain available when the SDK cannot obtain OpenGL data.

Why is `Application.backgroundLoadingPriority` useful for performance analysis?

The Loading module now records the configured asynchronous loading priority. This gives developers additional information when evaluating scene loading time and determining whether the loading strategy may provide an opportunity for optimization.

How Can You Analyze the GPU Performance of VFX Independently in Unity?

GameOptim — Thu, 13 Aug 2026 04:03:46 +0000

Summary

VFX performance pressure is generally more significant on the GPU than on the CPU.
Isolating VFX from backgrounds, gameplay elements, and other rendering factors makes GPU analysis more reliable.
GPU Clocks can help identify which VFX produce the highest GPU pressure.
GPU pressure can be further investigated from three perspectives: vertex pressure, fragment pressure, and shader complexity.
Metrics such as GPU Input Primitive, Culled Primitives, GPU Fragment Shaded, GPU Total Shader Cycles, and GPU Shader Instructions can help identify the underlying causes.

How Should You Prepare a VFX Performance Test Package?

During gameplay, VFX generally have a relatively limited impact on CPU performance, while their performance pressure is primarily concentrated on the GPU. Therefore, the analysis should focus mainly on GPU performance.

To reduce interference from other game elements, it is recommended to create a dedicated package containing the project's VFX resources.

The test environment can use a default skybox or a static texture as the background, minimizing the impact of the scene itself on the results.

The package should also support playing VFX individually. If the project contains a large number of effects, you can add automatic playback and effect navigation to make testing more efficient.

After each effect finishes playing, clear the relevant resources when appropriate. This helps prevent excessive memory usage from accumulating during long test sessions.

How Can You Separate VFX in the GOT Online Report?

When many effects are tested in the same package, it is important to distinguish individual VFX in the performance report.

When building the test package, use the UWAEngine.Tag API provided by GameOptim to divide the test into separate scenes or tagged intervals, with each VFX treated as an independent analysis unit.

This makes it easier to map performance data in GOT Online back to a specific effect.

How Can You Quickly Identify Expensive VFX?

After uploading the test data to GameOptim GOT Online, open:

GPU Mode → Performance Overview → Pressure Localization

The GPU analysis report provides a detailed view of the rendering performance of each VFX.

Why Is GPU Clocks Useful for VFX Analysis?

GPU Clocks represents the number of GPU clock cycles used per frame during the test. It provides a direct indication of the GPU workload for the current frame.

By comparing the GPU Clocks curve with the previously defined VFX scene names or tags, developers can quickly identify which effects generate relatively high GPU pressure.

When many VFX are included in the test package, the Scene Overview → Performance Overview page can make the comparison more efficient.

The scene performance table provides performance metrics for all tested effects. Developers can sort the table by GPU Clocks in descending order to quickly identify the VFX with the highest GPU pressure and prioritize them for optimization.

How Can You Locate the Source of VFX GPU Pressure?

After identifying the most expensive VFX, the next step is to determine why they are expensive.

A useful way to break down VFX GPU pressure is to analyze three major areas:

Vertex pressure
Fragment pressure
Shader complexity

Each represents a different stage or source of GPU workload.

Is High Triangle Count Causing the Vertex Pressure?

Triangle count can be checked in the Rendering Statistics module.

For a VFX with a relatively high triangle count, combine this information with:

GPU Input Primitive
Culled Primitives

These metrics can help determine why the effect is processing a large number of primitives.

For example, a high triangle count combined with a large number of culled primitives may indicate that some geometry is being submitted for rendering but ultimately contributes little to the visible result.

This provides a more targeted direction for checking and optimizing potentially wasted geometry.

Is Overdraw Causing the Fragment Pressure?

GPU Fragment Shaded directly reflects the workload generated during the fragment shading stage.

Because the dedicated VFX test package removes the influence of rendering resolution and post-processing on the effect's GPU workload, this metric can be used as a useful indicator of the VFX's own rendering and overdraw pressure.

For VFX with relatively high fragment pressure, developers can manually perform an Overdraw Dump during testing.

The Overdraw page provides an overdraw heatmap, allowing developers to visually inspect where excessive fragment processing occurs.

For example, an effect may not look particularly complex in the final image while still generating substantial overdraw.

Left: VFX appearance | Right: Overdraw heatmap

This is an important case to investigate because visual complexity and rendering cost do not always correlate directly.

Is Shader Complexity Causing the GPU Pressure?

Shader execution is another important source of VFX GPU workload.

GPU Total Shader Cycles reflects the overall shader computation complexity during VFX playback, while GPU Shader Instructions represents the number of shader instructions executed by the GPU.

By comparing these metrics with the VFX's overall GPU workload, developers can determine whether shader computation is a major contributor to the effect's GPU pressure.

If shader complexity is confirmed as the primary bottleneck, the next step is to analyze the individual shaders used by the effect.

For single-shader analysis, developers can use the Mali Offline Compiler to obtain metrics such as the shader's instruction count and clock cycle count.

This provides a more granular view of shader execution cost and can help guide further shader optimization.

What Is a Practical Workflow for VFX GPU Optimization?

A practical workflow can be summarized as follows:

Isolate VFX from other gameplay and rendering elements.
Create independent test units for individual effects.
Tag each VFX using UWAEngine.Tag to simplify report analysis.
Run GPU analysis with GameOptim GOT Online.
Rank VFX by GPU Clocks to identify the most expensive effects.
Analyze vertex pressure using triangle count, GPU Input Primitive, and Culled Primitives.
Analyze fragment pressure using GPU Fragment Shaded and Overdraw data.
Analyze shader complexity using GPU Total Shader Cycles and GPU Shader Instructions.
Inspect individual shaders with Mali Offline Compiler when necessary.
Optimize the actual bottleneck instead of optimizing VFX based only on visual complexity.

Key Takeaways

VFX should ideally be analyzed in an isolated test environment rather than directly inside complex gameplay scenes.
GPU Clocks is useful for quickly ranking VFX by GPU workload.
High GPU pressure does not necessarily have a single cause. It may come from excessive geometry, overdraw, or shader computation.
Triangle count + GPU Input Primitive + Culled Primitives can help investigate vertex-related pressure.
GPU Fragment Shaded + Overdraw can help identify fragment and overdraw pressure.
GPU Total Shader Cycles + GPU Shader Instructions can help determine whether shader computation is a major contributor.
When higher-level GPU metrics point to shader complexity, individual shaders can be analyzed further with Mali Offline Compiler.

FAQ

Should VFX performance be analyzed separately from the game scene?

Yes, when the goal is to understand the GPU cost of the VFX itself. Isolating effects removes interference from elements such as terrain, characters, background rendering, resolution, and post-processing, making the resulting performance data easier to interpret.

Which metric should I check first when comparing multiple VFX?

GPU Clocks is a useful starting point because it provides a direct indication of GPU workload per frame. Sorting VFX by GPU Clocks can quickly reveal which effects deserve further investigation.

Does a high triangle count always mean that a VFX is expensive?

Not necessarily. Triangle count should be analyzed together with metrics such as GPU Input Primitive and Culled Primitives to understand how much geometry is actually contributing to the GPU workload.

How can I determine whether overdraw is the main problem?

Check GPU Fragment Shaded and use an Overdraw Dump to inspect the overdraw heatmap. A VFX can appear visually simple while still generating significant overdraw.

How can I analyze a specific shader used by a VFX?

After identifying shader complexity as a potential source of GPU pressure, use Mali Offline Compiler to analyze the individual shader's instruction count and clock cycle count.

How Can You Quickly Find Logic Code Performance Bottlenecks in Unity?

GameOptim — Tue, 11 Aug 2026 08:56:41 +0000

Summary

When profiling Unity games, logic code is often one of the hardest areas to optimize. A single frame can contain hundreds or thousands of function calls, and it can be difficult to tell which function is actually responsible for a performance spike.

The problem becomes even more obvious when call stacks get deeper. You may know that a particular frame is expensive, but still spend a lot of time going through different call paths to find the function that is really contributing to the cost.

GameOptim GOT Online recently added several improvements to its logic code performance analysis, making it easier to move from a large amount of profiling data to the functions that actually matter.

The update focuses on three areas:

Call stack flame charts for a more visual way to inspect function hierarchies
Function search and call-stack linking to find the same function across different call paths
Top 20 reverse-call analysis to quickly identify functions with high self-time and overall impact

So, how can these features make Unity logic code profiling faster?

How Can a Flame Chart Help Find Unity Logic Code Bottlenecks?

Deep call stacks can be difficult to read when you're working with raw profiling data.

A function may call several other functions, which then call more functions. When the hierarchy becomes deep enough, simply reading the call stack doesn't always make it obvious where most of the time is actually being spent.

GameOptim GOT Online now provides a visual flame chart for logic code analysis.

The chart makes the function hierarchy much easier to understand. You can see how execution time is distributed across different functions and drill down into the hierarchy to identify expensive nodes.

The analysis can be performed at different levels:

Overall test range — Which functions consume most of the total execution time?
Specific scenario — Which functions are expensive during a particular gameplay sequence or combat scenario?
Specific frame — Which functions are responsible for a frame-time spike?

This makes it easier to move from a high-level performance overview to a specific function that needs investigation.

Instead of manually following a long call stack, you can visually inspect the hierarchy and quickly narrow down the expensive functions.

How Can You Find the Same Function Across Different Call Paths?

Another common problem during profiling is that the same function can appear in multiple call paths.

For example, a function might be called by several different systems. Looking at only one call stack doesn't necessarily tell you how much that function contributes to the overall performance cost.

GameOptim GOT Online now adds function search to the overall performance trend analysis.

You can search for part of a function name, and the system will perform a fuzzy match against the available functions.

This makes it easier to answer questions such as:

Where is this function being called?
Is the same function expensive in multiple systems?
Which parent functions contribute most to its execution time?
Does this function become a bottleneck only in a specific gameplay scenario?

More importantly, the function search is linked with the flame chart.

When you search for a function, matching nodes in the call stack are automatically highlighted. Unrelated nodes are temporarily faded out, making the matching functions much easier to spot.

This is particularly useful when the same function appears in multiple branches of a large call tree.

Instead of checking each path manually, GameOptim lets you focus on the matching nodes and build a more complete performance picture of that function.

How Can Reverse Call Analysis Identify Common Bottlenecks?

Sometimes you don't know which function you should investigate in the first place.

In that case, starting from the call tree and manually looking for expensive functions can still take a significant amount of time.

The updated reverse-call analysis in GameOptim GOT Online provides another way to approach the problem.

When you switch to reverse-call analysis, GOT Online lists the Top 20 functions with the highest self-time.

It also calculates their total cost across different calling paths.

This helps answer a slightly different question:

Which functions are expensive regardless of where they are called?

A function may appear in multiple call paths and contribute significant execution time across all of them. Instead of manually checking every path, you can start with the functions that have the largest overall impact.

This can be especially useful when looking for common bottlenecks in gameplay logic, combat systems, AI, update loops, or other frequently executed code.

What Is the Fastest Way to Analyze Unity Logic Code Performance?

There isn't a single profiling view that works for every performance problem.

A practical workflow with GameOptim GOT Online is to combine the three analysis methods:

Start with the overall performance trend to identify problematic frames or time ranges.
Use the flame chart to understand the function hierarchy and locate expensive branches.
Search for specific functions when you already have a suspicious function in mind.
Use reverse-call analysis to identify functions with high self-time and broad impact.

This gives you both top-down and bottom-up approaches to the same profiling data.

The goal isn't simply to find the function with the largest number.

The more useful question is:

Which function is expensive, why is it being called, and how widely does it affect the frame?

That's where combining different views becomes useful.

FAQ

What is logic code performance analysis in Unity?

Logic code performance analysis focuses on the CPU cost of gameplay and system logic, such as combat, AI, game state updates, and other scripts or functions executed during gameplay.

Tools such as GameOptim GOT Online can help developers inspect function-level execution time and call relationships to identify expensive code paths.

How does GameOptim GOT Online help with Unity profiling?

GameOptim GOT Online provides online performance analysis based on profiling data. For logic code, it provides call-stack visualization, function search, and reverse-call analysis to help developers locate CPU bottlenecks more efficiently.

What is a flame chart useful for in Unity?

A flame chart provides a visual representation of function call relationships and execution time.

In GameOptim GOT Online, the logic code flame chart can be used to inspect the overall test range, specific scenarios, or individual frames, making it easier to identify expensive functions and call paths.

Can I find the same function in multiple Unity call paths?

Yes. GameOptim GOT Online supports function search across the logic code analysis view.

When a function is found in multiple call paths, the corresponding nodes in the flame chart can be highlighted, making it easier to understand how the same function contributes to different execution paths.

What is reverse-call analysis?

Reverse-call analysis starts from individual functions rather than following the call hierarchy from the top.

In GameOptim GOT Online, the reverse-call view can show the Top 20 functions with the highest self-time and analyze their cost across different calling paths.

This can help developers quickly find functions that have a broad performance impact.

Is GameOptim a replacement for the Unity Profiler?

GameOptim GOT Online is not intended to replace the Unity Profiler.

The Unity Profiler remains an important tool for collecting and inspecting profiling data. GameOptim focuses on making large amounts of profiling data easier to analyze, especially when developers need to identify bottlenecks across different frames, scenarios, and call paths.

For teams dealing with complex Unity performance problems, using Unity Profiler together with GameOptim can provide a more complete profiling workflow.

Conclusion

Finding a Unity performance bottleneck is often less about collecting profiling data and more about making sense of it.

When call stacks become large and the same functions appear across multiple paths, manually going through every frame and every hierarchy can quickly become inefficient.

The latest logic code analysis improvements in GameOptim GOT Online provide three practical ways to reduce that overhead:

Visualize call stacks with flame charts
Search and highlight the same function across different paths
Use reverse-call analysis to identify high-impact functions

If you're working on a Unity project where gameplay logic is generating CPU spikes or frame-time problems, these views can provide a faster way to move from "something is expensive" to "this function is the bottleneck, and these are the paths affecting performance."

GameOptim is continuing to improve its profiling and performance analysis workflow to make Unity performance optimization more practical for developers.

Should You Automatically Enable 1/4 Render Target for High-Overdraw Effects Instead of Lowering Camera Resolution?

GameOptim — Thu, 06 Aug 2026 09:58:35 +0000

🌐 Website: www.gameoptim.com

Summary

Reducing the render target (RT) of particle effects to 1/4 resolution is an effective optimization for GPU fill-rate bottlenecks caused by transparent effects with high overdraw. However, it should not be treated as a replacement for lowering the overall scene resolution.

If GPU pressure mainly comes from VFX overdraw, enabling 1/4 RT selectively based on effect complexity or Overdraw scores is usually the better solution because it minimizes visual impact while reducing GPU workload. Lowering the camera resolution should be considered only after confirming that the GPU bottleneck extends beyond VFX and affects the entire rendering pipeline.

Why Does 1/4 RT Improve GPU Performance?

A 1/4 Render Target (RT) works by rendering visual effects at a lower resolution before compositing them back into the final frame.

This primarily reduces GPU fill-rate cost, making it particularly effective for:

Large-screen particle effects
Effects with extensive transparency
High-Overdraw combat scenes
Frequently triggered VFX during gameplay

Because fewer pixels are processed, GPU utilization decreases, which often leads to:

Lower GPU Clocks
Higher frame stability
Reduced device temperature
Lower power consumption

The benefit becomes more obvious as Overdraw increases.

Should High-Overdraw Effects Automatically Enable 1/4 RT?

In many projects, the answer is yes.

If certain effects consistently generate high Overdraw or appear frequently during combat, you can define automatic optimization rules based on metrics such as:

Overdraw score
Effect complexity
Screen coverage
GPU rendering cost

For example:

Effects below a defined threshold continue using full-resolution rendering.
Effects exceeding the threshold automatically switch to a 1/4 RT.
Effects can revert to full resolution when GPU pressure decreases.

This adaptive strategy balances visual quality and GPU efficiency without requiring manual tuning for every effect.

Image Placeholder

Insert comparison showing Full Resolution vs. 1/4 RT rendering results.

Is Lowering Camera Resolution the Same Optimization?

No.

Although both techniques reduce GPU workload, they optimize different parts of the rendering pipeline.

Optimization	Affects	Best For
1/4 RT	Individual visual effects	High Overdraw and transparent particle effects
Lower Camera Resolution	Entire rendered frame	Overall GPU bottlenecks affecting the whole scene

Lowering the camera resolution reduces rendering cost for everything, including:

Environment rendering
Characters
UI (depending on rendering setup)
Post-processing
Shadows
Visual effects

As a result, it also reduces overall image sharpness.

By contrast, 1/4 RT targets only the expensive effects while preserving most of the scene quality.

How Can You Determine Whether 1/4 RT Is Enough?

Before reducing the entire scene resolution, first identify where the GPU bottleneck actually comes from.

A GameOptim GOT Online GPU performance report can help verify this by checking several key indicators.

Monitor whether:

GPU Clocks remain consistently high, indicating sustained GPU pressure.
Overdraw increases significantly when more visual effects appear.
GPU Clocks, FPS, and device temperature improve after enabling 1/4 RT.
GPU load spikes coincide with VFX-heavy combat scenarios.

If these metrics improve noticeably after enabling 1/4 RT, then the optimization is addressing the primary bottleneck.

Image Placeholder

Insert GOT Online GPU report highlighting GPU Clocks, Overdraw, FPS, and thermal changes before and after enabling 1/4 RT.

When Should You Lower Scene Resolution?

Lowering the camera resolution should usually be considered after VFX optimization has been completed.

If GPU usage remains high even after enabling 1/4 RT, the remaining workload may come from other rendering systems such as:

Scene rendering
Post-processing
UI rendering
Lighting
Shadows
Other GPU-intensive passes

Only in these situations does reducing scene resolution become a reasonable next step.

The objective is not simply to lower GPU metrics, but to achieve a balanced trade-off between:

Stable frame rate
Visual quality
GPU utilization
Device temperature

A targeted optimization strategy generally delivers a better player experience than applying broad quality reductions too early.

Best Practices

Measure GPU bottlenecks before changing rendering settings.
Apply 1/4 RT selectively rather than globally.
Use Overdraw and effect complexity as automatic switching criteria.
Validate improvements using GPU Clocks, FPS, and thermal data.
Reduce overall scene resolution only if non-VFX rendering still dominates GPU cost.

FAQ

Does 1/4 RT always improve GPU performance?

No. It is most effective when GPU pressure is caused by transparent effects with high Overdraw. If the bottleneck lies elsewhere, the improvement may be limited.

Should every effect use 1/4 RT?

Not necessarily. Small or infrequently rendered effects often gain little benefit while potentially sacrificing image quality. Applying it selectively usually produces better results.

How do I know whether Overdraw is the real bottleneck?

Analyze GPU metrics together with Overdraw data. If GPU load rises alongside Overdraw during VFX-heavy scenes and falls after enabling 1/4 RT, Overdraw is likely a major contributor.

Should I lower camera resolution after enabling 1/4 RT?

Only if GPU utilization remains high after VFX optimization. If scene rendering, post-processing, UI, or other rendering passes still dominate GPU time, lowering the overall rendering resolution may provide additional gains.

Why Does Unity GC Run Frequently Even Without Calling GC.Collect? A Practical Debugging Guide

GameOptim — Tue, 04 Aug 2026 04:17:04 +0000

🌐 Website: www.gameoptim.com

Introduction

In Unity projects, developers sometimes encounter unexpected GC spikes: garbage collection happens frequently, causing frame drops or performance instability, even though there is no explicit GC.Collect() call and no obvious large memory allocation.

The key point is that frequent GC is usually not caused by the garbage collector itself. In most cases, it is a symptom of continuous object allocation happening somewhere in the game logic.

This article explains why Unity GC frequency increases, how to identify the root cause, and how to reduce unnecessary allocations in high-frequency code paths.

Summary

If Unity GC happens more frequently than expected, check:

Whether high-frequency logic is continuously creating temporary objects
Whether Incremental GC changes the way GC events appear
Which gameplay systems correlate with GC spikes
Where Managed memory allocations happen

The goal is not simply to reduce the number of GC events, but to eliminate unnecessary object creation that triggers garbage collection.

Why Does Unity Trigger GC Without Calling GC.Collect()?

A common misunderstanding is that GC only happens when developers manually call:

GC.Collect();

However, Unity's garbage collector can automatically run when the Managed Heap reaches certain allocation conditions.

During gameplay, many small temporary objects may be created continuously. Even if each allocation is tiny, frequent allocations can accumulate quickly and force Unity to perform garbage collection.

Common allocation sources include:

Temporary strings
Boxing operations
LINQ usage
Creating objects inside Update or Tick loops
Frequent creation of collections
Temporary arrays or lists

For example:

string info = "HP:" + hp + " MP:" + mp;

This line looks harmless, but every execution creates new string objects.

If this code runs every frame:

void Update()
{
    string info = "HP:" + hp + " MP:" + mp;
}

the game continuously generates garbage objects, increasing Managed memory pressure and eventually causing more frequent GC.

How Does Incremental GC Affect GC Frequency?

Unity's Incremental GC changes how garbage collection is executed.

Instead of performing one large GC operation that blocks the main thread, Incremental GC splits the collection process across multiple frames.

As a result, you may observe:

More frequent GC events
Lower GC time per event
Less noticeable frame spikes

Therefore, GC frequency alone does not always indicate a performance problem.

When analyzing GC behavior, always consider:

GC count
GC duration
Frame time impact
Managed memory allocation trend

A higher GC count with very low GC cost may be acceptable, while fewer but longer GC pauses can still cause visible frame drops.

How to Find the Source of Frequent GC?

A practical debugging workflow:

1. Identify When GC Happens

First, check the GC timeline and locate the periods where GC frequency increases.

For example:

During combat
When opening UI panels
During scene transitions
During character spawning
During network updates

Tools such as GameOptim GOT Online can help visualize GC trends and identify performance changes over time.

The key question is:

What gameplay logic is running when GC spikes appear?

2. Compare GC Spikes With Game Logic

Once you identify the time range, analyze what systems are active.

For example:

Scenario	Possible Allocation Source
Battle Tick	Temporary objects created in gameplay calculations
UI Refresh	String formatting and layout updates
Skill Effects	Runtime object creation
Network Update	Message parsing and temporary buffers

If GC spikes consistently happen together with a specific system, investigate the allocation behavior inside that path.

3. Find High-Frequency Allocations

The most common issue is not one large allocation, but many small allocations repeated thousands of times.

Avoid patterns like:

void Update()
{
    List<int> targets = new List<int>();
}

or:

void Tick()
{
    string text = "Damage:" + damage;
}

Better approaches:

Cache reusable objects
Avoid creating objects inside Update/Tick
Reuse collections
Cache frequently used strings
Reduce unnecessary formatting operations

Example:

Instead of creating text every frame:

damageText.text = "Damage:" + damage;

consider updating only when the value changes.

Best Practices to Reduce Unity GC Pressure

Avoid Temporary Allocations in Hot Paths

High-frequency functions such as:

Update()
FixedUpdate()
LateUpdate()
Network Tick
Combat calculations

should avoid unnecessary object creation.

Reuse Objects Whenever Possible

Instead of repeatedly creating:

new List<int>();

reuse existing collections and clear them when needed:

list.Clear();

Be Careful With String Operations

String concatenation creates new objects because strings are immutable.

Avoid frequent:

"Score:" + score

inside performance-critical loops.

Consider:

Updating UI only when values change
Using cached strings
Reducing unnecessary formatting

FAQ

Does calling GC.Collect() solve frequent GC problems?

Usually no.

Manual GC calls only force collection earlier. They do not remove the source of allocations.

The correct approach is to find and reduce unnecessary object creation.

Is a high GC count always bad?

Not necessarily.

With Incremental GC enabled, GC may happen more frequently but with lower impact.

Always evaluate GC frequency together with GC duration and frame performance.

What is the main cause of frequent Unity GC?

The most common cause is continuous allocation of temporary Managed objects in frequently executed code paths.

GC is only cleaning up the garbage created by the application.

Key Takeaways

Unity GC does not require manual GC.Collect() calls to occur.
Frequent GC usually means your code is creating temporary objects continuously.
Incremental GC can increase GC frequency while reducing frame spikes.
The best optimization strategy is finding and eliminating unnecessary allocations.
Focus on "which code creates garbage" instead of only counting GC events.

A frequent GC problem is usually not a garbage collection problem. It is an allocation problem.

How Can Shader Variant Analysis and GPU Load Thresholds Improve Mobile Game Performance?

GameOptim — Thu, 30 Jul 2026 10:59:58 +0000

🌐 Website: www.gameoptim.com

Summary

Performance optimization is one of the biggest challenges in game development. The difficulty is rarely collecting data—it is identifying which problems deserve attention first.

The latest GameOptim update introduces two practical capabilities designed to help developers analyze rendering performance more efficiently:

Shader Variant Analysis
GPU Load Threshold Alerts

These features make it easier to discover hidden rendering costs, reduce unnecessary resource consumption, and prioritize optimization work.

Why Are Shader Variants Responsible for High Memory Usage and Slow Loading?

Shader variants grow naturally as projects become more complex. Over time, projects often accumulate:

Deprecated shader keywords
Unused feature switches
Invalid keyword combinations
Redundant compiled variants

These unnecessary variants increase:

Graphics memory usage
AssetBundle size
Build complexity
Loading time
Rendering overhead

GameOptim now supports downloading complete AssetBundle shader variant data, exposing every shader keyword combination included in the package.

This allows developers to:

Find unused shader variants
Remove unnecessary keyword combinations
Reduce graphics memory consumption
Improve rendering efficiency

Instead of manually inspecting shader configurations, optimization can now be driven directly by variant data.

How Can GPU Load Thresholds Help Predict Frame Drops?

Many GPU issues become visible only after frame rates begin to decline.

GameOptim approaches GPU analysis using GPU Clocks, a hardware-level metric representing the GPU clock cycles consumed per frame.

By combining GPU Clocks with the target frame rate, developers can estimate the GPU compute power required during gameplay and compare it with the theoretical performance limit of the device.

The latest version introduces two warning thresholds:

Energy Consumption Threshold

When GPU frequency approaches 80%, the device is likely entering a high power consumption state.

Frame Rate Threshold

When GPU frequency approaches 100%, the GPU is approaching its hardware limit, increasing the likelihood of frame drops.

These indicators help teams:

Detect GPU bottlenecks earlier
Validate device classification strategies
Evaluate graphics quality settings
Reduce optimization guesswork

What Other Improvements Are Included?

In addition to these two major features, the latest GameOptim release introduces several new performance metrics and analysis dimensions to provide more comprehensive profiling data.

Whether the goal is reducing rendering cost, improving loading speed, validating device tiers, or making optimization decisions based on measurable data, the update provides developers with deeper visibility throughout the performance optimization workflow.

Key Takeaways

Excessive shader variants can significantly increase graphics memory usage and loading time.
AssetBundle Shader Variant Analysis helps identify redundant keyword combinations.
GPU Load Threshold Alerts provide early warnings before frame drops occur.
Hardware-level GPU Clocks offer a more practical way to evaluate rendering pressure.
New analysis capabilities enable faster and more data-driven performance optimization decisions.

How Can You Optimize Unity Render Textures to Reduce Memory Usage and GPU Pressure?

GameOptim — Tue, 28 Jul 2026 06:18:36 +0000

🌐 Website: www.gameoptim.com

Summary

Render Textures (RTs) are widely used in Unity projects for post-processing, camera rendering, shadows, UI effects, and other rendering workflows. However, high-resolution RTs, unnecessary anti-aliasing, excessive post-processing buffers, and unused URP intermediate textures can significantly increase GPU memory usage and rendering overhead.

To optimize Render Texture performance, developers should carefully review RT resolution, anti-aliasing settings, post-processing quality levels, and URP camera options. Reducing unnecessary RT allocations can lower memory consumption while improving GPU performance, especially on mid-to-low-end mobile devices.

What Render Texture Settings Have the Biggest Performance Impact in Unity?

When optimizing Render Textures, the most important factors to check are:

Render Texture resolution
Anti-aliasing (AA) settings
Post-processing buffer usage
URP intermediate render targets

These settings directly affect GPU bandwidth, fragment processing workload, and memory allocation.

How Does Render Texture Resolution Affect Unity Performance?

Some Render Texture resources reflect the current rendering resolution of the project.

For projects with high GPU load or rendering pressure, reducing rendering resolution on mid-to-low-end devices is an effective device-tiering strategy.

However, developers should note that:

Lowering RT resolution mainly reduces GPU fragment computation and bandwidth usage.
The impact on memory usage depends on the RT format and allocation size.
Resolution scaling is usually more effective for GPU optimization than pure memory reduction.

Besides the main rendering resolution, developers should also check other Render Textures with unusually high resolutions.

For example:

RTs larger than 2048×2048 should be reviewed carefully.
Confirm whether such high precision is actually required.
Consider using lower-resolution RTs for low-end devices.

Reducing unnecessary RT resolution can significantly reduce GPU workload without affecting visual quality in many cases.

Does Render Texture Anti-Aliasing Increase Memory Usage in Unity?

Yes. Enabling multi-sample anti-aliasing (MSAA) for Render Textures can significantly increase memory usage and GPU workload.

The RT resource list shows the AA multiplier for each Render Texture. Higher AA levels require additional samples, which increases:

Render Texture memory consumption
GPU bandwidth usage
Rendering overhead

For mobile games, especially on mid-to-low-end devices, developers should evaluate whether RT anti-aliasing is actually necessary.

Recommended optimization approaches:

Disable AA for RTs where visual improvement is minimal.
Avoid using high AA levels on devices with limited GPU resources.
Test AA settings on different hardware platforms.

For example, some Huawei devices have compatibility issues with 2× AA, where performance overhead occurs but no visible anti-aliasing improvement is achieved.

How Can Post-Processing Render Textures Be Optimized in Unity?

Many post-processing effects generate additional Render Textures.

Common effects include:

Bloom
Blur
Screen-space effects

These effects usually create RTs by downsampling from the original rendering resolution.

A common optimization strategy is:

Change the initial sampling resolution from 1/2 resolution to 1/4 resolution.
Reduce unnecessary downsampling passes.
Lower the quality level of post-processing effects on weaker devices.

These changes help reduce:

Render Texture memory usage
Post-processing rendering cost
GPU workload

For mobile games, another effective approach is to disable expensive post-processing effects entirely on mid-to-low-end device tiers.

How Do URP Render Textures Affect Memory Usage?

When using Unity Universal Render Pipeline (URP), additional Render Texture resources may be created automatically.

By default, URP creates:

_CameraColorTexture
_CameraDepthAttachment

as intermediate render targets.

If CopyDepth and CopyColor are enabled in URP Camera settings, Unity also creates:

_CameraDepthTexture
_CameraOpaqueTexture

These additional RTs consume extra memory and may increase rendering overhead.

Optimization recommendations:

Check whether CopyDepth is required.
Check whether CopyColor is required.
Disable unnecessary options in URP Camera settings.
Verify the Render Texture list after changing settings.

Avoiding unnecessary intermediate textures is especially important for mobile projects with strict memory budgets.

FAQ: Unity Render Texture Optimization

Does reducing Render Texture resolution reduce memory usage?

Reducing Render Texture resolution can reduce memory usage because smaller textures require fewer pixels to store. However, its biggest benefit is usually reducing GPU fragment workload and bandwidth consumption.

Should I always disable anti-aliasing for Render Textures?

Not always. Anti-aliasing can improve visual quality, but it increases memory usage and GPU cost. For mobile games, especially on low-end devices, developers should evaluate whether the visual improvement justifies the performance cost.

How can I find unnecessary Render Textures in Unity?

You can review the Render Texture resource list and check:

Extremely large RT resolutions
High AA multipliers
Duplicate intermediate textures
Unused post-processing buffers
URP-generated textures that are not required

Does URP always create extra Render Textures?

URP creates certain intermediate Render Textures depending on the rendering configuration. Features such as CopyDepth and CopyColor generate additional textures, so disabling unused features can reduce memory overhead.

What is the best Render Texture optimization strategy for mobile games?

A practical optimization workflow is:

Identify high-memory Render Textures.
Reduce unnecessary resolutions.
Disable unnecessary anti-aliasing.
Lower post-processing quality by device tier.
Remove unused URP intermediate textures.
Validate visual quality and performance on target devices.

By optimizing Render Texture usage, Unity developers can reduce GPU pressure, lower memory consumption, and improve stability on mobile platforms.