Por qué la CPU estrangula a la GPU a 1080p (y no a 4K)

Idea central: quién marca el ritmo por fotograma

Un único fotograma renderizado es una tubería. La CPU realiza un montón de trabajo para preparar un fotograma: simulación, visibilidad,
animación, construcción de buffers de comandos, comunicación con el driver, programación de trabajo y gestión del ruido del sistema operativo. La GPU hace las matemáticas pesadas
para ejecutar el fotograma: procesamiento de vértices/mallas, rasterización, sombreado, consultas de rayos, postprocesado y escritura de píxeles.

La tasa de fotogramas la marca el lado más lento. Si la CPU necesita 8 ms para producir el trabajo del siguiente fotograma y la GPU necesita 5 ms para renderizarlo,
no obtienes 200 FPS. Obtienes 125 FPS (y la GPU queda inactiva esperando que la CPU le entregue el siguiente lote). Si la GPU necesita 12 ms
y la CPU 6 ms, obtienes 83 FPS y la CPU espera.

Por eso “utilización de GPU” es una trampa cuando la gente la ve como un velocímetro. Una GPU puede estar subutilizada porque:
(1) espera a la CPU, (2) espera por memoria o transferencias PCIe, (3) el juego está capado o limitado por vsync, o (4) el driver
serializa trabajo de una forma que tu monitorización no expone claramente. La utilización es evidencia. No es un diagnóstico.

Por qué 1080p es “territorio de la CPU” y 4K es “territorio de la GPU”

La resolución cambia más el trabajo de la GPU que el de la CPU

Pasar de 1080p (1920×1080) a 4K (3840×2160) cuadruplica el conteo de píxeles. No es “un poco más.” Cuatro veces más píxeles.
Eso amplifica el trabajo de la GPU que escala con los píxeles: sombreado de fragmentos, pases de postprocesado, ciertos modos de AA, el ancho de banda para escribir objetivos de render
y el coste de efectos de alta calidad que se ejecutan por píxel.

¿Qué no escala mucho con la resolución? Gran parte del trabajo de la CPU: tick de la lógica del juego, paso de física, decisiones de IA, evaluación de grafos de animación,
decisiones de culling, recorrido del grafo de escena y la pura sobrecarga de enviar draw calls y enlaces de recursos. Esos costes están ligados a
cuántos objetos existen y cómo el motor organiza el trabajo, no a cuántos píxeles se dibujan.

A 1080p, la GPU termina rápido y luego espera

Con menos píxeles, la GPU a menudo completa su parte del fotograma más rápido, especialmente en tarjetas de gama alta. Si la CPU no puede producir
nuevo trabajo lo bastante rápido —porque un núcleo está saturado por el hilo del juego, el hilo del driver está ocupado o tareas en segundo plano roban tiempo— la GPU
se queda sin comandos y se atasca.

Eso es el “cuello de botella de la CPU.” No es místico. Es inanición. Compraste una cocina rapidísima (GPU), pero el camarero (CPU + driver)
solo trae los ingredientes de uno en uno.

A 4K, la GPU por fin tiene suficiente para masticar

A 4K, el tiempo por fotograma de la GPU aumenta de forma dramática. Muchas escenas se vuelven dependientes de la GPU porque el sombreado y el ancho de banda dominan.
La CPU sigue haciendo la misma orquestación, pero ahora la GPU es la etapa más lenta. La utilización de GPU sube hacia 95–99% y la tasa de fotogramas se alinea con
lo que esperarías de los benchmarks de GPU.

La trampa de los FPS competitivos

Los cuellos de botella de CPU más dramáticos aparecen en entornos competitivos: baja resolución, gráficos bajos, FPS sin límite, altas tasas de refresco.
Esas configuraciones reducen intencionalmente la carga de la GPU para maximizar FPS y reducir latencia—así que te empujan directamente hacia límites de CPU.

Broma #1: Comprar una GPU tope de gama para 1080p con ajustes bajos y esperar milagros es como instalar un motor a reacción en un carrito de la compra—técnicamente impresionante, operacionalmente confuso.

Qué hace realmente la CPU en un juego moderno

Si quieres entender por qué la CPU puede convertirse en cuello de botella a 1080p, deja de pensar en “la CPU” como una sola cosa. En motores reales, la carga de la CPU
se divide entre múltiples hilos con paralelismo desigual y puntos de sincronización desagradables.

1) El “hilo principal/juego” y los cuellos seriales

