El peor tipo de incidente de rendimiento es el que no puedes capturar con una captura de pantalla. Un juego se siente “raro”. Tu puntería con el ratón se vuelve blanda. La cámara se desplaza y ves el micro-tartamudeo
que tu amigo jura que no existe. Reinicias, cambias cables, culpas al controlador de la GPU, culpas al juego, culpas a tu escritorio. Entonces—tres ajustes después—se arregla mágicamente.
Ese caos es la realidad vivida de la frecuencia de actualización variable (VRR): la familia G-Sync de NVIDIA y la familia FreeSync de AMD. Se comercializaron como un duelo limpio.
En producción, se comportan como un ecosistema con bordes indefinidos. Si compras monitores, despliegas flotas de equipos de escritorio o solo quieres que tu equipo deje de hacer que dudas de ti mismo,
esta es la guía de campo.
Qué problema resolvió realmente VRR (y qué no)
La sincronización clásica de pantallas es una dictadura: tu monitor actualiza a una cadencia fija (60/120/144/240 Hz), y tu GPU renderiza frames cuando puede.
Cuando esos dos relojes se desincronizan, obtienes o bien:
- Desgarro (tearing): la pantalla muestra partes de dos frames a la vez porque la GPU actualiza el búfer a mitad del refresco.
- Tartamudeo (stutter): con V-Sync tradicional, la GPU espera la siguiente ventana de refresco; si la pierde, puede esperar un ciclo completo, produciendo un pacing desigual.
VRR hace que el reloj de refresco del monitor siga la entrega de frames de la GPU—dentro de un rango soportado. En lugar de “refrescar cada 6.94 ms porque es 144 Hz”,
se convierte en “refrescar cuando llega el siguiente frame completo, pero no más rápido que X Hz ni más lento que Y Hz.”
VRR no lo arregla todo. Si tus tiempos de frame son caóticos (picos por compilación de shaders, tareas en segundo plano, throttling térmico), VRR puede ocultar el tearing pero no puede
crear un pacing consistente. VRR tampoco puede arreglar overscan, escalado malo, respuesta de pixel deficiente o un panel que difumina transiciones oscuras como si limpiara una escena del crimen.
En términos de SRE: VRR no es capacidad. Es un mejor balanceador de carga entre productor (GPU) y consumidor (panel), con SLAs estrictos (límites de rango) y
casos límite específicos del proveedor.
Cómo funciona VRR: la mecánica poco glamorosa
En la capa eléctrica/protocolo, VRR trata de alargar el intervalo de blanking vertical (VBI): el tiempo entre refrescos.
El monitor recibe una señal que dice, efectivamente: “espera un poco más antes del siguiente scanout”, por lo que la pantalla espera al siguiente frame.
Tres detalles importan en la práctica:
1) El rango VRR es un límite rígido
Un monitor puede soportar VRR de 48–144 Hz. Si tu juego corre a 46 fps, el monitor no puede refrescar a 46 Hz (en ese ejemplo). Algo tiene que ceder:
o bien cae a un modo fijo, o bien usa un truco llamado LFC.
2) LFC es la cinta adhesiva que generalmente funciona
Low Framerate Compensation (LFC) repite frames para que el refresco se mantenga dentro del rango VRR. Si la GPU rinde 40 fps y el mínimo es 48 Hz,
el sistema podría mostrar cada frame dos veces para funcionar a 80 Hz. Obtienes menos tartamudeo que con un refresco fijo, pero sigues a 40 fps. La física sigue invicta.
3) El ajuste de overdrive no es opcional
La respuesta del pixel depende de la cadencia de refresco. Cuando el refresco varía, el overdrive del monitor (empuje de voltaje para mover los píxeles más rápido) puede quedar desajustado,
creando ghosting o inverse ghosting en ciertas bandas de fps. Algunas “certificaciones” son básicamente la promesa de que las tablas de overdrive no son terribles.
Broma #1: VRR es como una reunión que empieza exactamente cuando todos llegan. Buena idea—hasta que la persona que siempre llega tarde es tu GPU.
G-Sync, G-Sync Compatible y el módulo por el que pagaste
“G-Sync” ya no es una sola cosa. NVIDIA solía referirse a un módulo hardware dedicado en el monitor—caro, pero predecible.
Luego llegó “G-Sync Compatible”, que es VRR sobre estándares de la industria (usualmente VESA Adaptive-Sync por DisplayPort, o HDMI VRR),
probado por NVIDIA para cumplir ciertos criterios (sin parpadeos extremos, comportamiento aceptable).
G-Sync (módulo)
El trato original: el módulo de NVIDIA controla el timing del panel de forma estricta. Los beneficios típicos incluyen rango VRR amplio, overdrive variable robusto y menos casos límite raros.
Inconvenientes: coste, a veces ventiladores ruidosos en unidades tempranas, e históricamente opciones de entrada más limitadas.
G-Sync Ultimate
“Ultimate” es un paquete de marketing: históricamente ligado a expectativas HDR (brillo, local dimming, latencia). En la práctica, juzga el panel real:
HDR en papel no significa HDR que quieras mirar más de cinco minutos.
G-Sync Compatible
Esta es la realidad de mercado masivo: VRR estándar con validación de NVIDIA. Muchos monitores FreeSync no validados aún funcionan bien en GPUs NVIDIA,
pero estás en territorio de “no soportado pero probablemente OK”, y los modos de fallo se vuelven picantes: parpadeos a bajos fps, pantallas negras aleatorias,
VRR que se desactiva tras suspensión, o VRR que solo funciona en pantalla completa exclusiva (dependiendo del SO y el controlador).
Recomendación con opinión: si quieres el mínimo drama y puedes pagarlo, un monitor con módulo G-Sync ha sido históricamente la opción “aburrida y que funciona”.
Si tienes presupuesto ajustado o cambias de GPU, G-Sync Compatible es el término medio práctico—solo compra de una línea de modelos con historial comprobado.
Niveles de FreeSync, LFC y el impuesto del “depende”
AMD FreeSync se basa en estándares relativamente abiertos (VESA Adaptive-Sync y luego HDMI VRR), con branding y capas de certificación de AMD.
Esa apertura es por qué FreeSync inundó el mercado. También explica por qué la calidad varía enormemente.
FreeSync (básico)
FreeSync básico significa que el monitor soporta VRR, pero el rango puede ser estrecho y LFC puede no estar presente. Una trampa común: una pantalla 48–75 Hz.
“Soporta FreeSync”, sí, pero es básicamente un apretón de manos cortés, no un matrimonio.
FreeSync Premium
Premium generalmente implica LFC y una expectativa de refresco mínimo más alta. Eso importa porque LFC es lo que mantiene útil al VRR cuando los frames bajan.
FreeSync Premium Pro
Pro añade expectativas sobre manejo de HDR y latencia. Trátalo como “menos probable que sea un desastre”, no como una garantía de HDR cinematográfico.
Aquí está la parte que los compradores pasan por alto: FreeSync es una etiqueta de ecosistema, no una promesa directa de que tu GPU, controlador, cable, puerto, compositor del SO y motor de juego
se comportarán. Está más cerca de “soporta TCP” que de “tu aplicación web nunca hará 500”.
DisplayPort vs HDMI VRR: el cable es parte del protocolo
Si quieres VRR con menos sorpresas, DisplayPort sigue siendo la elección aburrida. DisplayPort Adaptive-Sync lleva más tiempo en el mundo PC,
y el firmware de los monitores tiende a estar más maduro allí.
HDMI VRR existe y puede ser excelente, especialmente en televisores y consolas. Pero HDMI añade más variabilidad:
versiones, comportamiento de link training, calidad del cable, receptores AV, barras de sonido y funciones “útiles” como HDMI-CEC que a veces se sienten como una broma.
Regla práctica de compra
- Si es un monitor de escritorio para PC: prefiere DisplayPort para VRR.
- Si es un televisor o necesitas funciones HDMI 2.1 (4K120, consola): usa HDMI VRR, pero espera validar toda la cadena de extremo a extremo.
Retardo de entrada, pacing de frames y por qué “FPS sin límite” no es una estrategia
VRR reduce el tearing sin la penalización clásica de V-Sync, pero “VRR activado” no significa automáticamente “mínima latencia”. Tu verdadero enemigo es el encolamiento:
frames acumulándose en la cola de render, en la cola del controlador o dentro del motor del juego.
El patrón estable para juego VRR de baja latencia es:
- Activa VRR (G-Sync/FreeSync).
- Activa V-Sync en el panel de control/controlador (contraintuitivo, pero evita el tearing por encima del techo VRR).
- Limita FPS ligeramente por debajo del refresco máximo (p. ej., 141 para 144 Hz, 237 para 240 Hz) usando el limitador interno del juego o un limitador externo fiable.
Esto te mantiene dentro de la ventana VRR para que el sistema rara vez alcance el “tope” donde V-Sync de otra forma bloquearía de forma abrupta.
No es religión; es evitar que el sistema rebote entre regímenes de temporización.
Una cita, porque aplica: la idea de Werner Vogels “Todo falla, todo el tiempo” (parafraseada). Las pantallas no están exentas; solo fallan más silenciosamente.
Multi-monitor y estaciones de acoplamiento: donde VRR va a morir
VRR es más simple en un mundo de un solo monitor y conexión directa. La realidad corporativa es multi-monitor, tasas de refresco mezcladas, docks, KVMs, dispositivos de captura
y “este cable USB-C vino gratis con una licuadora”.
Modos de fallo que verás:
- VRR funciona solo en un monitor; activarlo en ambos causa parpadeo o se desactiva en el primario.
- VRR funciona hasta la suspensión; al volver está en modo fijo 60 Hz.
- Las estaciones de acoplamiento exponen DisplayPort MST; el soporte VRR a través de MST es inconsistente y a menudo efectivamente no soportado.
- Mezclar refrescos (secundario 60 Hz, primario 144 Hz) puede disparar comportamiento de compositor que perjudica el pacing de frames.
Mi consejo si compras para una flota: no conviertas VRR en un requisito salvo que controles toda la cadena. Para un puesto de trabajo entusiasta individual,
mantén tu pantalla VRR en una salida GPU dedicada, sin docks, sin MST, sin adaptadores a menos que disfrutes depurar a la 1 a.m.
Datos interesantes y contexto histórico (corto y concreto)
- Dato 1: NVIDIA introdujo los primeros monitores G-Sync con un módulo dedicado en torno a 2013–2014, años antes de que el VRR fuera común.
- Dato 2: FreeSync de AMD se lanzó en 2015 aprovechando VESA Adaptive-Sync, lo que ayudó a impulsar la adopción masiva mediante diseños de monitor más baratos.
- Dato 3: VESA Adaptive-Sync es parte del estándar DisplayPort; los fabricantes podían implementarlo sin pagar por un módulo propietario.
- Dato 4: “G-Sync Compatible” llegó más tarde, cuando NVIDIA comenzó a habilitar VRR sobre Adaptive-Sync y validar modelos específicos por comportamiento aceptable.
- Dato 5: Low Framerate Compensation (LFC) se convirtió en un diferenciador clave porque muchos monitores VRR tempranos tenían límites mínimos de refresco altos.
- Dato 6: HDMI VRR se volvió mainstream con la era HDMI 2.1, alineando el comportamiento VRR con entornos de salón y consolas.
- Dato 7: Las implementaciones tempranas de VRR fueron notorias por parpadeos de brillo a bajos refrescos porque el voltaje del panel y el comportamiento del backlight no estaban afinados para cadencias variables.
- Dato 8: Con el tiempo, los compositores de SO evolucionaron: el soporte VRR en modos de ventana se volvió más común, reduciendo la dependencia de “pantalla completa exclusiva”.
- Dato 9: Muchos monitores se envían con múltiples modos de overdrive; normalmente solo uno está sintonizado para VRR, y el modo más rápido suele verse peor en la práctica.
Guía de diagnóstico rápido: encuentra el cuello de botella pronto
Cuando VRR “no funciona”, trátalo como una interrupción. Necesitas un bucle corto: reproducir, aislar, medir, decidir. Aquí está la secuencia que ahorra tiempo.
Primero: verifica la cadena física
- Confirma que estás en el puerto previsto (DP vs HDMI) y no a través de un dock/hub MST.
- Confirma que la tasa de refresco está realmente configurada al objetivo (144/165/240), no silenciosamente a 60.
- Cambia el cable por uno conocido y bueno certificado. Sí, de verdad.
Segundo: confirma que VRR está habilitado en cada capa
- OSD del monitor: interruptor FreeSync/Adaptive-Sync/VRR habilitado.
- Controlador GPU: G-Sync habilitado (NVIDIA) o FreeSync habilitado (AMD).
- Sistema operativo: VRR activado donde aplique; confirma el modo (pantalla completa vs ventana).
Tercero: determina el modo de fallo
- Desgarro por encima del techo de refresco: estás saliendo del rango VRR; limita FPS y/o habilita V-Sync del controlador.
- Parpadeo cerca de bajos fps: estás cerca del umbral mínimo VRR; LFC ausente o fallando; ajusta configuraciones o reduce carga.
- Pantallas negras / pérdida de señal: inestabilidad en link training; problema de cable/puerto/firmware; reduce ancho de banda (desactiva 10-bit, baja refresco) para confirmar.
- Tartamudeo a pesar de VRR: picos en tiempos de frame; investiga CPU, compilación de shaders, tareas en segundo plano, I/O de almacenamiento o límites térmicos.
Cuarto: asegura estabilidad antes de afinar
No empieces con ajustes exóticos. Obtén una línea base estable: monitor único, conexión directa, refresco conocido, VRR activado, overdrive sensato.
Luego optimiza.
Tareas prácticas (con comandos): verificar, medir, decidir
Estas son tareas reales que puedes ejecutar en Windows (vía PowerShell), Linux y pilas NVIDIA/AMD. Cada tarea incluye:
comando → qué significa la salida → qué decisión tomar.
Úsalas como runbooks.
Task 1 (Linux): identify GPU and driver in use
cr0x@server:~$ lspci -nnk | grep -A3 -E "VGA|3D"
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GP104 [GeForce GTX 1080] [10de:1b80] (rev a1)
Subsystem: Micro-Star International Co., Ltd. [MSI] GP104 [GeForce GTX 1080] [1462:3364]
Kernel driver in use: nvidia
Kernel modules: nvidiafb, nouveau, nvidia_drm, nvidia
Meaning: Confirms which driver owns the device. If you’re on nouveau unintentionally, VRR expectations change.
Decision: If the proprietary driver isn’t loaded, fix that before blaming the monitor.
Task 2 (Linux/NVIDIA): confirm DRM modes and whether VRR is exposed
cr0x@server:~$ xrandr --props | sed -n '/ connected/,/^[A-Z-]\{2,\}/p'
DP-0 connected primary 2560x1440+0+0 (normal left inverted right x axis y axis) 597mm x 336mm
EDID:
00ffffffffffff0010acb5a04c303030...
vrr_capable: 1
non_desktop: 0
Meaning: Some drivers expose a vrr_capable property. 1 suggests the display advertises VRR capability.
Decision: If it’s 0, check cable/port/OSD setting; VRR may be off or unsupported on that input.
Task 3 (Linux): check current mode, refresh, and whether you accidentally run at 60 Hz
cr0x@server:~$ xrandr | grep -A1 "^DP-0"
DP-0 connected primary 2560x1440+0+0 (normal left inverted right x axis y axis) 597mm x 336mm
2560x1440 59.95*+ 143.91 119.98
Meaning: The asterisk is the active mode. Here it’s 59.95 Hz, not 143.91.
Decision: Switch to the intended refresh; VRR range and feel depend on it.
Task 4 (Linux): set the intended refresh mode explicitly
cr0x@server:~$ xrandr --output DP-0 --mode 2560x1440 --rate 143.91
Meaning: Forces the mode. If it fails, the driver or link can’t sustain it.
Decision: If you can’t hold the mode reliably, reduce bandwidth (lower refresh, disable HDR/10-bit) and revisit cable/port quality.
Task 5 (Linux/NVIDIA): confirm the NVIDIA driver sees the display and mode
cr0x@server:~$ nvidia-smi -q | sed -n '/Display Mode/,/Performance State/p'
Display Mode : Enabled
Display Active : Enabled
Persistence Mode : Disabled
Performance State : P0
Meaning: Confirms the GPU believes a display is active and the driver is engaged.
Decision: If display is inactive while a monitor is connected, you’re in a headless/incorrect output situation—fix topology first.
Task 6 (Linux/Wayland): confirm session type (VRR support differs by compositor)
cr0x@server:~$ echo $XDG_SESSION_TYPE
wayland
Meaning: Wayland vs Xorg changes the VRR path, especially for multi-monitor and windowed apps.
Decision: If VRR is unstable in one session type, test the other to isolate compositor issues.
Task 7 (Linux): check kernel messages for link instability or display resets
cr0x@server:~$ dmesg -T | grep -iE "dp|displayport|link training|hdmi|drm|vrr" | tail -n 20
[Mon Jan 13 10:12:41 2026] [drm:nv_drm_master_set [nvidia_drm]] *ERROR* Failed to enable VRR on DP-0
[Mon Jan 13 10:12:43 2026] [drm] DP: link training failed
Meaning: Driver is telling you the link is unstable or VRR couldn’t be enabled.
Decision: Treat as physical-layer problem first: cable, port, reduced bandwidth, firmware update.
Task 8 (Linux): read EDID and look for VRR hints
cr0x@server:~$ sudo get-edid | parse-edid | sed -n '1,80p'
Checksum Correct
Section "Monitor"
Identifier "DELL S2721DGF"
ModelName "DELL S2721DGF"
VendorName "DEL"
EndSection
Meaning: EDID parsing confirms what the monitor claims it is. Some broken chains show generic EDID or none.
Decision: If EDID looks wrong or missing, suspect KVMs, adapters, docks, or a bad cable.
Task 9 (Windows): confirm GPU driver version (PowerShell)
cr0x@server:~$ powershell -NoProfile -Command "Get-CimInstance Win32_VideoController | Select-Object Name,DriverVersion"
Name DriverVersion
NVIDIA GeForce RTX 4070 31.0.15.5212
Meaning: Confirms the driver version in the OS view.
Decision: If you’re chasing a VRR flicker regression, pin or roll back/forward intentionally instead of randomly reinstalling.
Task 10 (Windows): check current refresh rate for the active display (PowerShell)
cr0x@server:~$ powershell -NoProfile -Command "Add-Type -AssemblyName System.Windows.Forms; [System.Windows.Forms.Screen]::PrimaryScreen.Bounds; (Get-CimInstance -Namespace root\wmi -ClassName WmiMonitorBasicDisplayParams | Select-Object -First 1)"
Width Height
----- ------
2560 1440
InstanceName : DISPLAY\DEL41A9\5&2a1c1b2&0&UID4353_0
MaxHorizontalImageSize : 60
MaxVerticalImageSize : 34
VideoInputType : 1
Meaning: Windows makes refresh rate annoyingly indirect, but you’re confirming you’re targeting the right display instance.
Decision: If the wrong display is primary or the wrong instance is active, fix display topology before VRR tuning.
Task 11 (Windows): export a diagnostics snapshot for display and driver state
cr0x@server:~$ powershell -NoProfile -Command "dxdiag /t $env:TEMP\dxdiag.txt; Get-Content $env:TEMP\dxdiag.txt -TotalCount 30"
------------------
System Information
------------------
Time of this report: 1/13/2026, 10:18:22
Machine name: WORKSTATION
Operating System: Windows 11 Pro 64-bit
Meaning: Generates a baseline report you can diff after changes.
Decision: Use it to correlate “VRR broke” with driver/OS updates rather than vibes.
Task 12 (Linux): observe real-time frame pacing proxies (CPU/GPU pressure)
cr0x@server:~$ top -b -n 1 | head -n 15
top - 10:19:41 up 12 days, 3:22, 1 user, load average: 2.31, 1.98, 1.77
Tasks: 317 total, 1 running, 316 sleeping, 0 stopped, 0 zombie
%Cpu(s): 18.2 us, 3.1 sy, 0.0 ni, 77.9 id, 0.5 wa, 0.0 hi, 0.3 si, 0.0 st
MiB Mem : 32018.9 total, 4122.2 free, 11882.7 used, 16014.0 buff/cache
Meaning: Not a VRR tool, but a sanity check: are you CPU bound, are you swapping, is I/O wait high?
Decision: If you see high wa (I/O wait) or memory pressure, your “VRR issue” may actually be system contention.
Task 13 (Linux): check storage latency spikes that masquerade as “stutter”
cr0x@server:~$ iostat -xz 1 3
Linux 6.6.0 (workstation) 01/13/2026 _x86_64_ (16 CPU)
avg-cpu: %user %nice %system %iowait %steal %idle
14.21 0.00 2.91 0.62 0.00 82.26
Device r/s rkB/s rrqm/s %rrqm r_await rareq-sz w/s wkB/s wrqm/s %wrqm w_await wareq-sz aqu-sz %util
nvme0n1 12.00 1400.00 0.00 0.00 0.45 116.67 18.00 2200.00 2.00 10.00 1.20 122.22 0.03 2.10
Meaning: r_await/w_await show latency. Big spikes correlate with hitching.
Decision: If latency spikes align with stutter, fix I/O (shader cache on slow disk, background indexing) before chasing VRR ghosts.
Task 14 (Linux): confirm VRR-related kernel parameters and module options (NVIDIA DRM modeset)
cr0x@server:~$ cat /proc/cmdline
BOOT_IMAGE=/vmlinuz root=/dev/mapper/vg0-root ro quiet splash nvidia-drm.modeset=1
Meaning: Some NVIDIA VRR paths require DRM modesetting enabled.
Decision: If you’re missing nvidia-drm.modeset=1 (in certain setups), enable it and retest—after confirming your distro guidance.
Task 15 (Linux): list connected displays and VRR properties via DRM (if available)
cr0x@server:~$ ls -1 /sys/class/drm | head
card0
card0-DP-1
card0-HDMI-A-1
card1
renderD128
Meaning: Shows what the kernel sees. If your expected output is missing, the problem is below the desktop environment.
Decision: If the connector node doesn’t exist, suspect hardware/firmware/BIOS, dock, or a disabled GPU output.
Task 16 (Linux): check for MST (multi-stream transport) topology that often breaks VRR
cr0x@server:~$ grep -R . /sys/class/drm/card0-DP-1/modes 2>/dev/null | head -n 5
2560x1440
1920x1080
Meaning: Not a direct MST detector by itself, but if you’re on a dock, you should assume MST unless proven otherwise.
Decision: If VRR is flaky and you’re on a dock, test direct GPU-to-monitor connection before doing anything else.
Tres micro-historias del mundo corporativo desde las trincheras
Micro-historia 1: El incidente causado por una suposición errónea
Un equipo de herramientas internas desplegó una “pantalla estándar para desarrolladores”. El objetivo no era jugar; era desplazamiento suave y menos fatiga visual.
Alguien leyó “FreeSync” como “buena tecnología moderna de pantalla” y lo marcó como requisito. Compras lo aprobó. El precio era correcto. Cientos de unidades enviadas.
Semanas después, tickets comenzaron: pantallas negras tras despertar, tartamudeos al arrastrar ventanas, desconexiones aleatorias durante videollamadas.
Era inconsistente—energía clásica de sistemas distribuidos. El mismo modelo funcionaba bien en escritorios pero fallaba en portátiles con docks USB-C.
La suposición equivocada: “Si un monitor soporta VRR, es irrelevante cuando no juegas.” No es verdad. Muchos monitores atan los interruptores VRR a un comportamiento de timing más amplio,
y los docks frecuentemente exponen DisplayPort MST o caminos de link training extraños. Cuando el monitor negociaba un modo a través de la cadena del dock, ocasionalmente aterrizaba en
una configuración frágil. VRR no se “usaba”, pero su presencia influía en el handshake.
La solución fue aburrida: deshabilitar Adaptive-Sync en el OSD del monitor a nivel de flota para usuarios con dock, y estandarizar un cable DP conocido y bueno para los escritorios.
La lección: capacidades que no planeas usar aún afectan al sistema. En términos de operaciones, tu “función no usada” sigue siendo código en ejecución.
Micro-historia 2: La optimización que salió mal
Un equipo de una aplicación gráfica pesada quería menor latencia en un entorno de demostración. Leyeron un consejo en línea: “apaga V-Sync; añade retardo.”
Empujaron un perfil de configuración que deshabilitó V-Sync en todas partes y dijeron a los usuarios que confiaran en VRR.
Llegó el día de la demo. En GPUs de gama alta, la app excedió constantemente el techo de refresco del monitor. VRR manejó la porción dentro del rango,
pero en cuanto la tasa de frames superó el refresco máximo, el tearing volvió—a veces sutil, a veces obvio durante paneos rápidos.
El equipo optimizó para el régimen equivocado. Redujeron un tipo de latencia pero reintrodujeron un artefacto visual que hacía que la demo se sintiera barata.
Peor aún: el tearing solo aparecía en las máquinas más rápidas, así que los equipos “mejores” se veían peor. Ironía divertida.
El rollback fue simple: habilitar V-Sync a nivel de controlador y limitar FPS justo por debajo del refresco máximo. La latencia siguió siendo excelente, el tearing desapareció
y el comportamiento fue consistente entre máquinas. La optimización no es vibra; es teoría de control con marketing.
Micro-historia 3: La práctica aburrida pero correcta que salvó el día
Un estudio mantenía un pequeño laboratorio de render y captura: múltiples PCs, múltiples monitores, tarjetas de captura y actualizaciones frecuentes de controladores.
Tenían una práctica que parecía paranoica: una lista de verificación de “cadena de pantalla conocida buena”, con modelos exactos de cables, puertos, versiones de firmware
y una simple prueba de humo después de cualquier cambio.
Una semana, una actualización de controlador GPU cambió silenciosamente el comportamiento alrededor de VRR en ventanas. Los editores se quejaron de judder intermitente en las timelines.
El técnico del laboratorio no debatió. Sacó la última instantánea conocida buena, comparó versiones de controlador y SO, y reproducido el problema en una sola máquina.
Debido a que la cadena estaba documentada, no perdieron tiempo intercambiando todo al azar. Anclaron el controlador, programaron una ventana de actualización controlada
y añadieron un clip de regresión que hacía obvio el tartamudeo relacionado con VRR en 10 segundos.
Nadie aplaude esto. No parece innovación. Pero previno horas de discusiones “¿es el monitor?” y mantuvo la producción en movimiento.
La práctica aburrida no era precaución; era rendimiento.
Errores comunes: síntoma → causa raíz → solución
1) Síntoma: aparece tearing aunque VRR esté activado
Causa raíz: FPS excede el máximo VRR; VRR no puede seguir por encima del techo, así que obtienes tearing a menos que V-Sync (u otro limitador) lo detenga.
Solución: Limita FPS 2–5% por debajo del refresco máximo y activa V-Sync del controlador. Valida que realmente estés corriendo a la tasa de refresco prevista.
2) Síntoma: parpadeo de brillo en escenas oscuras a bajos FPS
Causa raíz: VRR cerca del umbral mínimo; comportamiento del panel/backlight y tablas de overdrive inestables, o falta de LFC.
Solución: Eleva FPS mínimo (baja ajustes), activa modo con LFC si está disponible, evita el overdrive más rápido, o estrecha el rango VRR si el OSD lo permite.
3) Síntoma: pantallas negras aleatorias de 1–3 segundos
Causa raíz: Inestabilidad en link training a alto ancho de banda (alto refresco + HDR + 10-bit + alta resolución), frecuentemente relacionado con el cable.
Solución: Cambia a un cable conocido y bueno; prueba DisplayPort; desactiva temporalmente HDR/10-bit o reduce refresco para confirmar sensibilidad al ancho de banda; actualiza firmware del monitor si es posible.
4) Síntoma: VRR funciona en pantalla completa pero no en borde-sin-borde/ventana
Causa raíz: La ruta del compositor del SO no permite VRR para superficies en ventana (varía por versión del SO, controlador GPU y compositor).
Solución: Activa “VRR para aplicaciones en ventana” donde esté soportado; prueba pantalla completa exclusiva; actualiza SO/controlador; en Linux prueba Wayland vs Xorg.
5) Síntoma: el tartamudeo persiste, pero el tearing desapareció
Causa raíz: Picos en tiempos de frame por contención de CPU, compilación de shaders, tareas en segundo plano, latencia de almacenamiento, throttling térmico.
Solución: Perfilado de uso CPU/GPU, revisa temperaturas, desactiva overlays en segundo plano, mueve la caché de shaders a almacenamiento rápido y aborda I/O wait o presión de memoria.
6) Síntoma: al activar VRR el movimiento se siente “flotante”
Causa raíz: Encolamiento excesivo de render o smoothing agresivo en el motor; también posible que hayas activado un modo de sincronización que añade buffering.
Solución: Usa un tope de FPS adecuado, activa modo de baja latencia (ajuste del controlador), reduce frames pre-renderizados y verifica que el juego no use un camino de triple-buffer pesado.
7) Síntoma: VRR se desactiva tras suspensión o ciclo de energía
Causa raíz: Bugs de firmware del monitor, condiciones de carrera en el handshake o estado del controlador que no se restaura correctamente.
Solución: Actualiza firmware del monitor; desactiva modos de sueño profundo/eco en el OSD; reajusta el cable; en Linux prueba combinaciones más nuevas de kernel/controlador.
8) Síntoma: VRR funciona con un vendor de GPU pero no con otro
Causa raíz: Diferencias en validación por vendor; algunos monitores solo se comportan bien con ciertas implementaciones VRR.
Solución: Prefiere monitores conocidos por comportarse con tu familia de GPU; si mezclas GPUs, prioriza VRR basado en estándares con buen historial de compatibilidad.
Broma #2: Comprar un “monitor VRR” sin verificar el rango VRR es como comprar una UPS que solo funciona cuando la energía ya está encendida.
Listas de verificación / plan paso a paso
Pasos: configurar un VRR estable (monitor único, PC)
- Elige el puerto correcto: Usa DisplayPort para monitores de PC a menos que necesites específicamente funciones HDMI 2.1.
- Activa VRR en el OSD del monitor: “Adaptive-Sync”, “FreeSync” o “VRR”.
- Configura la tasa de refresco correcta en el SO: Verifica que no haya quedado en 60 Hz.
- Activa VRR en el controlador GPU: NVIDIA: habilita G-Sync para la pantalla; AMD: habilita FreeSync.
- Configura V-Sync del controlador: Evita tearing por encima del techo VRR.
- Limita FPS ligeramente por debajo del refresco máximo: Limitador dentro del juego preferido; si no, un limitador externo conocido y bueno.
- Elige overdrive sensato: Evita el modo más rápido a menos que esté comprobado limpio en rangos VRR.
- Valida en una escena de prueba repetible: Un paneo de cámara consistente o un benchmark integrado; no compares con “gameplay aleatorio”.
Pasos: solucionar parpadeo
- Confirma que el parpadeo se correlaciona con bandas de FPS bajas (observa el contador de FPS).
- Baja ajustes gráficos o resolución temporalmente para mantener FPS por encima del mínimo VRR.
- Cambia modos de overdrive; si está activo el modo más rápido, reduce.
- Desactiva HDR temporalmente y vuelve a probar (algunas tuberías HDR empeoran el parpadeo).
- Si es posible, prueba otro puerto (DP vs HDMI) y otro cable.
- Si el monitor lo permite, estrecha el rango VRR o desactiva VRR para ese juego si es irremediable.
Pasos: solucionar pantallas negras / pérdida de señal
- Reduce ancho de banda: baja un paso la tasa de refresco y desactiva HDR/10-bit.
- Cambia a un cable corto y conocido y bueno.
- Prueba otro puerto GPU en la misma tarjeta.
- Actualiza el controlador GPU; si sospechas regresión, retrocede a una versión estable conocida.
- Actualiza firmware del monitor si el proveedor ofrece herramienta.
- Elimina docks, adaptadores, KVMs y receptores AV de la cadena para aislar.
Checklist: qué evitar al comprar
- Un rango VRR estrecho (como 48–75 Hz) si esperas caídas de rendimiento.
- Sin LFC si tu carga no se mantiene por encima del refresco mínimo.
- “HDR” con poco brillo real y sin local dimming significativo—el HDR de marketing puede empeorar la experiencia.
- Monitores con reputación de parpadeo en reportes de usuarios—esto suele ser comportamiento de firmware/panel, no un controlador que puedas desear fuera.
- Exigir VRR sobre dock/MST como requisito—trátalo como mejor esfuerzo, no como especificación.
Preguntas frecuentes
1) ¿G-Sync es “mejor” que FreeSync?
G-Sync con módulo ha sido históricamente más consistente: rangos VRR más amplios, mejor overdrive variable y menos sorpresas en el handshake.
FreeSync puede ser igual de bueno en un monitor excelente, pero la varianza es mayor. Si odias depurar, compra consistencia.
2) ¿Qué significa realmente “G-Sync Compatible”?
Significa que el monitor usa VRR basado en estándares y NVIDIA ha probado ese modelo para que cumpla sus expectativas mínimas de comportamiento.
Reduce el riesgo; no lo elimina. Las actualizaciones de firmware aún pueden cambiar el comportamiento, para bien o para mal.
3) ¿Necesito VRR si juego mayoritariamente a 60 fps bloqueados?
Si estás verdaderamente bloqueado (tiempos de frame estables) y no te importa el V-Sync clásico, VRR es menos crítico.
VRR brilla cuando la tasa de frames fluctúa: juegos de mundo abierto, ports mal optimizados o cualquier cosa con picos.
4) ¿Por qué la gente recomienda activar V-Sync con VRR?
Porque VRR solo funciona dentro de su rango. Por encima del refresco máximo, aún puedes tener tearing.
V-Sync del controlador actúa como protección en el extremo superior, especialmente combinado con un tope de FPS justo por debajo del refresco máximo.
5) ¿Qué es LFC y lo necesito?
LFC repite frames para mantener el refresco efectivo dentro del rango VRR cuando los FPS caen por debajo del refresco mínimo soportado.
Si tus juegos bajan por debajo del piso VRR, LFC marca la diferencia entre “aún relativamente suave” y “fiesta de tartamudeos”.
6) ¿DisplayPort o HDMI para VRR?
Para monitores de PC, DisplayPort suele ser la apuesta más segura. Para TVs y consolas, HDMI VRR es la vía estándar.
Si ves pantallas negras, prueba la otra interfaz si puedes—es una forma rápida de aislar problemas de enlace.
7) ¿Por qué VRR se rompe cuando añado un segundo monitor?
Las tasas de refresco mezcladas y la programación del compositor pueden interferir, y algunos GPUs/controladores manejan mal VRR en multi-monitor.
Intenta poner el monitor VRR como primario, igualar tasas de refresco cuando sea posible o desactivar VRR en la pantalla secundaria.
8) ¿VRR es útil para productividad (scrolling, movimiento de ventanas)?
A veces. Puede hacer que el contenido con movimiento variable se sienta más suave, pero también puede introducir parpadeo en ciertos rangos de brillo en algunos paneles.
Para flotas, prioriza refresco fijo estable y buena calidad de panel; trata VRR como un complemento agradable.
9) ¿Un mal cable realmente puede causar parpadeo VRR o pantallas negras?
Sí. VRR cambia el comportamiento de temporización y estresa la estabilidad del enlace, especialmente en modos de alto ancho de banda.
Si reducir refresco/HDR “arregla” el problema, probablemente la culpa sea el margen del cable o del puerto.
10) ¿Debería pagar extra por un monitor con módulo G-Sync en 2026?
Págalo si tu objetivo es predictibilidad y mantienes GPUs NVIDIA. Si cambias de proveedor de GPU o buscas mejor relación calidad-precio,
un monitor Adaptive-Sync probado con buen rango VRR y LFC suele ser la compra más inteligente.
Conclusión: qué hacer a continuación
La “guerra” G-Sync vs FreeSync no fue solo branding. Moldeó el mercado de monitores: un camino optimizó control y predictibilidad,
el otro escala y presionó precios. Los usuarios finales heredaron la complejidad.
Pasos prácticos a seguir:
- Antes de comprar: prioriza rango VRR, soporte LFC y reportes reales de parpadeo/pantallas negras por encima de los logos.
- Antes de afinar: estabiliza la cadena física—conexión directa, tasa de refresco correcta, cable conocido y bueno.
- Para la mejor sensación: VRR activado, V-Sync del controlador activado, tope de FPS ligeramente por debajo del refresco máximo, overdrive sensato.
- Si aún se siente mal: trátalo como un incidente—mide pacing de frames, revisa estabilidad del enlace, aísla compositor y variables multi-monitor.
No necesitas “ganar” la guerra de monitores. Necesitas que tus píxeles lleguen a tiempo, cada vez, sin drama. Esa es una demanda perfectamente razonable.