Una actualización de controlador mató mis FPS: cómo diagnosticarlo correctamente

octubre 14, 2025 • febrero 3, 2026 • Lectura: 25 min • Views: 0

¿Te fue útil?

Actualizaste el controlador de tu GPU porque eres un adulto responsable que parchea cosas. Entonces tu juego se convirtió en un flipbook. Los FPS bajaron, los tiempos de cuadro parecen un sismógrafo y estás a una tartamudez de renunciar a las actualizaciones para siempre.

No supongas. Diagnostica. No estás cazando sensaciones; estás cazando cuellos de botella, regresiones y características “útiles” que cambiaron en silencio. Trátalo como un incidente: confirma la regresión, captura evidencia, aísla variables y avanza o retrocede con confianza.

Guía rápida de diagnóstico (15 minutos)

Esta es la secuencia de “deja de desplazarte y obtén señal”. El objetivo no es afinar tu sistema. El objetivo es responder una pregunta: ¿qué está limitando el rendimiento ahora mismo, y ¿la actualización del controlador pudo haber causado esa limitación?

Paso 1 (3 minutos): Prueba que es una regresión, no una carga diferente

Usa la misma versión del juego, misma escena, misma resolución, mismas opciones, mismo archivo de guardado, mismo mapa y el mismo ángulo de cámara si es posible.
Reinicia una vez después de instalar el controlador. A los controladores les encanta un estado de “pendiente todo”.
Desactiva cosas “únicas”: vídeo en navegador, copias de archivos, descargas de parches del juego.

Decisión: Si no puedes reproducir la caída en una escena controlada, aún no tienes un incidente—solo ruido.

Paso 2 (4 minutos): Identifica la clase de cuello de botella

Limitado por GPU: utilización de GPU cerca del máximo, los FPS escalan con la resolución, bajar la calidad gráfica ayuda.
Limitado por CPU: uno o dos núcleos saturados, la utilización de GPU baja, bajar la resolución no ayuda mucho.
Tartamudeo / limitado por E/S: FPS promedio aceptable, picos en frametime, lecturas de disco, compilación de shaders, streaming de assets.
Limitado por programación / latencia: la entrada se siente pegajosa, el audio chisporrotea, picos de latencia DPC, participación de capturas/overlays.

Decisión: Elige la siguiente herramienta de diagnóstico según la clase de cuello de botella. No “pruebes arreglos” al azar.

Paso 3 (4 minutos): Elimina los sospechosos habituales que los controladores cambian indirectamente

Overlays/captura (Steam, Discord, GeForce Experience, Xbox Game Bar).
Política de energía/rendimiento (plan de energía de Windows, herramientas OEM de portátiles).
VRR / límites de frame / comportamiento de V-Sync cambiado.
Reconstrucción de caché de shaders tras la actualización del controlador.
Conmutaciones ReBAR / MPO / HAGS (dependiendo de la rama del controlador y el SO).

Decisión: Si desactivar una categoría restaura el rendimiento, has encontrado una interacción—no “tu GPU se volvió más lenta”.

Paso 4 (4 minutos): Revertir o instalar limpio según la evidencia

Si la regresión es obvia y reproducible: revierte al último controlador conocido bueno.
Si la actualización fue desordenada (restos, errores, re-detección del dispositivo): realiza una instalación limpia.

Decisión: Prefiere revertir cuando necesites estabilidad; prefiere instalación limpia cuando la evidencia indique “higiene de instalación”.

Una idea parafraseada (atribución): Werner Vogels suele enfatizar que debes “construir para el fallo” y aprender rápido—trata las regresiones como datos, no como drama. (idea parafraseada)

Qué cambia realmente una actualización de controlador (y por qué caen los FPS)

Un controlador de GPU no es solo “nuevas optimizaciones”. Es un motor de políticas. Decide cómo se compilan y almacenan en caché los shaders, cómo el SO programa el trabajo, cómo reaccionan los estados de energía, cómo se maneja el pacing de frames y cómo el controlador interactúa con funciones del compositor como VRR y multi-plane overlay. También puede cambiar los valores por defecto. Los valores por defecto son donde las buenas intenciones crean tu peor benchmark.

Piénsalo como una canalización: entrada → simulación → llamadas de dibujo → ejecución en GPU → presentación. Una actualización del controlador puede mover el punto de estrangulamiento a otra etapa. El FPS promedio puede bajar. O puede mantenerse igual mientras los frametimes se vuelven feos. Lo último es más común de lo que la gente admite, porque “se siente peor” suele ser un problema de latencia/pacing, no de rendimiento bruto.