Muchos motores todavía tienen un hilo principal que coordina el paso de simulación: entrada, lógica de juego, scripting, IA de alto nivel y actualizaciones de escena.
Incluso en motores con sistemas de tareas robustos, ciertas restricciones de orden son inherentemente seriales: no puedes resolver ciertas interacciones físicas
hasta haber avanzado el mundo; no puedes generar objetos hasta que la lógica se ejecute; no puedes finalizar la visibilidad hasta que se actualicen las transformaciones.

Cuando la gente dice “un núcleo está al 100%,” esto suele ser a lo que se refieren. Un CPU de 16 núcleos no ayuda si el hilo limitante no se puede dividir.
Trabajadores paralelos pueden estar 20% inactivos mientras el hilo principal arde al 100% y la GPU espera educadamente.

2) Preparación del render: culling, ordenación y generación de comandos

El render moderno no es “enviar triángulos.” Es: determinar objetos visibles, elegir LODs, construir listas de render, ordenar para reducir cambios de estado,
enlazar recursos y construir buffers de comandos. Eso es trabajo de CPU.

Motores que dependen mucho de muchos draw calls pequeños pueden colapsar la CPU a 1080p porque la presentación de draw calls y la validación de estado son
costosas, especialmente en APIs gráficas antiguas o cuando el driver serializa.

3) Sobrecarga del driver y modelo de API

El driver forma parte del coste de la CPU. Cuando envías trabajo, el driver lo valida, lo traduce y puede agruparlo o reordenarlo.
Parte de esto puede paralelizarse; otra parte es tozudamente single-thread, especialmente en rutas heredadas.

DirectX 11 es notorio por una mayor sobrecarga de draw calls en muchas cargas de trabajo debido a cómo se gestiona el estado y cómo los drivers se ven obligados a hacer trabajo.
DirectX 12 y Vulkan trasladan más responsabilidad al motor, lo que puede reducir la sobrecarga si el motor los usa bien.
“Usar DX12” no es una victoria gratis. Es una oportunidad para no perder.

4) Streaming de assets y gestión de memoria

Hacer streaming de texturas y geometría también es un problema de CPU: descompresión, programación de IO, decisiones de residency y gestión de heaps.
Si ves tirones al girar rápidamente, eso puede ser tiempo de CPU gastado reaccionando a la presión del streaming, no solo “disco lento.”
(Sí, el almacenamiento importa. Pero normalmente es la CPU la que coordina el desastre.)

5) El SO: DPCs, interrupciones, servicios en segundo plano

La CPU también maneja interrupciones, planificación del kernel, pilas de audio, anti-trampas, overlays, software de captura y lo que sea que decida despertarse en el momento equivocado.
Unos cientos de microsegundos de jitter en el núcleo equivocado se convierten en un fotograma perdido a 240 Hz.

Qué cambia con la resolución (y qué no)

El coste de la GPU escala con los píxeles, pero no todo lo hace linealmente

Cuadruplicar los píxeles no siempre cuadruplica el tiempo de GPU porque las cargas de trabajo de la GPU incluyen componentes escalados por píxel y no escalados:
procesamiento de geometría, efectos compute con trabajo fijo por objeto y burbujas impuestas por la CPU en la tubería.

Pero para la mayoría de títulos modernos, 4K te empuja a un régimen donde el sombreado de píxeles, el postprocesado y el ancho de banda dominan. Ahí
la GPU se convierte en el limitador y las deficiencias de la CPU quedan enmascaradas.

El trabajo de la CPU está ligado a la “complejidad del mundo”, no a la resolución

A la CPU no le importa si renderizas la misma escena a 1080p o 4K: aún tiene que decidir qué es visible, simular los mismos NPCs y
construir el mismo número de draw calls. Si mantienes las mismas opciones gráficas y la misma escena, la carga de la CPU suele permanecer casi plana.

Por qué bajar ajustes puede hacerte “más dependiente de la CPU”

Bajar ajustes reduce el tiempo de GPU. Eso incrementa los FPS hasta que te topas con la pared de la CPU. Entonces los FPS dejan de escalar y da la sensación de que la mejora de GPU
no hizo nada. Hizo algo: eliminó los límites GPU y expuso el límite de CPU que ya existía.

El tiempo por fotograma es la única métrica que no miente

FPS es un resumen. El tiempo por fotograma es la autopsia. Si te importan los cuellos de botella, necesitas tiempo de fotograma CPU vs tiempo de fotograma GPU.
El lado limitante es el que tiene mayor tiempo por fotograma. Todo lo demás son sensaciones.

Una cita operativa que merece un post-it:
La esperanza no es una estrategia. — General Gordon R. Sullivan

Hechos y contexto histórico que explican el lío actual

