CS3 question 10 gave you a frame made of 2 ms serial plus 14 ms parallel, and you worked out 250 fps with one fraction. That was professional frame-budget engineering. This page turns that one question into an instrument — and then points it at your machine and your game.
A game does not "run at 120 fps". It has 8.33 milliseconds to finish everything and put a picture on screen, and then it has to do it again. Frames per second is the scoreboard. Milliseconds per frame is the budget. Engineers think in the budget, because that is the thing you can actually spend.
| Target | Budget per frame | What that is |
|---|---|---|
| 30 fps | 33.33 ms | console cinematic; input feels heavy |
| 60 fps | 16.67 ms | the classic target — still most games' design point |
| 120 fps | 8.33 ms | half the budget of 60. Not "a bit more work" — half. |
| 144 fps | 6.94 ms | a common monitor refresh |
| 240 fps | 4.17 ms | competitive; almost everything must be cut |
Notice the shape. Going 30 → 60 costs you 16.67 ms. Going 120 → 240 costs you 4.17 ms. The budget is 1000/fps — a hyperbola, not a line. Every doubling of frame rate is twice as expensive as the last one, which is why the last few frames per second cost the most.
Your question said: 2 ms of serial simulation, 14 ms of perfectly parallel shading, 7 cores. You got 4 ms. Here is that same model, live — and the thing worth staring at is the ceiling.
Push the core slider to the end and watch the curve flatten. The frame never gets below the serial part — 2 ms means 500 fps, for ever, no matter what card you buy. Your 5090 has 21,760 cores; the ceiling does not care, and that is the same sentence you answered out loud on Amdahl.
Which is why the "Halve the serial part" button moves the ceiling and the core slider never does. Optimisation is finding S, not buying N.
A real frame is not two numbers. Set a target, then try to fit the work inside it.
CPU work GPU work headroom over budget
The trap this model hides on purpose: it adds CPU and GPU time together, as if they took turns. Modern engines pipeline them — the CPU prepares frame N+1 while the GPU draws frame N. So the real frame time is closer to max(CPU, GPU) than to their sum, and whichever is larger is what people call being "CPU-bound" or "GPU-bound".
Press the button and watch the verdict change. Knowing which of the two numbers you are fighting is the whole first move of optimisation — and it is why "get a better GPU" sometimes changes nothing at all.
Average frame rate is an average, and averages hide exactly the thing you feel. One long frame is a visible hitch; a hundred short ones do not make up for it.
This is why reviewers stopped quoting average fps and started quoting 1% low — the frame time you are at or below 99% of the time. A game averaging 120 fps with a 1% low of 22 fps feels worse than a locked 60. The average went up; the experience went down. That gap is the whole reason frame-time graphs exist.
the chart unlocks when you have written a prediction. That is not a bug — it is the experiment.
| Setting changed | Avg fps | 1% low fps | GPU % | CPU % |
|---|---|---|---|---|
| baseline — your normal settings | ||||
| resolution down one step | ||||
| shadows / effects down one step | ||||
| view distance / crowd density down |
avg fps 1% low fps — same unit, so one axis, and you may compare the bars directly.
write a prediction, then type your numbers
Three sentences: (1) which knob moved the frame time most, (2) what that tells you about which side you are bound on, (3) what this cannot tell you.
Reading the result: resolution mostly costs GPU (more pixels to shade). View distance and crowd density mostly cost CPU (more objects to decide about and submit). If dropping resolution barely moves your fps, you are CPU-bound — and a better graphics card would have bought you nothing. That is a real finding, and a slightly annoying one.
The budget is not all yours. The operating system, the driver, and the compositor all take a slice. The card also has to present the finished image, and if you are using v-sync it then waits for the monitor. Miss the deadline by one microsecond and, with v-sync on, you do not show a slightly late frame — you show the previous frame again and your effective rate halves. 121 fps of work on a 120 Hz screen can display as 60.
And the memory wall shows up here too. CS3 Q4: a job doing one operation per twelve bytes moved is limited by bandwidth, not arithmetic. Post-processing passes read and write the whole screen buffer repeatedly — at 4K that is tens of megabytes per pass, several passes per frame. Those passes are almost pure memory traffic, which is why they cost far more than their arithmetic suggests, and why "turn off motion blur" is such a reliable win.
So the honest version of your ceiling is not 1000/serial. It is 1000/serial minus whatever the OS, driver and present path take — and that overhead is the part no slider on this page models.
Every slider here drives a model, and the model is deliberately simple: fixed costs, no pipelining unless you switch it on, no driver overhead, no v-sync, no thermal throttling. It is good enough to reason with and not good enough to predict your game. The only real numbers on this page are the ones you type into section 5 — and even those are one scene, one machine, one evening. That is a measurement, not a benchmark, and saying which one you have is the difference between an engineer and a forum post.