Methodology

Every SpecsTool tool comes from the same model. This page explains how it is built, where the data comes from and — above all — what it cannot do. If you are about to make a purchase decision using our numbers, this is what you should know first.

Hardware scores

Every processor and graphics card in the database has an in-game performance score. It is not a synthetic benchmark figure: it is built from published frame rate averages in independent reviews, at 1080p, 1440p and 4K, normalised onto a common scale so parts from different generations can be compared.

Alongside that score we store the data that changes behaviour even when raw speed does not: VRAM capacity, core and thread count, typical power draw under load and architecture generation. Those are what let us warn you that a card will run out of memory at 4K even though its score is high.

Per-game performance profile

Each game in the catalogue has two values: how much GPU it demands and how much CPU it demands, both relative to a reference configuration (RTX 3060 + Core i5-12400F at 1080p, high settings). A game rated 1.0 on graphics runs at that reference frame rate; one rated 2.0 needs twice the graphics power for the same result. When the engine caps frame rate, we store that ceiling too.

We should be honest about provenance: the most popular titles are hand-calibrated against published benchmark results, while the rest of the catalogue is estimated from release year, genre and the platforms it shipped on. Genre-based estimation works reasonably well — recent open worlds demand far more than a ten-year-old strategy game — but it is not the same as having measured that specific title.

How a result is calculated

With those ingredients, an estimate always follows the same steps: work out how many frames the CPU can prepare given the game's processor demand; work out how many the GPU can draw given its graphics demand, corrected for the cost of the chosen resolution; apply the upscaling saving if you enabled it, which only affects the graphics side; take the lower of the two, because the slower one rules; and finally apply the engine cap and check RAM and VRAM to flag memory bottlenecks.

The bottleneck percentage is the distance between those two figures relative to the larger one. Below 10-15% we consider the machine balanced: that difference sits inside the model's own margin of error.

Margin of error

Typical error against a real measurement is ±10-15% on common configurations, and can be larger in three specific cases: laptops, because the same chip performs very differently depending on the vendor's power limit; heavily unbalanced builds, where real behaviour depends on the engine; and games whose profile is estimated rather than calibrated.

The model also does not try to predict 1% low frame rates, which is what decides whether a game feels smooth. There is no shortcut for that: you have to capture frame times on your own machine.

What the model cannot know

It does not know your machine's temperatures or whether your processor throttles under heat. It does not know whether your RAM runs in dual channel or whether your card sits in a bandwidth-limited PCIe slot. It does not account for driver state, a specific patch's optimisations, ray tracing, frame generation, or whatever you have running in the background. All of those can move the real result several percentage points either way.

Updates and corrections

The database is reviewed with each new generation of processors and graphics cards, and game profiles are adjusted when better data appears. If you see a figure that does not match your experience or a review you trust, write to us: specific corrections with a source attached are the fastest way to improve the model.