• Hecho 1: El meme del “cuello de botella de CPU” se hizo más ruidoso cuando los esports en 1080p con altas tasas de refresco se popularizaron; 240 Hz hace visible el jitter de la CPU.
• Hecho 2: El modelo de contexto inmediato de DirectX 11 a menudo fuerza más trabajo del driver en la CPU; fue diseñado en una era con expectativas de threading distintas.
• Hecho 3: Los motores de consola impulsaron sistemas de tareas agresivos porque el hardware fijo lo exigía; los ports a PC a veces heredan esos patrones bien, a veces mal.
• Hecho 4: Los “límites de draw calls” solían estar en los pocos miles en APIs y drivers antiguos; hoy los motores pueden empujar mucho más, pero solo con batching y threading cuidadoso.
• Hecho 5: El aumento de postprocesados pesados en shaders (TAA, SSR, variantes de AO) hizo que 4K sea desproporcionadamente caro, desplazando los cuellos hacia la GPU.
• Hecho 6: El ancho de banda PCIe rara vez limita el render en estado estable, pero picos de subida (streaming, compilación de shaders, creación de PSO en tiempo de ejecución) pueden causar tirones que se sienten como cuello de botella de CPU.
• Hecho 7: SMT/Hyper-Threading ayuda al rendimiento total, pero muchos juegos están limitados por uno o dos hilos “calientes” donde SMT no dobla el rendimiento.
• Hecho 8: Los interruptores de “threaded optimization” del driver existen porque la sobrecarga del driver en CPU es real; también son frágiles porque cambian el scheduling y el comportamiento de bloqueo.

Guía rápida de diagnóstico

Primero: determina si estás limitado por CPU o GPU en 2 minutos

1. Cambia solo la resolución (1080p → 1440p → 4K) manteniendo los mismos ajustes.
   
   Si los FPS apenas cambian al aumentar la resolución, estás CPU-bound. Si los FPS caen notablemente con la resolución, estás GPU-bound.
2. Mira el tiempo por fotograma CPU vs GPU (no solo la utilización).
   
   Si el tiempo de CPU por fotograma > tiempo de GPU por fotograma, CPU-bound. Si el tiempo de GPU > tiempo de CPU, GPU-bound.
3. Revisa por límites y sincronización.
   
   Si estás anclado a 60/120/144/165/240, puede que estés tocando un limitador (vsync, tope de FPS, techo VRR, limitador del driver).

Segundo: identifica el limitador específico de la CPU

1. ¿Un núcleo está al 100%? Probablemente hilo principal, hilo del driver o un subsistema pesado (IA/física).
2. ¿Alto tiempo DPC/ISR? Probablemente latencia de driver/interrupciones: red, audio, almacenamiento, USB o dispositivos de captura.
3. ¿Tirones durante el recorrido? A menudo compilación de shaders, creación de PSO o coordinación del streaming de assets.

Tercero: haz el cambio más barato con mayor ROI esperado

• Activa un límite de fotogramas sensato por debajo de tu refresco para estabilizar el pacing.
• Activa el upscaler recomendado del motor a 4K en lugar de forzar nativo.
• Si tu objetivo es alto FPS en 1080p, prioriza frecuencia/IPC de la CPU y latencia de memoria, no “más GPU”.

Tareas prácticas: comandos, salidas, qué significan y la decisión

Estas son herramientas de campo. No perfectas. Pero son consistentes, scriptables y te dan pistas sólidas. El host es “server” porque soy SRE
y las costumbres mueren despacio.

Tarea 1: Verifica modelo de CPU, comportamiento de boost y disposición de núcleos

cr0x@server:~$ lscpu | egrep 'Model name|CPU\(s\)|Thread|Core|Socket|MHz'
Model name:                           AMD Ryzen 7 7800X3D 8-Core Processor
CPU(s):                               16
Thread(s) per core:                   2
Core(s) per socket:                   8
Socket(s):                            1
CPU MHz:                              4482.000

Significado de la salida: Confirma conteo de núcleos/hilos y snapshot de frecuencia actual. Si ves MHz bajos bajo carga, puedes estar limitado por energía/temperatura.

Decisión: Si las frecuencias no se están elevando, arregla refrigeración/plan de energía/límites BIOS antes de perseguir “cuellos de botella”.

Tarea 2: Revisa el gobernador de frecuencia de la CPU (Linux) o deriva de políticas

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

Significado de la salida: “schedutil” suele estar bien; “powersave” puede perjudicar la estabilidad a FPS altos.

Decisión: Para benchmarking, usa temporalmente “performance” para eliminar la variación inducida por el gobernador.