Los controladores también incluyen correcciones de errores que parecen regresiones porque dejan de depender de comportamientos indefinidos. Algunos juegos (y mods) dependen de rarezas. Cuando el controlador deja de hacer esa cosa accidentalmente útil, tus FPS “cambian misteriosamente”. El misterio es que hemos estado saliéndonos con la nuestra.

Y sí: a veces simplemente es un mal lanzamiento. Pasa. El trabajo es demostrarlo, aislarlo y decidir si retrocedes, parcheas hacia adelante o ajustas el entorno.

Broma #1: Una actualización de controlador es como un “pequeño refactor” en viernes—técnicamente correcto, emocionalmente peligroso.

Hechos interesantes y contexto histórico

Los “perfiles de juego” del controlador son antiguos: los vendedores de GPU han distribuido optimizaciones por juego durante décadas; un nuevo controlador puede cambiar el comportamiento para un título sin tocar otros.
El frame pacing se volvió tema mainstream a principios de los 2010s: el FPS promedio estaba bien, pero los frametimes irregulares hacían que el juego se sintiera peor que el número sugería.
El tartamudeo por compilación de shaders no es nuevo: las APIs y motores antiguos compilaban más fuera de línea; las tuberías modernas a menudo compilan o especializan shaders en tiempo de ejecución, y las cachés dependen del controlador.
WDDM cambió las reglas: el modelo de controladores de Windows evolucionó entre versiones, afectando programación, gestión de memoria y rutas de presentación—las actualizaciones pueden “activar” rutas diferentes en la misma versión de SO.
Los overlays históricamente enganchan rutas de renderizado: contadores de FPS y herramientas de captura suelen inyectarse en APIs gráficas; una actualización puede alterar puntos de hook y la sobrecarga.
Multi-plane overlay (MPO) es sospechoso frecuente: es una característica del compositor que puede mejorar eficiencia, pero ciertas combinaciones de controladores, monitores y apps han producido tartamudeos o parpadeos con los años.
El soporte VRR maduró de forma desigual: el comportamiento G-SYNC/FreeSync depende del firmware del monitor, la política del controlador y las reglas del compositor del SO; las actualizaciones pueden cambiar cómo se comportan los casos límite.
La gestión de energía se volvió más agresiva con el tiempo: GPUs y CPUs modernas cambian frecuencias rápidamente; un pequeño cambio de política puede afectar el comportamiento de boost y la consistencia del frametime.
Resizable BAR (ReBAR) es una vuelta moderna a una idea antigua: mapear ventanas de memoria GPU más grandes puede ayudar algunas cargas y perjudicar otras según patrones del juego y heurísticas del controlador.

Mide primero: los FPS son un síntoma, el frametime es la enfermedad

Cuando alguien dice “mis FPS bajaron”, pregunto: ¿FPS promedio o 1% lows? Porque las regresiones del controlador a menudo golpean la cola. El juego todavía puede mostrar “120 FPS”, pero lo sientes con tirones porque recibes picos periódicos de 40–80 ms.

El frametime es el tiempo para producir un fotograma. Un constante 16.6 ms se siente suave (60 FPS). Un constante 8.3 ms se siente suave (120 FPS). Una mezcla de 5 ms, 6 ms, 40 ms, 7 ms se siente horrible, aunque el promedio parezca bien. Tu cerebro no hace la media; se queja.

Así que: captura métricas que separen rendimiento bruto de latencia.

FPS promedio: rendimiento.
1% / 0.1% lows: latencia en la cola de frames.
Gráfico de frametime: pacing y picos.
Utilización GPU/CPU: dónde estás limitado.
Modo de present / ruta del compositor: si estás peleando con el escritorio.

Además: si actualizaste el controlador y volviste a ejecutar un benchmark inmediatamente, puede que hayas medido el calentamiento de la caché de shaders, no el rendimiento. La primera pasada puede ser mala. La segunda es la realidad. La tercera son estadísticas.

Broma #2: Tus FPS no “murieron”. Solo están esperando un paso de compilación que está teniendo una crisis existencial.

Tareas prácticas: comandos, salidas y decisiones (12+)

Estas tareas son para sistemas Windows porque ahí es donde viven la mayoría de incidentes “el controlador mató mis FPS”. Incluyo herramientas de los vendedores cuando proceda. Usa lo que corresponda a tu GPU.

Tarea 1: Confirma la versión y fecha del controlador GPU (NVIDIA)

