Los parches me robaron los FPS: mito, realidad y la aburrida verdad

Mito vs. realidad: cuándo los parches realmente perjudican

El mito: cada parche roba FPS porque los desarrolladores son descuidados o porque las actualizaciones son inherentemente “más pesadas”. Esa historia es emocionalmente satisfactoria. También no explica nada.

La realidad: los cambios de rendimiento tras los parches caen en unos cuantos cubos, y solo algunos son regresiones reales. Si puedes nombrar el cubo, puedes arreglarlo—o al menos presentar un informe de error que no sea ridiculizado en triage.

Bucket 1: regresiones reales (sí, ocurren)

Una regresión genuina es cuando la nueva versión realiza más trabajo por frame o hace el mismo trabajo de forma menos eficiente. Ejemplos: una ruta de render ahora usa un shader más lento, se activa por defecto un nuevo efecto de post-proceso más costoso, un cambio en la física aumenta las comprobaciones de colisión, o un controlador cambia la ruta del compilador para ciertos shaders.

Estas son reales, medibles y típicamente reproducibles en varias máquinas. Si tienes números antes/después y un recorrido de prueba estable, estás en buena posición.

Bucket 2: efectos de “calentamiento” (caches de shaders y compilación de pipelines)

Muchos informes de “mis FPS murieron tras un parche” son solo tartamudeos por compilación de shaders. Los parches a menudo invalidan caches de shaders, cambian pipelines o añaden nuevos shaders. Tus primeras partidas pegan tirones. Luego se estabiliza.

Si la queja es “tirones, no una media más baja de FPS”, asume caches primero. Si la queja es “la media cayó un 20%”, asume otra cosa.

Bucket 3: restablecimientos de ajustes y alternancias silenciosas

Las actualizaciones adoran restablecer ajustes. Juegos, controladores y SO lo hacen. Tu escala de resolución salta. El trazado de rayos se activa. Tu plan de energía vuelve a “equilibrado”. Tu controlador de GPU decide que ahora te gusta “potencia óptima”.

Este es el “retroceso” más común porque no es una regresión. Es amnesia.

Bucket 4: mitigaciones de seguridad y cambios en el kernel

Algunas actualizaciones sí reducen el rendimiento por diseño, especialmente mitigaciones de seguridad para problemas de ejecución especulativa. El impacto varía mucho según la carga de trabajo. Para muchos juegos, el impacto es pequeño; para títulos intensivos en CPU o motores con muchas llamadas al sistema, puede ser medible.

También: cambios en el planificador del kernel, comportamiento de temporizadores y ajustes de gestión de energía pueden desplazar los frametimes. No necesitas ser ingeniero de kernel para detectarlo; necesitas un benchmark repetible y paciencia para aislarlo.

Bucket 5: actividad en segundo plano que no pediste

Tras parchear, los sistemas suelen realizar “mantenimiento”: indexado, picos de telemetría, reconstrucción de caches de shaders, reinspecciones del antivirus, tareas de optimización del controlador, sincronización en la nube. Si tus tirones coinciden con I/O de disco o picos de CPU, este cubo es tu sospechoso principal.

Bucket 6: el placebo de notar

A veces el parche no cambió el rendimiento. Cambiaste tu atención. Empezaste a mirar el contador de FPS, activaste una superposición de frametime, jugaste en otro mapa, o entraste en un servidor con distinto tick y latencia.

Los humanos son excelentes detectando incomodidad y terribles en experimentos controlados. A tu GPU no le importan las vibras.

Una cita para mantenerte honesto: la idea de Peter Drucker (parafraseada): lo que no puedes medir, no puedes gestionar. Medir es cómo dejas de discutir con tu memoria.

Qué cambian realmente los parches (y por qué los FPS son frágiles)

FPS no es un solo número. Es la salida de una tubería con múltiples partes móviles, cada una con su modo de fallo. Tu “FPS promedio” puede mantenerse bien mientras los frametimes se disparan y el juego se siente terrible. O tus 1% bajos se desploman mientras los promedios parecen normales. O tu latencia de entrada aumenta y lo llamas “lag” aunque la red esté bien.

Juegos: contenido, shaders y trabajo de CPU

Los parches de juego pueden cambiar:

• Shaders y materiales: nuevas permutaciones, nuevas banderas de compilación, rutas de muestreo de texturas distintas.
• Funciones de render: activar opciones más costosas por defecto, cambiar umbrales de LOD, añadir pases de oclusión/visibilidad.
• Simulación: pasos de física, tasas de tick de IA, conteo de partículas, complejidad del mezclado de audio.
• Streaming de assets: nueva compresión, heurísticas de streaming cambiadas, assets más grandes, distintos tamaños de prefetch.
• Telemetría/anti-trampas: drivers en modo kernel adicionales, comprobaciones más frecuentes, mayor coste de CPU en casos extremos.