Tarea 3: Ver presión por núcleo (encuentra el hilo saturado)

cr0x@server:~$ mpstat -P ALL 1 3
Linux 6.8.0 (server) 	01/21/2026 	_x86_64_	(16 CPU)

01:10:01 PM  CPU   %usr  %nice  %sys %iowait  %irq  %soft  %steal  %idle
01:10:02 PM  all  22.10   0.00  3.10    0.10  0.00   0.30    0.00  74.40
01:10:02 PM    6  88.00   0.00  4.00    0.00  0.00   0.00    0.00   8.00
01:10:02 PM    7  12.00   0.00  2.00    0.00  0.00   0.00    0.00  86.00

Significado de la salida: Un núcleo de CPU (CPU 6) está casi saturado mientras otros no lo están. Eso es comportamiento clásico de “hilo principal” o serialización en el driver.

Decisión: Optimiza para rendimiento de hilo único: actualización de CPU, ajuste de memoria o configuraciones del motor que reduzcan trabajo en el hilo principal (distancia de vista, densidad de multitudes).

Tarea 4: Confirma que la GPU está presente y en qué stack de drivers estás

cr0x@server:~$ lspci -nn | egrep -i 'vga|3d|nvidia|amd'
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation Device [10de:2684] (rev a1)

Significado de la salida: No puedes ajustar lo que el SO no ve. Esto también ayuda a detectar “slot equivocado” y problemas raros de cableado PCIe.

Decisión: Si la GPU no está enumerada correctamente, para. Arregla hardware/BIOS/configuración PCIe antes de analizar rendimiento.

Tarea 5: Revisa ancho y velocidad de enlace PCIe (limitador silencioso común)

cr0x@server:~$ sudo lspci -s 01:00.0 -vv | egrep -i 'LnkCap|LnkSta'
LnkCap: Port #0, Speed 16GT/s, Width x16
LnkSta: Speed 16GT/s, Width x16

Significado de la salida: Quieres que LnkSta coincida con LnkCap en velocidad y ancho. x8 o Gen3 puede importar en casos extremos, especialmente con streaming intenso.

Decisión: Si ves x4 o Gen1/Gen2, vuelve a asentar la GPU, revisa el modo PCIe en BIOS y verifica que se use el slot correcto.

Tarea 6: Observa utilización y clocks de GPU (sanidad, no diagnóstico)

cr0x@server:~$ nvidia-smi --query-gpu=utilization.gpu,clocks.gr,clocks.mem,pstate,power.draw --format=csv -l 1
utilization.gpu [%], clocks.gr [MHz], clocks.mem [MHz], pstate, power.draw [W]
62 %, 2730 MHz, 10501 MHz, P0, 220.45 W
58 %, 2715 MHz, 10501 MHz, P0, 214.10 W

Significado de la salida: Utilización moderada con clocks altos puede significar CPU-bound, capado o cargas desiguales. P0 indica que no está en un estado de bajo consumo.

Decisión: Si los clocks están bajos (P2/P5) bajo carga, arregla la gestión de energía o ajustes del driver antes de perseguir cuellos de botella de CPU.

Tarea 7: Revisa fuentes de latencia en el scheduling de CPU (tormentas de interrupciones)

cr0x@server:~$ cat /proc/interrupts | head
           CPU0       CPU1       CPU2       CPU3
  0:         52          0          0          0   IO-APIC   2-edge      timer
  1:          0          0          0          0   IO-APIC   1-edge      i8042
 24:    1200345          0          0          0   PCI-MSI 65536-edge      eth0
 27:     450221          0          0          0   PCI-MSI 327680-edge      nvme0q0

Significado de la salida: Si un CPU está manejando un número ridículo de interrupciones (red, NVMe), puede robar tiempo al hilo caliente del juego.

Decisión: Considera balanceo de IRQs, desactivar dispositivos/drivers con mal comportamiento o mover cargas fuera del core que usa el juego (depende de la plataforma).

Tarea 8: Identificar si te estás bloqueando por IO (presión de streaming)

cr0x@server:~$ iostat -xz 1 3
avg-cpu:  %user   %nice %system %iowait  %steal   %idle
         21.14    0.00    3.05    0.80    0.00   74.99

Device            r/s     w/s   rkB/s   wkB/s  %util  await
nvme0n1         120.0    15.0  8200.0  1200.0   35.0   2.10

Significado de la salida: %util moderado y await bajo sugiere que el almacenamiento no es el factor limitante. Picos altos de await se correlacionan con tirones durante el recorrido.

