Photo by Florian Olivo on Unsplash. Illustrative, not a benchmark capture.
120 FPS becomes a much better performance claim when the label tells you what was counted.
For a game with frame generation, I would want three separate entries in the test record: rendered frame rate, displayed frame rate, and measured latency. They describe different parts of the experience. Treating them as interchangeable makes a useful graphics feature harder to evaluate fairly.
Start with a record, not a headline
Here is a blank test template, not a set of measured results:
game_build:
gpu_and_driver:
scene_and_capture_duration:
output_resolution_and_refresh_rate:
super_resolution_mode_and_model:
frame_generation_mode:
latency_reduction_mode:
vsync_vrr_and_frame_cap:
rendered_fps_and_measurement_tool:
displayed_fps_and_measurement_tool:
latency_ms_and_measurement_boundary:
image_quality_observations:
Leave a field unmeasured when your tool cannot expose it. In particular, do not derive latency by dividing 1,000 by an FPS counter. That calculation gives a frame interval in milliseconds, not an end-to-end input-to-display measurement.
A counter also needs a definition. Check whether it counts engine-produced frames, presentation events, or output including generated frames. A display's refresh-rate readout is not automatically any of those measurements.
Three technologies, different jobs
NVIDIA's DLSS overview describes Super Resolution as constructing higher-resolution output from lower-resolution inputs. It separately describes Multi Frame Generation as generating additional frames per rendered frame.
The Reflex developer documentation describes another job: synchronizing CPU and GPU work for just-in-time rendering and exposing latency measurements across pipeline stages.
Those are vendor descriptions of mechanisms, not an independent benchmark of your game. They are still a good reason to give each mechanism its own column.
| Question | Record | Do not substitute |
|---|---|---|
| How quickly is the game producing rendered frames? | A tool-defined rendered-frame metric | An unlabeled counter that includes generated frames |
| How smooth is the output? | Displayed-frame metric, pacing and motion observations | Average FPS alone |
| How quickly does an input appear? | Latency in milliseconds, with measurement boundary and method | The reciprocal of FPS |
| How does the picture hold together in motion? | Observations from repeatable camera movement and gameplay | A single still screenshot |
Make the comparison reproducible
Choose a short, repeatable route in a game you actually play. Include a steady camera pan, thin geometry or foliage, a visible HUD, and a section with ordinary player input. These are proposed inspection points, not a claim that every implementation has problems there.
Warm up the scene, then record the same duration for each configuration. Keep resolution, graphics settings, driver, power conditions and display configuration fixed unless they are the variable under test. Repeat captures rather than trusting one particularly good run.
First establish a configuration with frame generation off. Then enable the supported frame-generation mode while preserving the other settings where possible. If enabling it also changes a latency-reduction setting automatically, record that dependency. You are comparing two configurations, not isolating a single switch perfectly.
Record the actual mode rather than writing only “DLSS on.” Super Resolution quality mode, model selection and frame-generation mode answer different questions. Dynamic modes deserve an explicit label too; a changing multiplier is not a fixed test condition.
Keep the measurement boundary visible
A PC-latency metric and a full click-to-photon measurement are not necessarily the same thing. Peripherals and display behavior can sit outside a software metric's boundary. Use the tool's documented definition, and compare like with like.
If you cannot measure latency, say so. You can still describe how aiming or camera movement felt, but label that observation subjective rather than assigning it an invented millisecond value.
Likewise, smooth output does not prove every game simulation or input sample ran at the displayed frame rate. Conversely, generated frames can provide genuine visual value even though they are not a separate full simulation step. A useful review can hold both ideas at once.
The goal is not to crown one universal setting. It is to find the combination of smoothness, image quality and responsiveness that suits a particular game and player. Better labels help people reproduce that choice instead of chasing a number with an unclear meaning.
Which missing field most often makes a gaming benchmark difficult for you to compare?
Full KRI ZEK hardware overview.
Download Altered Brilliance: https://play.google.com/store/apps/details?id=tech.krizek.alteredbrilliance
Global website: https://global.krizek.tech
Pre-register for Arzenal Human Health: https://play.google.com/store/apps/details?id=tech.krizek.arzenal
Join The Power Of Gaming: https://discord.gg/sbYSPcCqJn
Top comments (0)