GPU x Monitor Checker

Methodology

This page explains exactly how a verdict is produced, so you can judge how much to trust it. Nothing here is marketing - if a number can't be sourced, the tool says so.

What we check

What we do NOT check

Why we don't calculate FPS

Rendered frame rate depends on the game, the settings, the CPU, the driver and the scene. It changes second to second. Signal compatibility is a fixed property of the hardware and the mode. Mixing them would make both answers less trustworthy.

What "Target Mode" means

A Target Mode is the exact combination you want: for example3840x2160, 144Hz, 10-bit, HDR on, VRR on. Every verdict applies to one Target Mode on one connector - never to the GPU-monitor pair as a whole. The same pair can be SUPPORTED at 4K 60Hz and NOT SUPPORTED at 4K 240Hz 10-bit.

Evidence priority

Bandwidth requirements are established from the best available evidence, in this order:

  1. Manufacturer PC Factory Support Mode / timing table - an explicit row for the exact mode.
  2. EDID detailed timing descriptor.
  3. Official pixel clock, reverse-computed into a bandwidth figure.
  4. VESA / CTA standard timing (CVT-RB2). Reserved - not yet implemented as a live calculation.
  5. Active-pixel estimate - active pixels x an approximate blanking overhead. Last resort, always labelled.

A result that rests only on step 5 is never shown as a bare "SUPPORTED". It caps at "SUPPORTED WITH CONDITIONS" or "UNKNOWN".

Evidence levels shown on results

Verified from manufacturer timing dataAn official table lists this exact mode.
Verified from official pixel clock dataThe manufacturer publishes a pixel clock; the requirement is computed from it.
Based on verified display timing standardsA real VESA/CTA standard timing row.
Estimated - exact manufacturer timing unavailableActive-pixel approximation; blanking is not exact.
DSC capability is estimated, not confirmedThe fit depends on an assumed DSC compression ratio, with no official DSC timing row.
Insufficient verified dataCan't be established from anything we trust. Result is UNKNOWN.

Source trust grades (A-F)

AManufacturer's own product page, manual, or spec sheet.
BManufacturer platform documentation or user guide (less specific).
CReputable independent measurement (e.g. a professional review lab).
DMirrored or third-party manual, retailer spec listing.
EAggregator / wiki.
FForum or community report.

Retailer listings and unofficial manual mirrors are never relabelled as official. Where sources disagree, we show the conflict instead of picking one.

HDMI version is not bandwidth. DisplayPort version is not link rate.

"HDMI 2.1" covers FRL grades from 24 to 48 Gbps. "DisplayPort 2.1" does not imply UHBR20. The link's gross rate and its effective payload(after transport encoding overhead) are stored as separate numbers, and only the effective payload is compared against a mode's requirement. Where a device's real FRL / UHBR grade isn't documented, we use a conservative floor and label the result as resting on a presumed rate.

DSC needs both ends

Display Stream Compression only helps if the GPU can encode it andthe monitor can decode it. If either side is unverified on a mode that needs DSC, the verdict is UNKNOWN, not SUPPORTED. A 3:1 compression assumption on its own is never enough to produce SUPPORTED or SUPPORTED WITH CONDITIONS - there must be an official DSC timing row.

What UNKNOWN means

UNKNOWN means we could not verify a capability the mode depends on - most often a GPU link rate or DSC support that the manufacturer never published. It does not mean the mode fails. Every UNKNOWN result still shows what is confirmed for the pair and the nearest mode you can rely on. We would rather return the honest UNKNOWN than guess a spec to make the answer look cleaner.

Known exceptions and their limits

Reported real-world quirks - driver regressions, firmware bugs, a specific port on a specific panel - are shown as context on results. Coverage is sparse and skewed toward widely reported cases. The absence of a known issue is not a guarantee that none exists.

Last verified & corrections

Each result shows a "last verified" date for its data. Specs and documentation change, and our early data has been corrected before when a better source turned up (an HDMI timing table was initially read from the wrong table type). Our policy is simple:we correct data when better evidence becomes available, and we don't quietly make the engine more optimistic to reduce UNKNOWNs.