Decisión: Si await es alto, investiga actualizaciones en segundo plano, escaneo antivirus o un SSD saturado; de lo contrario, céntrate en tiempo de fotograma CPU/GPU.

Tarea 9: Detectar throttling térmico (el “freno invisible”)

cr0x@server:~$ sensors | egrep -i 'Tctl|Package|Core|temp|fan'
Tctl:         +86.5°C
Core 0:       +84.0°C
Core 1:       +83.5°C
fan1:        1850 RPM

Significado de la salida: Temperaturas sostenidas altas pueden reducir clocks de boost, especialmente con disipadores pequeños o mala pasta térmica.

Decisión: Si las temperaturas están cerca de puntos de throttling, arregla la refrigeración primero. Afinar rendimiento en un sistema que hace throttling es solo negación organizada.

Tarea 10: Revisa velocidad de memoria y si estás corriendo un perfil “seguro”

cr0x@server:~$ sudo dmidecode -t memory | egrep -i 'Speed:|Configured Memory Speed'
Configured Memory Speed: 4800 MT/s
Speed: 6000 MT/s

Significado de la salida: Velocidad nominal de RAM vs velocidad configurada. Juegos CPU-bound a 1080p pueden ser sensibles a la latencia y ancho de banda de memoria.

Decisión: Si la velocidad configurada es baja, habilita el perfil XMP/EXPO correcto y valida estabilidad.

Tarea 11: Encuentra procesos en segundo plano que roban frametime a FPS altos

cr0x@server:~$ ps -eo pid,comm,%cpu,%mem --sort=-%cpu | head
  PID COMMAND         %CPU %MEM
 4123 game.exe        62.5  8.1
 2311 obs             12.2  3.4
 1990 chrome           6.8  2.1

Significado de la salida: Software de captura/overlay y procesos de navegador pueden introducir jitter, especialmente si generan contención GPU/CPU o se despiertan con frecuencia.

Decisión: Si procesos no relacionados con el juego consumen CPU significativa, ciérralos o mueve la captura a otra máquina si te importa la consistencia a 240 Hz.

Tarea 12: Comprueba si estás topando con un tope de fotogramas (te sorprendería)

cr0x@server:~$ grep -R "MaxFPS" -n ~/.config/game/config.ini | head
42:MaxFPS=144

Significado de la salida: Un tope forzado por configuración imitará un cuello de botella de CPU: baja utilización de GPU, techo de FPS estable.

Decisión: Quita o ajusta el tope para pruebas. Luego vuelve a aplicar un tope intencional para pacing una vez entiendas los límites.

Tarea 13: Mide stalls en el lado CPU y cambios de contexto durante muestreo en juego

cr0x@server:~$ pidof game.exe
4123

cr0x@server:~$ sudo pidstat -p 4123 -w -u 1 5
Linux 6.8.0 (server) 	01/21/2026 	_x86_64_	(16 CPU)

01:15:11 PM   UID       PID    %usr %system  %CPU   cswch/s nvcswch/s  Command
01:15:12 PM  1000      4123   58.00    4.00 62.00   1200.00    35.00  game.exe
01:15:13 PM  1000      4123   57.00    4.00 61.00   1400.00    40.00  game.exe

Significado de la salida: Altos cambios de contexto pueden implicar contención, sobrecarga de sincronización o ruido en el scheduling del SO.

Decisión: Si los cambios de contexto se disparan con tirones, reduce overlays, revisa problemas de drivers y prefiere fullscreen exclusivo cuando aplique.

Tarea 14: Verifica comportamiento de hugepages/THP (puede afectar la varianza del frametime)

cr0x@server:~$ cat /sys/kernel/mm/transparent_hugepage/enabled
[always] madvise never

Significado de la salida: Los ajustes de THP pueden influir en el comportamiento de memoria; algunas cargas ven variación en latencia.

Decisión: Si persigues micro-tirones en Linux, prueba A/B modos de THP. Cambia una cosa a la vez y registra deltas en tiempo por fotograma.

Broma #2: Los gráficos de tiempo por fotograma son como análisis de sangre—nadie los quiere, todos los necesitan, y los resultados siempre culpan a algo que no esperabas.

Tres microhistorias corporativas desde el frente

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

Un estudio tenía una build de PC que “parecía bien” a 4K en el laboratorio de la oficina. La utilización de GPU era alta, el tiempo por fotograma suave. Lanzaron un preset competitivo
orientado a 1080p/240 Hz. En días llegaron tickets de soporte: “GPU solo al 60%,” “CPU al 40%,” “tirones en peleas,” “mi GPU cara está rota.”