cr0x@server:~$ nvidia-smi
Tue Jan 21 10:14:02 2026
+-----------------------------------------------------------------------------------------+
| NVIDIA-SMI 555.42                 Driver Version: 555.42         CUDA Version: 12.5     |
|-----------------------------------------+------------------------+----------------------|
| GPU  Name                 Persistence-M | Bus-Id          Disp.A | Volatile Uncorr. ECC |
| Fan  Temp   Perf          Pwr:Usage/Cap |           Memory-Usage | GPU-Util  Compute M. |
|                                         |                        |               MIG M. |
|=========================================+========================+======================|
|   0  GeForce RTX 4070 Ti           Off  |   00000000:01:00.0  On |                  N/A |
|  36%   63C    P2              165W / 285W|   7340MiB / 12282MiB   |     96%      Default |
+-----------------------------------------+------------------------+----------------------+

Qué significa: Tienes una versión concreta del controlador para correlacionar con la regresión. También observa el estado de rendimiento (P2 vs P0) y GPU-Util.

Decisión: Si la versión no es la que pretendías (Windows Update “ayudó”), para y corrige la procedencia del controlador antes de afinar más.

Tarea 2: Confirma la versión del controlador GPU (herramienta integrada de Windows)

cr0x@server:~$ powershell -NoProfile -Command "Get-CimInstance Win32_VideoController | Select-Object Name, DriverVersion, DriverDate"
Name                           DriverVersion    DriverDate
----                           -------------    ----------
NVIDIA GeForce RTX 4070 Ti     31.0.15.5542     12/18/2025 12:00:00 AM

Qué significa: Versión del controlador tal como la ve Windows, además de la fecha. Esto detecta casos donde el panel de control dice una cosa y el controlador instalado es otra.

Decisión: Si la fecha/versión no coincide con tu “último conocido bueno”, tienes una ventana de regresión. Bien. Ahora puedes hacer una bisect.

Tarea 3: Verifica que no estás ejecutando por accidente en la iGPU (común en portátiles)

cr0x@server:~$ powershell -NoProfile -Command "Get-CimInstance Win32_VideoController | Select-Object Name, AdapterRAM, VideoProcessor"
Name                         AdapterRAM   VideoProcessor
----                         ----------   --------------
Intel(R) Iris(R) Xe Graphics 1073741824   Intel(R) Iris(R) Xe Graphics
NVIDIA GeForce RTX 3060      12884901888  NVIDIA GeForce RTX 3060

Qué significa: Ambos adaptadores existen; el juego puede haber cambiado la preferencia tras la actualización.

Decisión: Si los FPS se hundieron y ves la iGPU activa en overlays o en el Administrador de tareas durante el juego, fuerza el juego al GPU discreto en la configuración de Gráficos de Windows y en el panel del vendedor.

Tarea 4: Revisa el plan de energía de Windows (porque “Equilibrado” puede ser picante)

cr0x@server:~$ powercfg /getactivescheme
Power Scheme GUID: 381b4222-f694-41f0-9685-ff5bb260df2e  (Balanced)

Qué significa: Estás en Equilibrado. Eso no es automáticamente incorrecto, pero es un culpable frecuente de frametimes en algunos sistemas.

Decisión: Si los frametimes empeoraron tras la actualización y estás en Equilibrado, prueba Alto rendimiento (escritorio) o el modo “Rendimiento” del OEM (portátil). Mide; no creas.

Tarea 5: Comprueba si el Modo Juego está activado (y si correlaciona)

cr0x@server:~$ powershell -NoProfile -Command "reg query HKCU\Software\Microsoft\GameBar /v AllowAutoGameMode"
HKEY_CURRENT_USER\Software\Microsoft\GameBar
    AllowAutoGameMode    REG_DWORD    0x1

Qué significa: Modo Juego activado. Normalmente está bien; ocasionalmente interactúa mal con captura/overlays o tareas en segundo plano.

Decisión: Si el problema parece jitter de programación, prueba a alternar el Modo Juego y vuelve a medir la misma escena.

Tarea 6: Inspecciona HAGS (Programación de GPU acelerada por hardware)

cr0x@server:~$ powershell -NoProfile -Command "reg query HKLM\SYSTEM\CurrentControlSet\Control\GraphicsDrivers /v HwSchMode"
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\GraphicsDrivers
    HwSchMode    REG_DWORD    0x2

Qué significa: HwSchMode=2 normalmente significa activado. A algunas máquinas les encanta. A otras les da tartamudeos.

Decisión: Si el problema es “se siente peor” más que “los benchmarks bajaron”, prueba a alternar HAGS y vuelve a probar. Si lo arregla, has encontrado una interacción de políticas.

Tarea 7: Comprueba si tu tasa de refresco fue restablecida (clásico tras actualizaciones)