Controladores: cambios en el compilador y comportamiento de energía

Los controladores de GPU son básicamente compiladores más un planificador y un gestor de energía. Una actualización del controlador puede:

• Cambiar la salida de compilación de shaders para juegos específicos (a veces más rápido, a veces no).
• Modificar cómo se comportan los boost clocks bajo ciertas condiciones térmicas o de potencia.
• Restablecer perfiles por juego, incluyendo limitadores de frames y modos de baja latencia.
• Cambiar cómo se almacenan y reutilizan caches de pipeline en DX12/Vulkan.

Actualizaciones del SO: kernel, planificador y servicios “útiles”

Los parches del SO pueden cambiar el scheduling, el comportamiento de coalescencia de temporizadores, el manejo de faltas de página, rutas de código del sistema de archivos, políticas de compresión de memoria y mitigaciones de seguridad. Incluso si la sobrecarga bruta es pequeña, puede aparecer como frametimes inconsistentes—especialmente en CPUs ya cerca del límite.

Y luego está lo aburrido: un parche desencadena un escaneo en segundo plano, que satura la cola de tu SSD, que retrasa el streaming de assets, y eso se convierte en tartamudeo. Eso no es una “regresión gráfica.” Es una cola de almacenamiento diciendo “no”.

Broma #1: Un parche no “robó” tus FPS; simplemente los “reasignó” al departamento de indexado en segundo plano.

El modelo mental: encuentra el palo más largo por frame

Cada frame tiene un presupuesto. A 60 FPS tienes 16,67 ms. A 120 FPS tienes 8,33 ms. Si excedes el presupuesto, tartamudeas, pierdes frames o ambas cosas.

La pregunta no es “¿un parche redujo los FPS?” La pregunta es “¿qué etapa ahora excede el presupuesto?” ¿Hilo principal de CPU? ¿Hilo de render? ¿GPU? ¿I/O de disco? ¿Sobrecarga del controlador? ¿Latencia de interrupt/DPC? ¿Throttling térmico?

La ingeniería de rendimiento es mayormente negación: negarse a adivinar, negarse a perseguir fantasmas, negarse a arreglar lo que no mediste.

Hechos interesantes y contexto histórico (las partes que la gente olvida)

• Las mitigaciones de seguridad pueden ser medibles: las mitigaciones post-2018 para ejecución especulativa (p. ej., para problemas tipo Spectre/Meltdown) introdujeron sobrecarga real en ciertas transiciones kernel/usuario y patrones de I/O, y algunas cargas de trabajo lo notaron.
• El tartamudeo por compilación de shaders es antiguo: existía mucho antes de las APIs modernas; las nuevas tuberías simplemente facilitaron golpearlo cuando las caches se invalidan o los controladores cambian la generación de código.
• El pacing de frames importa más que el FPS promedio: muchos motores “se sienten” peor tras cambios que aumentan la varianza, aunque la media sea similar. Los 1% bajos se convirtieron en una métrica mainstream por una razón.
• Las actualizaciones de Windows pueden restablecer políticas de energía: las actualizaciones de funciones y algunas instalaciones de controladores suelen revertir planes de energía o valores por defecto de GPU, especialmente en portátiles.
• Los controladores incluyen perfiles por título: ambos grandes proveedores mantienen optimizaciones por título; las actualizaciones pueden ayudar a uno y perjudicar a otro debido a heurísticas y cambios en el compilador.
• DX12/Vulkan movieron trabajo a la aplicación: la promesa es menor sobrecarga del controlador, pero también significa que los juegos pueden compilar pipelines en momentos inconvenientes si no están bien diseñados.
• El almacenamiento se volvió más rápido, las expectativas crecieron: NVMe redujo tiempos de carga, pero también fomentó un streaming más agresivo. Cuando ocurren fallos de almacenamiento, son más visibles porque la tubería es más ajustada.
• El anti-trampa se ha profundizado: más títulos usan componentes en modo kernel. Pueden interactuar con controladores y características de seguridad, a veces produciendo ruido en el scheduling o contención.
• El “mantenimiento” en segundo plano no es nuevo: indexado, actualizaciones y escaneos siempre han existido, pero los sistemas modernos lo hacen automáticamente y con más frecuencia.

Guion de diagnóstico rápido

Este es el orden que uso cuando alguien dice “el parche mató el rendimiento” y quiero una respuesta en 15 minutos, no un fin de semana.

Primero: clasifica el dolor (promedio vs tartamudeo vs latencia)