La suposición era simple y equivocada: “Si la utilización global de CPU es baja, no puede ser el cuello de botella.” Leían el promedio entre
16 núcleos y declaraban victoria. El hilo principal estaba saturando un núcleo, y el hilo de envío de render se bloqueaba periódicamente en un lock
en la ruta del driver cuando muchos objetos pequeños entraban en vista.

Su plan de pruebas interno no incluía “ajustes bajos + FPS sin límite + alta refresco” porque la cultura del laboratorio era cinematográfica: probar a 4K, ajustes máximos,
admirar la iluminación, shippear. Los clientes reales intentaban eliminar cada milisegundo de latencia y exponían el peor comportamiento de CPU.

La solución no fue un parche mágico. Reducieron el conteo de draw calls fusionando ciertos props, mejoraron el batching de instancias y movieron parte del trabajo de visibilidad
a un sistema de tareas para reducir picos en el hilo principal. También cambiaron su telemetría para capturar tiempo por hilo y duración de envío al driver.
Los tickets de soporte bajaron porque el software cambió y porque su explicación finalmente coincidió con la realidad.

Microhistoria 2: La optimización que salió mal

Una gran empresa ejecutaba software de visualización interna en escritorios con GPUs potentes. Un equipo “optimizó” el tiempo de arranque cacheando shaders compilados
agresivamente y precargando grandes assets al iniciar sesión. El arranque se hizo más rápido—en sus máquinas de prueba.

Luego vino el problema: a 1080p, los usuarios se quejaron de tirones aleatorios al mover la cámara que antes no existían. Los gráficos de GPU parecían aburridos.
La CPU hacía picos en ráfagas y los tirones se alineaban con churn de residency de assets. Su cache aumentó la huella de memoria; el SO empezó a expulsar
y paginar más agresivamente en máquinas con menos RAM. Cada movimiento de cámara desencadenaba una cascada de trabajo de streaming “útil” que robaba tiempo de CPU
al hilo de preparación de render.

La optimización era correcta en aislamiento y equivocada en el contexto de producción. Trataron la memoria como un pool infinito e ignoraron que muchos usuarios
ejecutaban otras apps pesadas concurrentemente. Realidad corporativa clásica: alguien siempre tiene veinte pestañas del navegador abiertas, y sí, son “trabajo.”

La solución eventual fue aburrida y efectiva: limitar el tamaño del caché, priorizar assets por reutilización prevista y añadir backpressure para que el trabajo de streaming ceda
cuando el presupuesto de fotograma está justo. También añadieron un “modo baja latencia” que reduce la agresividad del streaming en segundo plano cuando los usuarios piden altos FPS.

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

Otro equipo mantenía una flota de estaciones de trabajo para simulación y demos tipo juego en ferias. Tenían una regla: cada actualización de driver
debía pasar por una pool canaria con un conjunto de benchmarks repetibles en tres resoluciones (1080p competitivo, 1440p equilibrado, 4K de escaparate).

Era profundamente poco glamoroso. La gente se quejaba de que ralentizaba la “innovación.” Pero el equipo mantenía logs: utilización por núcleo de CPU, clocks de GPU, estado del enlace PCIe,
percentiles de frametime y una captura corta de interrupciones del sistema. Mismos scripts, mismas máquinas, mismo procedimiento. Sin heroísmos.

Un mes, una actualización de driver mejoró ligeramente el rendimiento a 4K pero introdujo picos esporádicos del lado CPU a 1080p en una ruta de aplicación. La suite canaria
lo detectó inmediatamente: el percentil 99 de tiempo por fotograma saltó, la utilización de GPU cayó y los cambios de contexto del hilo de envío se duplicaron. Retuvieron la actualización
y presentaron un informe al proveedor con evidencia que no dependía de sensaciones.

La semana de la feria pasó sin vergüenza. La “práctica aburrida” no era sobre ganar rendimiento; era sobre prevenir regresiones que solo aparecen en regímenes dependientes de CPU.
Los usuarios nunca supieron lo que no ocurrió, que es el mayor elogio que recibe operaciones.

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

1) “La utilización de GPU es baja, así que mi GPU está mala”

Síntomas: 50–70% de utilización de GPU a 1080p, FPS se estancan, un núcleo de CPU cerca del 100%.

Causa raíz: CPU-bound (hilo principal o sobrecarga del driver). La GPU espera trabajo.

Solución: Aumenta la resolución o activa características GPU más pesadas para confirmar escalado; reduce ajustes pesados para la CPU (distancia de visión, multitudes); actualiza CPU/RAM si quieres más FPS.

