What FrameSight does, how to give it a frame to analyse, and how to read the report. Written for 3D leads and producers, no GPU-profiling background needed.
FrameSight takes one recorded frame of your game, replays it on real GPUs, and turns it into a plain-language report: how fast the frame is, what is slowing it down, and what your team should fix first. There are two things to know: how to get a report, and how to read it. Both are below.
Getting started
FrameSight analyses a single frame of your game. You give it a capture, a recording of exactly what the GPU did to draw one frame. FrameSight replays that frame on one of our GPUs to measure where the time and memory go.
Not a RenderDoc user? The recording step is a two-minute job for anyone on the team who can launch the game from the editor or a build. A producer can hand it off and still drive everything else (uploading, comparing builds, reading reports).
A capture is a .rdc file made with RenderDoc, the free, industry-standard tool for recording a single frame of GPU work. You only need it for this one step.
.exe, fill in the working directory and any launch arguments as usual, then click Launch. Your game opens with a small overlay in the corner..rdc file (usually 50 MB to 2 GB). Drag it into a FrameSight scene.Capture the heaviest frame. Pick the moment your game works hardest. A capture of a menu or loading screen produces a report, but the numbers will not reflect your real ceiling.
Capture at the resolution you ship. Pixel work grows fast with resolution, so a 1080p capture of a 4K game badly under-counts the pixel cost.
Hide debug overlays first. On-screen debug menus and ImGui panels add extra draws that can mask the real bottleneck. Turn them off before pressing F12.
One frame is enough. A single representative frame holds everything the analysis needs. There is no need to record a sequence.
A scene is one moment in your game that you want to track: a boss fight, the hub, a cutscene. Group captures of the same moment under one scene.
Why it matters: the matrix view lines up captures of that scene across different GPUs and across game builds, so a performance regression between two builds is one glance away.
Tip: upload a new capture into an existing scene and the old one is kept as a previous version. The letter on each cell (A, B, C, …) follows the upload order, which is handy for tracking how a scene's cost moves build over build.
A runner is a GPU machine that Exploding Frame runs for you. You never install or manage anything. You choose which GPU(s) to test on when you create a benchmark, and we replay your capture on them.
Each GPU you pick becomes one column in the benchmark matrix, so you can compare the same frame across hardware side by side (for example: does this scene hold 60 fps on a mid-range card?).
The public fleet page lists every GPU with its status (online, offline, or in maintenance) and specs (model, VRAM, driver). If one of your jobs is stuck on queued, the GPU you picked is probably offline or in maintenance. Check that page.
Need a specific GPU that is not in the fleet? Contact us and we will look into adding it.
Reading your report
The grade at the top of the report is a quick read on how clean the frame is: A means nothing looks alarming, F means several serious issues. A 0-to-100 score backs it up for the curious (in the grade card's tooltip and at the bottom of the report).
It is built from the report's list of warnings. Each warning has a severity (info / medium / high / critical), and the grade follows the worst ones present. No warnings → A. A few criticals → F.
A good grade does not mean “fast”. It means “nothing looks alarming”, not “this hits 60 fps”. Always read it next to the frame time and the bottleneck before drawing conclusions.
A frame has a time budget set by your target frame rate. FrameSight measures you against a 30 fps budget (33.3 ms per frame). The donut shows how much of that budget your frame uses, with markers for 60 fps (half the budget) and 120 fps (a quarter).
Headroom (below the donut) is how much slack you have left before dropping under 30 fps on that GPU. Negative headroom = you are already over budget on this card. A small positive number = fragile: a slightly heavier moment (more particles, foliage, weather) will push you over.
The number used here is the corrected GPU time: your raw replay time minus the extra cost that only exists during RenderDoc replay (see Total GPU time for why replay runs slower than your real game).
The top-line counts for the captured frame.
This section names the one part of the GPU that is the limiting factor for this frame, the thing worth fixing first. FrameSight scores how hard each part of the pipeline is working and reports the busiest one as the bottleneck.
A balanced frame shows similar scores everywhere, with no single culprit. One part standing far above the rest is your optimisation target.
A map of GPU time by render pass (shadows, lighting, post-processing, UI, …). Each block is one pass; its size is the share of frame time that pass took. The biggest blocks are where your time actually goes.
Click a block to open it and see its individual draw calls, shaders, and resources.
Blocks are coloured by the kind of call (regular / instanced / GPU-driven / compute), so the overall mix reads at a glance.
The Colour by toggle above the treemap switches to Density, which recolours each block by how many draw calls it packs per millisecond. A big pale block is time-heavy but efficient; a small dark block crams many calls into little time and usually means CPU-side overhead from submitting all those calls. Flip back to Kind for the default view.
The most expensive individual draws, ranked by GPU time. For each one:
GPU-driven draws (shown as Execute events) have their parameters decided on the GPU rather than by your code. FrameSight reads those parameters back so the counts shown are the real ones.
How your GPU memory (VRAM) is split across resource types. The pie at the top gives the shape; the treemap below lets you drill into individual allocations, sized by megabyte.
Per-texture detail for every texture used in the frame, plus recommendations.
R8G8B8A8. They cut memory bandwidth dramatically for a small quality cost.When the GPU reads data, the closer it lives the faster it is. This card shows where the frame's reads were served from: fast on-chip caches, or slow trips out to VRAM.
Rule of thumb: a green-heavy pie with low VRAM traffic means your data fits in cache and is well laid out. A peach-heavy pie with high traffic points at oversized textures, missing mips, or scattered memory access. Fix those before touching shaders.
How much pixel work the frame does, and how much of it is wasted.
Advanced (for engineers digging deeper)
Low-level hardware numbers read straight from the GPU. A producer can skip this section. It is here for engineers who want to confirm why a stage is the bottleneck. Which counters are available depends on the GPU vendor and driver.