cr0x@server:~$ powershell -NoProfile -Command "Get-CimInstance -Namespace root\wmi -ClassName WmiMonitorListedSupportedSourceModes | Select-Object -First 1 -ExpandProperty MonitorSourceModes | Select-Object -First 5"
HorizontalActivePixels VerticalActivePixels RefreshRate
---------------------- ------------------- -----------
1920                   1080                60
1920                   1080                120
1920                   1080                144
2560                   1440                60
2560                   1440                144

Qué significa: Modos soportados. Aún necesitas confirmar cuál está seleccionado actualmente en la configuración de pantalla de Windows, pero esto ayuda a detectar situaciones donde el monitor negoció un modo incorrecto.

Decisión: Si pretendías 144 Hz y en realidad estás en 60 Hz, tu historia de límite de FPS/latencia se verá rara. Arregla la tasa de refresco antes de perseguir fantasmas.

Tarea 8: Comprueba si el juego está limitado por CPU o GPU (muestreo rápido en vivo)

cr0x@server:~$ typeperf "\Processor(_Total)\% Processor Time" "\GPU Engine(*)\Utilization Percentage" -sc 5
"(PDH-CSV 4.0)","\\HOST\Processor(_Total)\% Processor Time","\\HOST\GPU Engine(pid_1234_luid_0x0000_0x0000_eng_3D)\Utilization Percentage"
"01/21/2026 10:18:01.123","42.318","97.000"
"01/21/2026 10:18:02.123","45.102","98.000"
"01/21/2026 10:18:03.123","41.777","96.000"
"01/21/2026 10:18:04.123","43.550","97.000"
"01/21/2026 10:18:05.123","44.001","98.000"

Qué significa: Utilización de GPU cerca del máximo mientras la CPU es moderada sugiere GPU-bound. Si la GPU está baja y la CPU alta (o un núcleo alto), estás limitado por CPU/programación.

Decisión: Si estás limitado por GPU y los FPS bajaron tras la actualización, céntrate en ajustes del controlador (energía, filtrado de texturas, caché de shaders, VRR, límites de frame). Si estás limitado por CPU, céntrate en programación, procesos en segundo plano y comportamiento de energía/boost de la CPU.

Tarea 9: Identifica los principales consumidores de CPU en segundo plano durante el juego

cr0x@server:~$ powershell -NoProfile -Command "Get-Process | Sort-Object CPU -Descending | Select-Object -First 10 Name,Id,CPU"
Name            Id      CPU
----            --      ---
Game.exe      1234  812.43
MsMpEng       4321  210.10
Discord       9876   55.22
chrome        2468   44.01
OneDrive      1357   21.88

Qué significa: Defender (MsMpEng) o herramientas de sincronización pueden consumir CPU y causar tartamudeos, especialmente durante reconstrucciones de caché de shaders o cuando el juego escribe logs/configs frecuentemente.

Decisión: Si un proceso en segundo plano está consistentemente alto durante los tirones, ponlo en pausa, excluye la carpeta del juego del escaneo (con cuidado) o prográmalo fuera del juego. Vuelve a probar.

Tarea 10: Comprueba la salud del disco y si la unidad del juego está siendo golpeada

cr0x@server:~$ powershell -NoProfile -Command "Get-PhysicalDisk | Select-Object FriendlyName, MediaType, HealthStatus, OperationalStatus"
FriendlyName        MediaType HealthStatus OperationalStatus
------------        --------- ------------ -----------------
Samsung SSD 980 Pro SSD       Healthy      OK
WDC WD10EZEX       HDD        Healthy      OK

Qué significa: Confirma que no estás transmitiendo assets desde un HDD moribundo mientras asumes que está “bien”.

Decisión: Si el juego está en un HDD y ves tartamudeos tras una actualización, muévelo a SSD antes de culpar al controlador. Los controladores pueden cambiar el comportamiento de la caché de shaders e incrementar el churn de disco.

Tarea 11: Verifica la E/S de disco en tiempo real mientras reproduces un tartamudeo

cr0x@server:~$ powershell -NoProfile -Command "Get-Counter '\PhysicalDisk(_Total)\Avg. Disk sec/Read','\PhysicalDisk(_Total)\Disk Reads/sec' -SampleInterval 1 -MaxSamples 5"
Timestamp                 CounterSamples
---------                 --------------
01/21/2026 10:22:11       \\HOST\physicaldisk(_total)\avg. disk sec/read : 0.085
                          \\HOST\physicaldisk(_total)\disk reads/sec : 420.000