• FPS promedio bajó: probablemente un cuello de botella sostenido (limitado por GPU, limitado por CPU, tope de potencia/temporal, nueva carga de trabajo).
• Tartamudeo / picos de frametime: probable compilación, streaming de assets, paginación, I/O en segundo plano, problemas DPC del controlador.
• La entrada se siente retrasada: podría ser cambios en limitadores de frames, vsync, profundidad de cola de render, toggles de modo de baja latencia o saturación de CPU.

Segundo: verifica qué cambió (ajustes, controladores, energía)

1. Verifica que los ajustes gráficos del juego no se hayan restablecido (escala de resolución, RT, DLSS/FSR, límites de frame).
2. Confirma si la versión del controlador de GPU cambió (y si reseteó el perfil por juego).
3. Confirma que el modo de energía del SO no haya revertido. En portátiles, también verifica si estás con batería y atrapado en un modo de TDP bajo.

Tercero: identifica el cuello de botella con una superposición y un gráfico

Usa una herramienta que muestre tiempo GPU, tiempo de frame de CPU y uso de VRAM/RAM, además de un gráfico de frametimes. Si el tiempo GPU es mayor que el tiempo CPU, estás limitado por GPU. Si el tiempo CPU es mayor, estás limitado por CPU. Si los picos de frametime se correlacionan con I/O de disco o faltas de página, es streaming/paginación.

Cuarto: elimina el ruido de fondo

Justo después de parchear, deja el sistema inactivo 10–20 minutos, enchufado, pantalla encendida, para que termine indexado/escaneos. Luego prueba otra vez. Si el rendimiento “mágicamente” regresa, no arreglaste nada; simplemente esperaste a que terminara el mantenimiento.

Quinto: reproduce con una prueba estable

Mismo mapa. Misma escena. Mismo recorrido de cámara si es posible. Misma resolución. Mismos ajustes del controlador. Si no puedes reproducirlo de forma fiable, no puedes diagnosticarlo de forma fiable.

Sexto: solo entonces culpa al parche

Si puedes reproducirlo tras reinicios, con tareas en segundo plano quietas, ajustes verificados y un benchmark estable, entonces puedes decir con credibilidad “esta versión es más lenta”. Ahí es cuando presentas un informe accionable (o haces rollback).

Tareas prácticas: comandos, salidas, decisiones

Estos son chequeos reales que correrían en una caja de juego Linux o una estación de trabajo que hace cargas de GPU. Si estás en Windows, las ideas siguen aplicando, pero los comandos no. El punto es dejar de adivinar y empezar a acotar.

Tarea 1: Confirmar kernel y build del SO (¿realmente parcheamos?)

cr0x@server:~$ uname -a
Linux cr0xbox 6.5.0-14-generic #14~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC x86_64 GNU/Linux

Qué significa: Versión y sabor del kernel. Un salto de kernel puede cambiar comportamiento del planificador, mitigaciones e interacciones con controladores.

Decisión: Si el rendimiento cambió justo después de una actualización de kernel, prueba el kernel anterior desde el gestor de arranque, o instala un kernel LTS para comparar.

Tarea 2: Listar actualizaciones de paquetes recientes (qué cambió anoche)

cr0x@server:~$ grep " upgraded " /var/log/dpkg.log | tail -n 8
2026-01-09 03:12:10 upgraded linux-image-6.5.0-14-generic:amd64 6.5.0-13.13~22.04.1 6.5.0-14.14~22.04.1
2026-01-09 03:12:12 upgraded linux-modules-6.5.0-14-generic:amd64 6.5.0-13.13~22.04.1 6.5.0-14.14~22.04.1
2026-01-09 03:12:20 upgraded nvidia-driver-550:amd64 550.54.14-0ubuntu0.22.04.1 550.67-0ubuntu0.22.04.1
2026-01-09 03:12:35 upgraded mesa-vulkan-drivers:amd64 24.0.5-1~22.04.2 24.0.6-1~22.04.2

Qué significa: Evidencia concreta de qué cambió: kernel, driver NVIDIA, Mesa Vulkan.

Decisión: Si cambiaron tanto kernel como la pila GPU, aísla: mantiene kernel constante y cambia la versión del driver (o viceversa). No depures con dos partes moviéndose a la vez.

Tarea 3: Verificar el estado del driver y runtime de GPU (¿el driver está sano?)

cr0x@server:~$ nvidia-smi
Sat Jan 10 12:18:44 2026
+-----------------------------------------------------------------------------------------+
| NVIDIA-SMI 550.67                 Driver Version: 550.67         CUDA Version: 12.4     |
|-----------------------------------------+------------------------+----------------------|
| 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  NVIDIA GeForce RTX 4070        Off | 00000000:01:00.0   On  |                  N/A |
| 30%   54C    P2              85W / 200W |    2100MiB / 12282MiB  |     12%      Default |
+-----------------------------------------+------------------------+----------------------+