2) “Mi CPU solo está al 35%, así que no puede ser el límite”

Síntomas: El uso global de CPU parece bien, pero el tiempo por fotograma es inconsistente; GPU no totalmente usada.

Causa raíz: Un hilo caliente está saturado; los promedios ocultan saturación por núcleo.

Solución: Inspecciona uso por núcleo; encuentra el hilo limitante; optimiza para rendimiento de hilo único y reduce fuentes de contención.

3) “Bajar ajustes siempre debería aumentar FPS”

Síntomas: Bajar ajustes no hace nada a 1080p; FPS sin cambios y utilización de GPU baja.

Causa raíz: Ya estabas limitado por CPU. Bajar ajustes eliminó trabajo de GPU pero no cambió el trabajo de CPU.

Solución: Si necesitas más FPS, trátalo como un problema de CPU: ajuste de memoria, actualización de CPU, opciones del motor que reduzcan carga de CPU, o acepta un tope.

4) “El stutter debe ser mi SSD”

Síntomas: Tirones aleatorios, especialmente al girar; el SSD “es rápido sobre el papel”.

Causa raíz: A menudo compilación de shaders del lado CPU, creación de PSO o coordinación de streaming; a veces el antivirus escanea el directorio del juego.

Solución: Revisa IO await; revisa tareas en segundo plano; precompila shaders si es posible; excluye directorios del juego del escaneo en tiempo real cuando proceda.

5) “Un driver nuevo redujo mis FPS, debe ser la GPU”

Síntomas: 4K sin cambios, 1080p peor; aumentan saltos de frametime; clocks de GPU normales.

Causa raíz: Regresión en sobrecarga del driver del lado CPU o comportamiento distinto de scheduling/bloqueos.

Solución: Reviértelo y compara con corridas de prueba consistentes; mantén un proceso canario; reporta con tiempo por fotograma y evidencia por núcleo, no capturas de pantalla de utilización.

6) “La velocidad de enlace PCIe no importa”

Síntomas: FPS promedio bien, peores 1% lows; tirones durante streaming intenso; rendimiento extraño tras cambios de hardware.

Causa raíz: GPU funcionando a x4/x8 inesperadamente, o negociada a una generación inferior por BIOS/slot/cable/riser defectuoso.

Solución: Verifica ancho/velocidad del enlace; vuelve a asentar la GPU; evita risers cuestionables; establece modo PCIe explícito si la autonegociación falla.

7) “FPS ilimitados siempre son mejores”

Síntomas: Alto promedio de FPS pero mal pacing; entrada inconsistente; sistema muy caliente.

Causa raíz: La CPU trabaja a tope; el jitter en segundo plano se hace visible; el comportamiento de la cola de render puede empeorar la latencia.

Solución: Usa un tope de fotogramas ligeramente por debajo del refresco; ajusta para un percentil 99 estable de tiempo por fotograma, no para el pico de FPS.

Listas de verificación / plan paso a paso

Paso a paso: prueba y demuestra el cuello de botella (no adivines)

1. Desactiva topes temporalmente: Apaga vsync, quita topes de FPS, asegúrate de que VRR no te esté acotando.
2. Ejecuta una escena repetible: Mismo mapa, misma trayectoria de cámara, misma duración.
3. Prueba 1080p → 1440p → 4K: Mantén ajustes idénticos. Registra FPS y 1% lows.
4. Registra tiempos por fotograma: Captura tiempo por fotograma CPU y GPU si tus herramientas lo permiten.
5. Revisa CPU por núcleo: Busca un hilo caliente saturado.
6. Sanity-check térmico: Asegura que no haya throttling y clocks estables.
7. Sanity-check enlace PCIe: Confirma x16 y la generación esperada.

Paso a paso: si estás CPU-bound a 1080p y quieres más FPS

1. Prioriza IPC y boost de CPU: Alto rendimiento por hilo único vence a más núcleos pasado cierto punto.
2. Arregla configuración de memoria: Asegura que XMP/EXPO esté habilitado y estable; evita kits mezclados.
3. Reduce ajustes pesados para la CPU: Distancia de vista, densidad de multitudes, detalle de física, sombras (algún trabajo de sombras es lado CPU), opciones de tick de simulación.
4. Reduce presión de draw calls: Ajustes en juego que reduzcan densidad de objetos o follaje ayudan.
5. Capea FPS intencionalmente: Fija un límite que puedas sostener con buenos 1% lows. Un 180 estable vence a un 240 irregular.
6. Elimina fuentes de jitter: Overlays, captura, software RGB, reproducción de vídeo en navegador—todo lo que se despierte con frecuencia.