01/21/2026 10:22:12       \\HOST\physicaldisk(_total)\avg. disk sec/read : 0.120
                          \\HOST\physicaldisk(_total)\disk reads/sec : 610.000
01/21/2026 10:22:13       \\HOST\physicaldisk(_total)\avg. disk sec/read : 0.015
                          \\HOST\physicaldisk(_total)\disk reads/sec : 95.000
01/21/2026 10:22:14       \\HOST\physicaldisk(_total)\avg. disk sec/read : 0.090
                          \\HOST\physicaldisk(_total)\disk reads/sec : 500.000
01/21/2026 10:22:15       \\HOST\physicaldisk(_total)\avg. disk sec/read : 0.010
                          \\HOST\physicaldisk(_total)\disk reads/sec : 80.000

Qué significa: Los picos en Avg. Disk sec/Read (p. ej., 80–120 ms) se correlacionan con bloqueos por streaming de assets. Un SSD debería ser mucho más rápido bajo cargas de juego, aunque pueden ocurrir picos.

Decisión: Si los tartamudeos se alinean con picos de latencia de disco, investiga reconstrucción de caché de shaders, escaneo antivirus, contención por descompresión en CPU y espacio libre/estrangulamiento térmico del disco.

Tarea 12: Comprueba si la GPU está limitada por potencia o atascada en un estado inferior (NVIDIA)

cr0x@server:~$ nvidia-smi -q -d PERFORMANCE | sed -n '1,120p'
==============NVSMI LOG==============
Timestamp                                 : Tue Jan 21 10:24:01 2026
Driver Version                            : 555.42
GPU 00000000:01:00.0
    Performance State                      : P2
    Clocks Throttle Reasons
        Idle                               : Not Active
        Applications Clocks Setting         : Not Active
        SW Power Cap                        : Active
        HW Slowdown                         : Not Active
        Thermal Slowdown                    : Not Active

Qué significa: Estás en P2 y el tope de potencia por software está activo. Eso puede ocurrir por ajustes de energía, herramientas de overclocking o cambios en valores predeterminados del vendedor.

Decisión: Si SW Power Cap está activo durante el juego cuando antes no lo estaba, inspecciona el modo de energía del panel del vendedor, elimina herramientas de OC de terceros y revisa PSU/conectores. No “arregles” esto subiendo límites de potencia a ciegas sin entender por qué cambió.

Tarea 13: Revisa los registros de eventos de Windows por reinicios del controlador de pantalla (TDR)

cr0x@server:~$ powershell -NoProfile -Command "Get-WinEvent -FilterHashtable @{LogName='System'; Id=4101} -MaxEvents 5 | Format-Table TimeCreated, ProviderName, Message -AutoSize"
TimeCreated           ProviderName      Message
-----------           ------------      -------
01/21/2026 09:55:12   Display           Display driver nvlddmkm stopped responding and has successfully recovered.

Qué significa: El controlador se reinició. Eso puede causar tartamudeos, bajada de relojes o inestabilidad que parece “caída de FPS”.

Decisión: Si tienes TDRs tras la actualización, deja de afinar el rendimiento y comienza a depurar estabilidad: instalación limpia, quitar overclocks/undervolts, revisar temperaturas, comprobar alimentación PCIe, considerar revertir.

Tarea 14: Captura una traza lista para GPUView (avanzado, pero concluyente)

cr0x@server:~$ wpr -cancel
WPR session cancelled.
cr0x@server:~$ wpr -start GPU -start CPU -filemode
Recording...
cr0x@server:~$ timeout /t 15
Waiting for 15 seconds...
cr0x@server:~$ wpr -stop C:\Temp\fps_drop_trace.etl
WPR trace saved to: C:\Temp\fps_drop_trace.etl

Qué significa: Capturaste una traza que puedes inspeccionar para detectar bloqueos de programación, problemas de presentación y solapamiento CPU/GPU.

Decisión: Si la traza muestra largos huecos en la sumisión de trabajo a la GPU, la CPU (o la sobrecarga del controlador) es tu cuello de botella. Si la cola de GPU está llena y la presentación está bloqueada, examina VRR/V-Sync/las interacciones con el compositor.

Tres microhistorias corporativas desde el terreno

Microhistoria #1: El incidente causado por una suposición errónea

En un estudio mediano, un líder de QA señaló una “regresión de controlador” en la última versión de un proveedor popular de GPU. Los FPS bajaron un 25–30% en su escena de benchmark. El ambiente fue familiar: culpar al controlador, avisar al representante del vendedor, retener notas de la versión.