Qué significa: Versión del driver, clocks/estado de rendimiento de la GPU, consumo de potencia, uso de VRAM. “Perf P2” podría indicar que no está alcanzando el boost completo en algunos casos.

Decisión: Si el rendimiento es pobre y la GPU está atrapada en un estado de bajo rendimiento, investiga límites de potencia, throttling térmico o ajustes de gestión de potencia del driver.

Tarea 4: Comprobar el gobernador de frecuencia de la CPU (clásico “¿por qué voy lento tras la actualización?”)

cr0x@server:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
powersave

Qué significa: Estás en un governor conservador. En algunos sistemas, actualizaciones o demonios de energía lo cambian.

Decisión: Si juegas o trabajas con sensibilidad de latencia, pon un governor orientado al rendimiento (o arregla la política de energía subyacente).

Tarea 5: Cambiar el governor temporalmente (experimento controlado, no un modo de vida)

cr0x@server:~$ sudo cpupower frequency-set -g performance
Setting cpu: 0
Setting cpu: 1
Setting cpu: 2
Setting cpu: 3

Qué significa: Las CPUs escalarán más agresivamente. Esto puede estabilizar frametimes en títulos limitados por CPU.

Decisión: Vuelve a probar. Si los tirones disminuyen y los FPS vuelven, tu “regresión por parche” es una regresión de política de energía.

Tarea 6: Comprobar si la CPU está en throttling (las térmicas son una nota de parche silenciosa)

cr0x@server:~$ sudo dmesg | egrep -i "throttl|thermal|overheat" | tail -n 5
[  812.223001] thermal thermal_zone0: throttling CPU, temperature too high
[  812.223114] CPU0: Package temperature above threshold, cpu clock throttled

Qué significa: La CPU se está protegiendo. Las actualizaciones pueden cambiar curvas de ventilador, objetivos de potencia, o simplemente aumentar la carga lo suficiente para alcanzar el límite.

Decisión: Arregla la refrigeración, limpia el polvo, revisa la pasta térmica, ajusta límites de potencia. Ningún rollback de driver vence a la física.

Tarea 7: Identificar throttling de GPU / comportamiento de tope de potencia

cr0x@server:~$ nvidia-smi --query-gpu=clocks.sm,clocks.gr,power.draw,power.limit,temperature.gpu,utilization.gpu --format=csv
clocks.sm [MHz], clocks.gr [MHz], power.draw [W], power.limit [W], temperature.gpu, utilization.gpu [%]
2610, 2550, 198.34, 200.00, 73, 98

Qué significa: Cerca del límite de potencia, alta utilización. Si los clocks son más bajos de lo esperado a temperaturas razonables, puedes estar limitado por potencia o alcanzando un límite de voltaje.

Decisión: Si una actualización del driver cambió el comportamiento de boost, compara con el driver anterior o ajusta objetivos de potencia/temperatura dentro de límites seguros.

Tarea 8: Detectar presión de memoria y swap (los picos de frametime adoran el swap)

cr0x@server:~$ free -h
               total        used        free      shared  buff/cache   available
Mem:            31Gi        26Gi       1.2Gi       1.3Gi       3.8Gi       3.9Gi
Swap:          8.0Gi       2.1Gi       5.9Gi

Qué significa: Se está usando swap y la RAM “disponible” es baja. Eso es receta para tartamudeo cuando se hace streaming de assets y ocurren faltas de página.

Decisión: Cierra procesos que consumen memoria, aumenta RAM, reduce ajustes de texturas o ajusta el comportamiento de swap. Si un parche aumentó el uso de RAM, aquí es donde se muestra.

Tarea 9: Comprobar saturación de I/O de disco durante los tirones (el almacenamiento es culpable más a menudo de lo que se admite)