Paso a paso: si estás GPU-bound a 4K y quieres mejores visuales o FPS más estables

1. Usa upscaling: Prefiere modos DLSS/FSR/XeSS que preserven detalle sin forzar nativo.
2. Ataca los pases caros: Ray tracing, AO pesado, sombras ultra y reflexiones de alta calidad suelen dominar.
3. Vigila uso de VRAM: Sobrepasar VRAM puede causar hitching y paging.
4. Prioriza tiempos de fotograma consistentes: Afina para el percentil 99 reduciendo los ajustes que generan picos, no solo la carga promedio.

Preguntas frecuentes (FAQ)

1) ¿“Cuello de botella de CPU” es lo mismo que “mi CPU es muy lenta”?

No siempre. Puede ser “CPU demasiado lenta”, pero también puede ser sobrecarga del driver, un punto de estrangulamiento de hilo único o jitter del SO. El síntoma es la inanición de la GPU.

2) ¿Por qué mi mejora de GPU ayuda a 4K pero no a 1080p?

4K incrementa el trabajo por fotograma de la GPU lo suficiente como para que la GPU sea la etapa más lenta. A 1080p, la GPU termina rápido y espera a que la CPU la alimente.

3) Si estoy CPU-bound, ¿debería aumentar ajustes gráficos?

Si estás CPU-bound y ya estás satisfecho con los FPS, sí: aumentar carga GPU puede mejorar la calidad de imagen “gratis” porque la CPU estaba limitando de todas formas.
Si tu objetivo es máximo FPS, subir ajustes no ayudará.

4) ¿Por qué bajar resolución a veces reduce el stutter?

Puede reducir la presión en GPU y el ancho de banda de VRAM, lo que alise picos dependientes de GPU. Pero si el stutter viene del lado CPU (compilación de shaders, streaming), cambiar resolución puede no solucionarlo.

5) ¿Más núcleos de CPU arreglan cuellos a 1080p?

A veces, pero no de forma fiable. Muchos juegos se limitan en uno o dos hilos calientes. Quieres buen rendimiento por hilo y baja latencia de memoria, no solo más núcleos.

6) ¿DX12/Vulkan siempre mejoran los cuellos de CPU?

No. Pueden reducir sobrecarga si el motor los usa bien, pero también trasladan responsabilidad al juego. Algunos títulos funcionan mejor en DX11 por madurez y rutas de driver.

7) ¿Por qué mi uso de CPU es bajo pero los FPS siguen capados?

Porque los promedios ocultan hilos calientes y porque puedes estar tocando un limitador explícito: vsync, tope en el juego, tope del driver o un techo VRR. También revisa throttling térmico.

8) ¿Cuál es la prueba más rápida para confirmar CPU vs GPU bound?

Aumenta la resolución manteniendo ajustes constantes. Si los FPS se mantienen casi iguales, estás CPU-bound. Si los FPS caen, estás GPU-bound.

9) ¿RAM más rápida y timings más apretados realmente importan?

En escenarios CPU-bound de FPS altos, sí pueden. La latencia de memoria afecta la rapidez con que los hilos calientes atraviesan el estado del juego, construyen buffers de comandos y manejan datos de draw calls.
No es magia, pero es medible.

10) ¿Debería capear FPS incluso si quiero baja latencia?

A menudo sí. Un tope inteligente (ligeramente por debajo del refresco) puede reducir colas, estabilizar tiempos por fotograma y bajar térmicas de la CPU. El resultado puede sentirse más responsivo que el caos sin límite.

Conclusión: próximos pasos que realmente funcionan

Las CPUs estrangulan a las GPUs a 1080p porque el trabajo por fotograma de la GPU se reduce mientras que el trabajo de orquestación de la CPU se mantiene mayormente igual. A 4K, el coste por píxel explota,
la GPU se convierte en la etapa lenta y los pecados de la CPU quedan ocultos tras una pared de sombreado y ancho de banda.

Haz lo disciplinado:

• Demuestra si estás CPU-bound o GPU-bound con escalado de resolución y tiempos por fotograma.
• Si estás CPU-bound a 1080p y buscas más FPS, invierte en boost/IPC de CPU, configuración de memoria y ajustes pesados en CPU—no en otra GPU.
• Si estás GPU-bound a 4K, evita forzar nativo cuando un buen upscaler te da margen con menos compromisos.
• Adopta una rutina aburrida y repetible de benchmarking. Previene regresiones de rendimiento y te salva de discutir con gráficas de utilización.