La suposición errónea fue sutil: asumieron que la escena del benchmark era estable entre builds. No lo era. Había llegado una actualización de contenido la misma semana—nuevo sistema de partículas, camino de cámara ligeramente distinto y un nuevo toggle de postprocesado que se activó por defecto en configuraciones nuevas.

Lo tratamos como un incidente SRE de todos modos. Bloqueamos la carga: mismo hash del ejecutable, mismo archivo de configuración, misma ruta de reproducción, mismo estado de la caché de shaders. También comparamos el directorio de configuración del juego antes y después de la ejecución. Sorpresa: el nuevo controlador forzó un “primer inicio” que restableció los gráficos en ese título, reactivando una opción cara que normalmente mantenían desactivada en los benchmarks.

Una vez fijada la configuración, la “regresión” se redujo a un error de redondeo. Aún quedó un pequeño cambio en la cola de frametime, pero no la caída principal. El culpable real fue un cambio de valor por defecto y un benchmark que derivó silenciosamente.

Conclusión: si no puedes fijar la carga, no estás haciendo benchmarking; estás representando ser un benchmark.

Microhistoria #2: La optimización que salió mal

Un equipo de TI corporativo intentó ser útil. Desplegaron un nuevo controlador de GPU en una flota de estaciones de trabajo de ingeniería—algunas usadas para CAD, otras para simulación y sí, algunas para jugar fuera de horas. El controlador prometía mejor rendimiento y parches de seguridad, y la ventana de cambio fue “tranquila”.

Tras el despliegue, un grupo de usuarios reportó tartamudeos en juegos y en algunas herramientas de visualización. El FPS promedio estaba bien, pero la interacción se sentía pegajosa. La gente empezó a desactivar todo: Modo Juego, overlays, incluso su segundo monitor. Lo típico.

La “optimización” fue activar un conjunto de predeterminados de baja latencia y ahorro de energía vía un perfil de gestión. La intención era reducir térmicas y ruido de ventiladores en una oficina abierta. Funcionó—las térmicas bajaron. También bajó la entrega consistente de frames. Las GPUs oscilaban entre estados más agresivamente, y los picos de frametime coincidían con las transiciones de estado.

La solución fue aburrida: establecer una política de energía sensata y estable para máquinas que hacen trabajo gráfico interactivo, y no forzar modos de baja latencia orientados al juego globalmente. También: probar cambios en una muestra representativa, no en la GPU más ruidosa del inventario.

Las “mejoras” de rendimiento que no se miden contra la calidad de la interacción son solo vibras con privilegios administrativos.

Microhistoria #3: La práctica aburrida pero correcta que salvó el día

Una firma financiera ejecutaba una pequeña app interna de visualización que usaba un motor de juego para dashboards en tiempo real. No es broma. Era una pared de pantallas que necesitaba verse suave porque los ejecutivos notan el tartamudeo como los tiburones notan la sangre.

El equipo tenía una política: cada actualización de controlador requería una captura de “escena conocida”, un informe de frametime y un plan de reversión. A nadie le gustaba. Parecía papeleo. Pero lo mantenían porque una mala actualización años antes había convertido una demo en vivo en una presentación de diapositivas.

Esta vez, el nuevo controlador introdujo tirones esporádicos en setups multi-monitor. El equipo ya tenía líneas base: misma escena, mismo hardware, mismo build de SO. La regresión fue obvia en los 1% lows y en una traza que mostraba retrasos de presentación correlacionados con la actividad del compositor.

Revirtieron en menos de una hora, desplegaron un cambio de configuración para desactivar un componente problemático de overlay en la app y volvieron a probar. El problema desapareció. Luego fijaron versiones de controlador para las máquinas de demo hasta que el vendedor validó una corrección.

La práctica aburrida—líneas base más reversión—significó que no tuvieron que discutir si el problema era “real”. Tenían gráficos. Los ejecutivos obtuvieron visuales suaves. Los ingenieros pudieron dormir.

Errores comunes: síntoma → causa raíz → solución

Esta es la parte donde dejas de encender velas y empiezas a usar un multímetro.

1) “Los FPS bajaron en todos lados”

Síntoma: Todos los juegos bajaron 10–30% tras la actualización.
Causa raíz: Cambió la política de energía (plan de Windows, modo rendimiento del portátil, “optimal power” del vendedor), o la GPU está bajando relojes por un tope.
Solución: Verifica el plan activo; comprueba el estado de rendimiento y las razones de throttle de la GPU; asegúrate de que el panel del vendedor esté en el modo correcto para juegos; elimina herramientas de ajuste de terceros y vuelve a probar.

2) “El FPS promedio está bien, pero tartamudea constantemente”

