Cycles/Pixel, GPU bandwidth, and a thread timeline read the same frame drop from three angles — so you optimize the right subsystem instead of guessing.
A dropped frame in a modern Unity game rarely has a single cause. Higher-fidelity art pushes Shader cost up, more textures increase GPU memory bandwidth, and heavier logic spreads work across threads. A stutter can come from any of these, and optimizing the wrong one yields no frame-time improvement at all.
GameOptim GOT Online's Overview mode adds two diagnostics that read the same frame from different angles: GPU Counter for shader cost and memory bandwidth, and Timeline for thread-level activity during a stutter. This article explains what each measures, how to read them, and how to decide which one your stutter belongs to.
Summary
- A frame drop can come from GPU shader cost, GPU memory bandwidth, or thread blocking — each needs a different fix.
- Cycles/Pixel measures the average GPU clock cycles spent per pixel. High values usually mean the Shader is too complex; low values with a stutter point elsewhere.
- GPU bandwidth measures per-frame read/write volume. Sustained high external read/write causes fast battery drain and is independent of shader complexity.
- Timeline visualizes up to 5 threads with parent and child function durations, so you can see thread count, queueing, idle states, and inter-thread waits during the exact stutter frame.
- GPU Counter data is currently available on devices with supported Mali chips; check device compatibility before reading absence as a finding.
What Does "GPU Is Slow" Actually Mean?
"GPU pressure" is three separate things bundled into one complaint. Each has a different symptom and a different fix.
| Subsystem | What it measures | Symptom when overloaded |
|---|---|---|
| Cycles/Pixel | Average GPU clock cycles per pixel | Shader complexity exceeds per-pixel budget; frame time grows with screen complexity |
| GPU bandwidth | Per-frame total read/write volume | Sustained high load → fast battery drain, thermal throttling, eventual stutter |
| Thread timeline | Activity across CPU threads during a frame | Threads idle, queued, or waiting on each other; stutter caused by blocking, not raw compute |
These are independent. A game can have low Cycles/Pixel and still drop frames because threads are blocking. A game can have expensive shaders and a clean timeline. The new GOT Online features let you read each separately so you do not optimize one to fix the other.
Cycles/Pixel: Reading Shader Complexity
Cycles/Pixel is the average number of GPU clock cycles consumed per rendered pixel. Shader complexity is the dominant factor: when a scene's shaders are complex, the GPU spends many cycles per pixel evaluating them, GPU time rises, and the frame stutters.
How to read it: Use Cycles/Pixel under GPU shading to identify scenes with high cycle counts, then judge whether the scene's GPU pressure is caused by shader complexity. If the cycles value is high and tracks with shader-heavy scenes, shader simplification is the right lever. If the cycles value is low but the frame still stutters, shader cost is not the cause — look at bandwidth or the thread timeline instead.
What Cycles/Pixel does not tell you: It cannot distinguish between a few very expensive pixels and many moderately expensive ones, and it says nothing about memory traffic. Pair it with bandwidth data before deciding.
GPU Bandwidth: Reading Memory Traffic
GPU bandwidth, like CPU bandwidth, is a major contributor to chip power consumption. When the GPU performs sustained high-load external read/write operations, power draw rises sharply.
The GPU bandwidth module in GOT Online reports the total per-frame read/write bandwidth across the test. Use it to locate scenes where bandwidth is high, identify what is driving the traffic, and run a follow-up test after any changes.
How to read it:
- A scene with high bandwidth but normal Cycles/Pixel points at memory traffic — texture streaming, render-target copies, or excessive buffer uploads — rather than shader compute.
- A scene with both high bandwidth and high cycles confirms a GPU-heavy scene that needs work on both fronts.
- Bandwidth is also a thermal signal: sustained high values lead to throttling and stutter even when raw frame time looks acceptable.
Timeline: Reading Thread Activity During a Stutter
Overview mode already supported stutter analysis through call-stacks. The new Timeline module adds a time-ordered view so the sequence of events is visible at a glance.
Timeline shows the main thread and up to 4 sub-threads (5 total). Under each thread, both parent and child functions are visible, and the length of each function's time bar represents its duration — the longer the bar, the more time that function consumed near that frame.
What the Timeline answers:
- How many threads were active during the stutter frame.
- What each thread was executing and for how long.
- Whether threads were queued behind one another.
- Whether any thread was idle or waiting on another thread to finish.
This makes thread-level bottlenecks visible in a way a call-stack cannot. A call-stack tells you what one function did; a Timeline tells you whether another thread was the actual reason the frame did not complete on time.
How Can You Tell Which Subsystem Is Causing the Stutter?
Work through the three signals in this order:
| If you see | The cause is likely | What to optimize |
|---|---|---|
| Cycles/Pixel high, bandwidth low, timeline clean | Shader complexity | Reduce shader cost, simplify passes, optimize per-pixel work |
| Bandwidth high, cycles normal, timeline clean | Memory traffic | Reduce texture streaming, render-target copies, buffer uploads |
| Cycles and bandwidth normal, timeline shows idle/waiting threads | Thread blocking | Re-order work, remove unnecessary waits, balance load across threads |
| Cycles high and bandwidth high | Combined GPU load | Address both, starting with whichever has the larger headroom gap |
A stutter that matches none of these rows may be CPU-side logic or input handling — the new modules do not cover that, and you should check the existing stutter call-stacks instead.
What Should You Check First?
- Confirm device compatibility. GPU Counter data requires a supported Mali chip. If Cycles/Pixel and bandwidth are absent, it is a device limitation, not a zero reading.
- Start with the stutter frame. Open Timeline and look at the exact frame that dropped. Thread activity at that moment tells you whether the problem is compute, memory, or blocking.
- Read Cycles/Pixel next. If the dropped frame also has high cycles, shader cost is involved.
- Read bandwidth for the same frame. If bandwidth spiked too, memory traffic is part of the cause.
- Correlate across the test. A one-frame spike is different from a scene-wide trend. Check whether the high values persist through the scene or appear only in one frame.
What Should You Avoid?
- Do not treat a missing GPU Counter reading as zero. On unsupported devices the data is simply unavailable. Verify chip support first.
- Do not optimize shaders when the timeline shows thread waiting. Shader work has no effect on a CPU-side thread-blocking stutter.
- Do not reduce bandwidth if the cycles value is the real driver. Cutting texture resolution will not lower Cycles/Pixel if the shader itself is the cost.
- Do not read a single frame in isolation. Confirm the signal holds across the scene before making changes.
Key Takeaways
- GPU pressure splits into Cycles/Pixel (shader cost), bandwidth (memory traffic), and thread blocking (timeline) — independent signals requiring different fixes.
- High Cycles/Pixel means shaders are doing too much per pixel. Low cycles with a stutter means the cause is elsewhere.
- High bandwidth drives power draw and thermal throttling, even when frame time looks fine.
- Timeline reveals thread count, queueing, idle states, and inter-thread waits — the only way to see a blocking bottleneck.
- GPU Counter is available on supported Mali devices; absence is a compatibility note, not a zero.
FAQ
Why is my Cycles/Pixel high but my game looks fine?
Cycles/Pixel measures shader cost per pixel, not visual quality. High values mean the GPU spends many cycles evaluating shaders, which can cause stutter even if the output looks correct. Simplify shaders or reduce overdraw to bring it down.
Does high GPU bandwidth cause stuttering directly?
Not always immediately. Sustained high bandwidth raises power draw and temperature, which leads to thermal throttling and eventual stutter. It also competes with other memory traffic, so spikes can coincide with frame drops.
How many threads does the Timeline show?
Up to 5 — the main thread plus 4 sub-threads. Within each thread, both parent and child functions are shown with duration bars.
What does an idle thread in the Timeline mean?
A thread that is idle or waiting for another thread to finish means the stutter is likely a blocking issue, not a compute shortage. Re-ordering work or removing the wait is more effective than adding more CPU tasks.
My device does not show GPU Counter data. Is that a bug?
GPU Counter currently supports devices with certain Mali chips. If the data is absent, verify that your device uses a supported chip; otherwise the reading is simply unavailable, not zero.
Top comments (0)