cr0x@server:~$ iostat -xz 1 3
Linux 6.5.0-14-generic (cr0xbox) 	01/10/2026 	_x86_64_	(16 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          18.12    0.00    3.44    6.90    0.00   71.54

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         52.00   8200.00     0.00   0.00    8.20   157.69   40.00   6400.00     0.00   0.00   12.40   160.00   0.78  92.00

Qué significa: NVMe está al 92% de utilización con tiempos de espera no triviales. Si esto coincide con tirones, estás limitado por I/O durante el streaming o tareas en segundo plano.

Decisión: Pausa servicios en segundo plano, mueve el juego a un disco más rápido, asegúrate de que TRIM funciona, o reduce la presión de streaming (calidad de texturas).

Tarea 10: Encontrar al culpable en segundo plano (¿quién está martillando el disco?)

cr0x@server:~$ sudo iotop -oPa
Total DISK READ: 35.21 M/s | Total DISK WRITE: 18.77 M/s
  PID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN     IO>    COMMAND
 2143 be/4 root     28.11 M/s   10.22 M/s  0.00 %  7.11 %  updatedb.mlocate
 1987 be/4 root      2.02 M/s    5.41 M/s  0.00 %  2.34 %  systemd-journald

Qué significa: Una actualización de la base de datos de locate está consumiendo disco. Journald está escribiendo mucho. Este tipo de cosas adora suceder tras actualizaciones.

Decisión: Déjalo terminar, reprograma la tarea o desactívala en sesiones de juego. No diagnostiques “tartamudeo de GPU” mientras el disco está en llamas.

Tarea 11: Comprobar espacio libre en el sistema de archivos (poco espacio puede hundir el rendimiento del SSD)

cr0x@server:~$ df -h /
Filesystem      Size  Used Avail Use% Mounted on
/dev/nvme0n1p2  930G  905G   25G  98% /

Qué significa: 98% usado. Muchos SSD y sistemas de archivos funcionan peor cuando están casi llenos (menos espacio para wear leveling y actualizaciones de metadatos).

Decisión: Libera espacio. Apunta al menos 10–15% libre en SSD de consumo, más si escribes mucho.

Tarea 12: Verificar la programación de TRIM (ayuda al rendimiento sostenido del SSD)

cr0x@server:~$ systemctl status fstrim.timer
● fstrim.timer - Discard unused blocks once a week
     Loaded: loaded (/lib/systemd/system/fstrim.timer; enabled; preset: enabled)
     Active: active (waiting) since Sat 2026-01-10 09:00:01 UTC; 3h 18min ago
    Trigger: Mon 2026-01-12 00:00:00 UTC; 1 day 11h left

Qué significa: TRIM está habilitado semanalmente. Buena higiene de base.

Decisión: Si está deshabilitado en SSD, actívalo. Si el sistema estaba lleno y se limpió recientemente, ejecuta fstrim y vuelve a probar.

Tarea 13: Comprobar tormentas de page-faults (streaming de assets se encuentra con poca RAM)

cr0x@server:~$ vmstat 1 5
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 2  0 214748 1213440 142320 3568120    0    0  8012  6321 3120 8441 21  4 69  6  0
 3  0 214748 1189024 142320 3579000    0    0  9200  7000 3411 9032 24  5 65  6  0

Qué significa: Altos context switches, I/O constante, poca memoria libre. Si ves swap-in/out (si/so) aumentando, estás en problemas.

Decisión: Reduce el uso de memoria, cierra pestañas del navegador (sí, en serio) y revisa procesos en segundo plano que se hayan descontrolado tras el parche.

Tarea 14: Comprobar presión en el scheduling de CPU (¿estamos simplemente sobrecargados?)

cr0x@server:~$ uptime
 12:24:11 up  5:42,  1 user,  load average: 11.20, 9.84, 6.91

Qué significa: Un load average cercano al número de CPUs puede estar bien; load muy por encima significa que hay tareas ejecutables esperando. A los juegos no les gusta esperar.

Decisión: Identifica qué consume CPU. Si un parche introdujo un servicio que satura núcleos, desactívalo o limítalo.

Tarea 15: Identificar los principales consumidores de CPU (los sospechosos habituales)

cr0x@server:~$ ps -eo pid,comm,%cpu,%mem --sort=-%cpu | head
  PID COMMAND         %CPU %MEM
 4121 game.bin        285.2 18.3
 1981 baloo_file      122.4  2.1
 3777 discord          32.1  1.8
 2190 pipewire         18.7  0.4

Qué significa: El juego consume mucho (esperado), pero un indexador de archivos también está quemando CPU. Eso interfiere con los frametimes.

Decisión: Para o reprograma el indexador, luego vuelve a probar. Si el parche desencadenó indexado, tu “regresión” es una tarea en segundo plano.

Tarea 16: Comprobar el estado de mitigaciones del kernel (para el público de “el parche de seguridad mató el rendimiento”)

cr0x@server:~$ grep . /sys/devices/system/cpu/vulnerabilities/* | head
/sys/devices/system/cpu/vulnerabilities/meltdown:Mitigation: PTI
/sys/devices/system/cpu/vulnerabilities/spectre_v2:Mitigation: Retpolines; IBPB: conditional; STIBP: disabled
/sys/devices/system/cpu/vulnerabilities/l1tf:Not affected

Qué significa: Qué mitigaciones están activas. PTI, retpolines, IBPB, etc. Algunas mitigaciones afectan transiciones al kernel o ciertos patrones.

Decisión: No desactives mitigaciones a ciegas. Si mides una gran regresión y entiendes el modelo de riesgo, puedes probar toggles en un sistema no sensible. Si no, déjalas y arregla el verdadero cuello de botella.

Broma #2: Desactivar mitigaciones para recuperar 5 FPS es como quitarte los frenos para mejorar tiempos de vuelta—técnicamente efectivo, socialmente desaconsejado.

Tres microhistorias corporativas desde las trincheras

Microhistoria 1: El incidente causado por una suposición equivocada

En una empresa mediana de software, el laboratorio interno de “game night” también hacía de granja de pruebas gráficas. No era un juguete: los equipos validaban builds de UI aceleradas por GPU y renderizado remoto. Tras un ciclo rutinario de parches de seguridad, todos se quejaron de que los builds “se sentían” peor. La teoría más fuerte era que los parches de seguridad introdujeron un impacto de rendimiento en el kernel. La historia se volvió épica.

Un ingeniero hizo rollback del kernel en algunas máquinas y proclamó victoria. El gráfico de frametimes se veía más suave—brevemente. No fue reproducible. El rollback se volvió un ritual: “si tartamudea, arranca con el kernel viejo.” Eso no es ingeniería; es superstición con botón de reinicio.

La causa real fue más pequeña y estúpida: la actualización cambió la configuración del daemon de perfil de energía de la máquina. El governor de CPU cambió a powersave tras el reinicio en esa generación de hardware. Bajo cargas intermitentes, la CPU no escalaba a tiempo y el hilo principal fallaba en los presupuestos de frame, creando picos.

Cuando forzaron el governor correcto y fijaron el perfil mediante políticas, el rendimiento regresó en todos los kernels. El parche de seguridad no “robó FPS.” La suposición sí: asumieron que el parche tocó solo rutas de código relacionadas con seguridad, no la política del sistema. Esa suposición les costó tres días y creó una cultura de rollback que luego bloqueó fixes reales de seguridad.

Microhistoria 2: La optimización que salió mal

Otra organización manejaba una flota de estaciones Linux para artistas. Un lead decidió “optimizar” las noches de parche ejecutando tareas de mantenimiento pesadas inmediatamente después de las actualizaciones: indexado de archivos, reconstrucción de catálogos de assets y escaneos de integridad. La idea era razonable: hacerlo una vez, fuera de horas, cuando nadie trabaja.

Luego movieron el parcheo de medianoche a primera hora de la mañana para “reducir downtime”. Las tareas de mantenimiento vinieron con el cambio. La primera hora de la jornada se convirtió en un festival de tartamudeos: tirones en el viewport, pausas en compilaciones y lentitud general. La gente culpó al driver más nuevo. La gente siempre culpa al driver más nuevo.

Intentaron cambiar ajustes del driver, cambiar compositores y fijar paquetes Mesa antiguos. Nada funcionó porque el cuello de botella no era la GPU. Era la contención de la cola de almacenamiento: las tareas de mantenimiento saturaban el NVMe con I/O aleatorio pequeño, y las apps creativas tenían que pelear por las mismas colas.

La solución fue casi embarazosa: reprogramar el mantenimiento a las verdaderas horas fuera de jornada, fijar prioridad de I/O para los jobs en segundo plano y limitar la concurrencia. La “regresión” de rendimiento desapareció sin tocar la pila GPU. La optimización falló porque asumió que “fuera de horas” es una marca de tiempo, no una condición. Si los usuarios están activos, no está fuera de horas.

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

Una gran empresa con control de cambios estricto mantenía una “imagen dorada” para estaciones GPU. Gobernanza aburrida, montones de formularios. Los ingenieros se burlaban—hasta que aterrizó una actualización que verdaderamente regresó el rendimiento en una capa de traducción OpenGL/Vulkan usada por una herramienta interna.

En lugar de pánico, tuvieron tres cosas: una base apuntada, un benchmark reproducible y un despliegue escalonado. El grupo de staging detectó la regresión en un día, con números claros antes/después y logs mostrando exactamente qué paquetes cambiaron.

Detuvieron el despliegue, mantuvieron producción en la imagen conocida como buena y presentaron un informe nítido a upstream con un repro mínimo y versiones. Mientras tanto, validaron un workaround: fijar un componente mientras se aplicaban el resto de actualizaciones de seguridad. Riesgo reducido, trabajo continuó, nadie tuvo que “simplemente convivir” con el problema.

Por eso las prácticas aburridas importan. Rollouts, baselines y escenas de prueba no parecen heroicas. Evitan heroísmos.

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

1) “Los FPS bajaron tras el parche” (pero la escala de resolución se restableció)

Síntoma: El FPS promedio cae bruscamente; la utilización de GPU sube; los visuales se ven ligeramente más nítidos.

Causa raíz: La escala de resolución, antialiasing o trazado de rayos activados por defecto tras el parche.

Solución: Revisa los ajustes, confirma la resolución de render, vuelve al preset anterior y vuelve a probar la misma escena.

2) “Hace tirones cada pocos segundos” (disco e indexado)

Síntoma: Picos de frametime alineados con actividad de disco; el FPS promedio puede estar bien.

Causa raíz: Indexado/escaneo en segundo plano tras actualizaciones; streaming de assets compite por I/O.

Solución: Identifica el proceso (iotop), déjalo terminar, reprograma o reduce su prioridad de I/O. Asegura suficiente espacio libre en disco.

3) “Bajos FPS solo después de reiniciar” (reinicio de governor/política de energía)

Síntoma: Primera sesión tras el reinicio es lenta; los clocks de CPU tardan en aumentar; el portátil se siente capado.

Causa raíz: El governor cambió a powersave/balanced, o firmware/demonio revirtió límites de potencia de la plataforma.

Solución: Establece el governor/power mode apropiado, verifica alimentación AC y revisa perfiles de potencia de la plataforma.

4) “Los 1% bajos se desplomaron” (presión de memoria y swap)

Síntoma: FPS promedio correcto; tartamudeos al girar una esquina o cargar zonas; swap aumenta.

Causa raíz: El parche aumentó uso de RAM/VRAM; el sistema empieza a paginar.

Solución: Baja texturas, cierra apps en segundo plano, aumenta RAM, asegúrate de que el swap no esté thrashing.

5) “Uso de GPU bajo pero FPS bajo” (limitado por CPU o sobrecarga del driver)

Síntoma: GPU al 40–60% mientras los FPS son pobres; un núcleo de CPU está saturado.

Causa raíz: Cuello de botella en el hilo principal, sobrecarga del driver o contención de CPU en segundo plano.

Solución: Reduce ajustes que cargan la CPU (distancia de vista, multitudes), mata procesos que consumen CPU en segundo plano, prueba otro renderer (DX11 vs DX12/Vulkan).

6) “En menús va bien, en juego va mal” (reconstrucción de cache de shaders)

Síntoma: Primera partida pega tirones, partidas posteriores mejoran; picos de CPU durante efectos nuevos.

Causa raíz: Cachés de shaders invalidadas por parche o actualización de driver.

Solución: Deja que compile (calentamiento), evita juzgar en la primera ejecución, mantiene caches en almacenamiento rápido, no borres caches a menos que hagas troubleshooting.

7) “VR tartamudea tras la actualización” (sensibilidad de timing)

Síntoma: Caídas de frames/reproyección más frecuentes; pequeños picos arruinan la comodidad.

Causa raíz: VR no tolera la varianza de frametime; tareas en segundo plano o cambios en el scheduling importan más.

Solución: Elimina actividad en segundo plano, fija modo de energía/rendimiento, asegura que la GPU no esté capada por potencia, vuelve a probar con escala de render fija.

8) “Revertir no ayudó” (múltiples cambios y estado cacheado)

Síntoma: Revertiste una cosa; el problema persiste; todos están confundidos.

Causa raíz: Cambiaste dos o más componentes (kernel + driver + juego), o caches/ajustes persistieron tras el rollback.

Solución: Cambia una variable a la vez. Registra versiones. Resetea solo lo relevante (configuración gráfica, cache de shaders si es necesario), luego vuelve a probar.

Listas de verificación / plan paso a paso

Paso a paso: probar (o refutar) “el parche lo causó”

1. Bloquea tu prueba: misma escena, misma resolución, misma ubicación en el juego, mismo replay/demo si está disponible.
2. Registra versiones: build del juego, versión del driver, versión del SO/kernel.
3. Captura frametimes: no confíes en el FPS promedio. Mira los 1% bajos y los picos.
4. Verifica ajustes: especialmente escala de resolución, RT, modo de upscaler, límite de frames, vsync, modo de baja latencia.
5. Comprueba estado de energía: governor de CPU, estado de perf de GPU, AC/batería en portátiles, logs de throttling térmico.
6. Elimina trabajos en segundo plano: indexado, antivirus, herramientas de sincronización, servicios de actualización.
7. Revisa salud del almacenamiento: espacio libre, I/O wait, tiempos de espera altos, programación de TRIM.
8. Revisa presión de memoria: RAM disponible, uso de swap, indicadores de faltas de página.
9. Cambia una variable: haz rollback del driver o swap de kernel o versión del juego (cuando sea posible). No los tres.
10. Vuelve a probar dos veces: la primera ejecución puede incluir reconstrucción de cache; la segunda ejecución se acerca más al estado estable.
11. Decide: si es una regresión reproducible, presenta un bug con números; si es configuración/actividad en segundo plano, arréglalo localmente y documenta.

Checklist: las acciones rápidas “solo quiero volver a la suavidad”

• Reinicia una vez (sí, una vez), luego espera 10 minutos inactivo para que las tareas post-actualización se asienten.
• Confirma que tu modo de energía/governor no está atascado en un estado de bajo consumo.
• Comprueba espacio libre en disco; si estás por encima del 90% usado, arregla eso primero.
• Desactiva overlays que no necesites para la prueba (algunos introducen sobrecarga medible).
• Calienta la compilación de shaders ejecutando la misma escena unos minutos.
• Si el problema empezó con una actualización de driver, prueba la versión anterior del driver.

Checklist: qué incluir en un informe de bug que los ingenieros respetarán

• Versiones antes/después (juego, driver, SO/kernel).
• Ajustes exactos y resolución, incluyendo modo de upscaler y límite de frames.
• Pasos de reproducción con una escena estable y cuánto tiempo correrla.
• FPS promedio más 1% bajo y descripción de picos de frametime.
• Resumen de hardware (CPU, GPU, RAM, tipo de almacenamiento).
• Si la regresión persiste tras la segunda ejecución (cache calentado).

Preguntas frecuentes

1) ¿Los parches realmente bajan los FPS, o es siempre placebo?

Ambas cosas. Existen regresiones reales. El placebo también es común. La diferencia está en la reproducibilidad con una prueba controlada y métricas consistentes (frametime, 1% bajos).

2) ¿Por qué tartamudea justo después de una actualización pero mejora luego?

Invalidación de caches de shaders y mantenimiento en segundo plano. La compilación en la primera ejecución y el indexado post-actualización son clásicos. Prueba tras una ejecución de calentamiento y cuando el sistema esté inactivo.

3) ¿Debo revertir el driver de GPU inmediatamente?

Solo tras verificar restablecimientos de ajustes y actividad en segundo plano. Si el problema comenzó exactamente con la actualización del driver y persiste tras reinicios y ejecuciones de calentamiento, entonces sí: revierte como paso de aislamiento.

4) ¿Las mitigaciones de seguridad son la razón de mi caída de FPS?

A veces, pero rara vez son la primera causa en juegos. Mide primero. Revisa políticas de energía, I/O en segundo plano y restablecimientos de ajustes antes de empezar a tocar mitigaciones y asumir riesgos de seguridad.

5) El FPS promedio se ve bien, pero se siente peor. ¿Qué métrica importa?

La consistencia de frametimes. Observa los 1% bajos y el gráfico de frametimes. Los picos son lo que sientes como tirones, incluso si el promedio es alto.

6) ¿El poco espacio en disco realmente puede causar problemas de FPS?

Sí. El streaming de assets puede tartamudear por saturación de I/O, y los SSD pueden rendir peor cuando están casi llenos. Si estás al 95–99% usado, te has creado un generador de tirones.

7) ¿Por qué la utilización de GPU es baja cuando los FPS son bajos?

Probablemente estás limitado por CPU o bloqueado por otra cosa (sobrecarga del driver, límite de un solo hilo, contención de CPU en segundo plano). La GPU no puede trabajar si no le llegan tareas.

8) ¿Debo “optimizar” desactivando servicios y tareas en segundo plano?

Sé quirúrgico. Desactiva a los ofensores que puedas probar que interfieren (indexadores, escaneos) o reprograma. No desfolles tu sistema al azar y luego te preguntes qué parte rompió las actualizaciones.

9) ¿Cuál es la forma más rápida de saber si está limitado por CPU o GPU?

Usa una superposición que muestre tiempo de frame de CPU y tiempo de GPU. El que sea mayor es tu límite. Entonces enfoca ese subsistema en vez de tocar sliders gráficos al azar.

10) ¿Por qué un parche cambia mis ajustes?

Las migraciones fallan, se introducen nuevas opciones, cambian los valores por defecto, los perfiles se restablecen tras instalaciones de drivers y los archivos de configuración se regeneran. No es malicia; es entropía con nota de versión.

Conclusión: próximos pasos que realmente funcionan

Si solo te llevas una cosa de esto: deja de discutir con el calendario. “Pasó tras el parche” no es lo mismo que “el parche lo causó”. La correlación es donde buenas investigaciones empiezan, no donde terminan.

Esto es lo que hacer la próxima vez que los FPS desaparezcan tras una actualización:

1. Clasifica el problema (caída promedio vs picos de frametime vs latencia de entrada).
2. Verifica ajustes y política de energía (lo poco glamuroso rompe constantemente).
3. Busca I/O en segundo plano y hogs de CPU (el mantenimiento postparche es reincidente).
4. Mide con una prueba estable y guarda evidencia antes/después.
5. Cambia una variable a la vez (rollback de driver, swap de kernel o versión del juego—elige una).

Si es una regresión real, la probarás. Si no lo es, igual la arreglarás—más rápido y con menos folklore. Esa es la aburrida verdad. Aburrido es bueno. Lo aburrido llega a producción.