Síntoma: Picos en frametime cada pocos segundos; la entrada se siente desigual.
Causa raíz: Overlays/capture añaden sobrecarga, reconstrucción de caché de shaders o escaneos en segundo plano (Defender) que afectan archivos de caché.
Solución: Desactiva overlays temporalmente; ejecuta la escena dos veces para calentar cachés; excluye directorios de caché de shaders con cautela; detén descargas en segundo plano.

3) “Bajar la resolución no ayuda”

Síntoma: 1440p y 1080p rinden casi igual, siguen bajos.
Causa raíz: Cuello de botella en CPU o sobrecarga del controlador. A veces un nuevo controlador cambia el comportamiento de hilos o aumenta el coste por draw call en CPU.
Solución: Mide la utilización por núcleo; cierra procesos que consumen CPU en segundo plano; comprueba si el juego cambió a modo sin borde con sobrecarga del compositor; considera revertir si una reproducción limpia muestra mayor tiempo de CPU por frame.

4) “Pantalla completa se siente peor que sin borde (o viceversa)”

Síntoma: Un modo de pantalla tiene peor latencia o tartamudeo.
Causa raíz: Diferentes rutas de present y interacciones con el compositor; desajuste de políticas VRR/V-Sync.
Solución: Prueba ambos modos con el mismo límite de frames; revisa ajustes VRR; asegúrate de que la tasa de refresco sea correcta; considera desactivar MPO/HAGS como experimento si la evidencia apunta a problemas de presentación.

5) “Solo un juego está roto”

Síntoma: Un título cae; otros están normales.
Causa raíz: Cambio de perfil específico del juego en el controlador, sincronización de parche del juego, invalidación de caché de shaders para ese motor, o interacción con anti-cheat/overlay específica.
Solución: Fija la versión del juego; limpia y reconstruye su caché de shaders; desactiva hooks de terceros; prueba revertir el controlador solo para validación, no por superstición.

6) “Después de la actualización, mi uso de GPU es bajo”

Síntoma: La utilización de GPU baja a 40–70% mientras los FPS están bajos.
Causa raíz: Limitación por CPU, proceso en segundo plano robando ranuras de tiempo, problemas de programación del controlador, o el juego ejecutándose en la iGPU.
Solución: Confirma la GPU activa; revisa la CPU por núcleo; captura una traza si es necesario; asegúrate de que no haya un limitador de frames oculto activo.

7) “Los FPS están bloqueados a 60 ahora”

Síntoma: Límite duro a 60 independientemente de las opciones.
Causa raíz: Tasa de refresco restablecida a 60 Hz, V-Sync forzando al refresco, limitador de frames habilitado en el controlador o el juego cambió de modo de pantalla.
Solución: Verifica la tasa de refresco del monitor, desactiva límites a nivel de controlador temporalmente, prueba pantalla completa exclusiva vs sin borde, y revisa el limitador dentro del juego.

Listas de comprobación / plan paso a paso

Checklist A: Antes de tocar nada (disciplina de línea base)

Reinicia una vez después de instalar el controlador.
Elige una escena reproducible (benchmark, replay, rango de entrenamiento, ángulo de cámara fijo).
Registra: resolución, preset gráfico, ajustes DLSS/FSR, estado V-Sync/VRR, límite de frames, modo de pantalla.
Ejecuta la escena dos veces; registra la segunda ejecución (caché calentada).
Captura: FPS promedio, 1% low, gráfico de frametime si lo tienes.

Checklist B: Aislamiento (cambia una cosa a la vez)

Desactiva overlays uno por uno (Discord, Steam, Xbox Game Bar, overlay del vendedor).
Pausa tareas en segundo plano (navegador, sincronización en la nube, descargas).
Alterna HAGS y vuelve a probar.
Cambia entre pantalla completa y sin borde; vuelve a probar.
Alterna VRR (G-SYNC/FreeSync) y estrategia V-Sync; vuelve a probar.
Prueba el último controlador conocido bueno (revertir) para confirmar la regresión.

Checklist C: Cuando sospechas higiene de instalación

Exporta tus ajustes actuales (capturas del panel de control están bien).
Realiza una instalación limpia del controlador (opción del instalador del vendedor) y reinicia.
Vuelve a probar con ajustes por defecto primero.
Vuelve a aplicar solo los ajustes que puedas justificar con mediciones.

Checklist D: Cuando sospechas issues de almacenamiento o caché de shaders

Confirma que el juego esté en un SSD.
Revisa espacio libre (deja margen; a los SSD no les gusta estar llenos).
Observa la latencia de disco durante los tartamudeos.
Ejecuta la misma escena varias veces para ver si el tartamudeo disminuye tras la reconstrucción de caché.
Si es necesario, borra las cachés de shaders (del juego y del controlador) y reconstruye una vez—luego mide la segunda ejecución.

Preguntas frecuentes

1) ¿Debo siempre revertir si los FPS bajan después de actualizar un controlador?

No. Revertir cuando puedas reproducir la regresión en una escena controlada y necesites estabilidad ya. Si es una instalación desordenada o deriva de ajustes, una instalación limpia puede arreglarlo sin perder correcciones de seguridad y perfiles de juego.

2) ¿Por qué la primera ejecución tras actualizar un controlador tartamudea más?

Las cachés de shaders a menudo se invalidan con las actualizaciones. El juego recompila o re-especializa shaders durante el juego, causando picos en frametime. Mide la segunda ejecución, no la primera del pánico.

3) Mi FPS promedio está bien, pero “se siente” peor. ¿Qué debo medir?

Gráficos de frametime y 1% lows. También revisa el modo de present y el comportamiento del compositor (pantalla completa vs sin borde) y desactiva overlays. “Se siente peor” suele ser pacing o latencia, no potencia bruta de GPU.

4) ¿Windows Update puede reemplazar mi controlador de GPU y arruinar el rendimiento?

Sí. Puede instalar una rama de controlador diferente o una variante “segura”. Confirma la versión instalada desde Windows, no solo desde el panel del vendedor.

5) ¿Los overlays realmente cuestan tanto rendimiento?

A veces no, a veces sí—especialmente combinados con rutas de present específicas del controlador o funciones de captura. La maniobra de diagnóstico es sencilla: apágalos y vuelve a probar la misma escena.

6) ¿Vale la pena alternar HAGS, MPO u otras funciones gráficas del SO?

Sólo cuando tienes síntomas consistentes con problemas de programación/present (tartamudeos, latencia rara, anomalías en sin borde) y mides antes/después. Alternar al azar sin datos es culto de carga.

7) ¿Por qué bajar la resolución ya no aumenta los FPS?

Probablemente estás limitado por la CPU, o alcanzaste un límite de frames (V-Sync, limitador, comportamiento VRR). Si la GPU no está cerca del 100% de utilización, no sigas “optimizando ajustes gráficos”. Estás afinando el lado equivocado de la canalización.

8) ¿El almacenamiento puede afectar los FPS si el juego “está funcionando bien”?

El almacenamiento afecta los frametimes mediante el streaming de assets y las lecturas/escrituras de la caché de shaders. Una actualización de controlador puede cambiar el comportamiento de la caché e incrementar la actividad del disco. Si los picos de latencia de disco coinciden con tartamudeos, el almacenamiento es parte del problema.

9) ¿Cuál es la causa más común de rarezas tras una actualización?

Deriva de ajustes: restablecimiento de la tasa de refresco, cambios en la política V-Sync/VRR, cambios de modo de energía, overlays reactivados o el juego cambiando de modo de pantalla. La solución es verificar el entorno antes de culpar al controlador.

10) ¿Cuándo debo escalar a una traza “real” (WPR/GPUView)?

Cuando puedes reproducir el problema de forma fiable y las comprobaciones más sencillas no identifican el cuello de botella. Una traza convierte discusiones en líneas de tiempo: huecos de sumisión CPU, bloqueos de presentación, sobrecarga del controlador y contention quedan visibles.

Siguientes pasos que puedes hacer hoy

Haz esto en orden. Es deliberadamente aburrido.

Bloquea una escena. Mismo lugar, mismas opciones, segunda ejecución medida.
Confirma la procedencia. Registra la versión/fecha del controlador desde Windows y (si aplica) desde herramientas del vendedor.
Clasifica el cuello de botella. ¿GPU-bound, CPU-bound, I/O-bound o pacing/present-bound?
Elimina la sobrecarga obvia. Desactiva overlays/captura temporalmente; pausa tareas en segundo plano.
Verifica refresco y límites. Asegúrate de no haber retrocedido a 60 Hz ni activado un limitador.
Decide revertir vs instalación limpia. Regresión reproducible → revertir para validar. Comportamiento desordenado/TDRs/caos de ajustes → instalación limpia y prueba con valores por defecto.
Si sigues atascado, traza. Captura una traza WPR e inspecciona programación y comportamiento de presentación. La evidencia vence la arqueología de foros.

La idea no es nunca actualizar controladores. La idea es actualizarlos como gestionas sistemas: mide, aísla y conserva una vía de reversión. Tu GPU seguirá teniendo días malos, pero al menos sabrás por qué.