El juego marca más de noventa FPS, pero se detiene un instante al girar o entrar en otra zona. El promedio no ha fallado: responde a una pregunta general, cuántos fotogramas se produjeron en ese intervalo. Para saber si llegan a un ritmo uniforme hay que mirar su distribución temporal.
Empieza por el tiempo de fotograma y decide después qué medir. Un porcentaje de cuello de botella o una caída aislada del uso de GPU no indican qué componente cambiar.
Un fotograma largo puede ocultarse en un buen promedio
Con salida idealmente uniforme, el intervalo en milisegundos es aproximadamente 1.000 ÷ FPS. Así, 60 FPS son unos 16,67 ms y 120 FPS unos 8,33 ms. Es una conversión temporal, no un resultado de un PC.
Supongamos 100 fotogramas: 99 de 10 ms y uno de 100 ms. El total es 99 × 10 + 100 = 1.090 ms. Dividir fotogramas por duración da unos 91,74 FPS. El promedio parece bueno, pero sigue habiendo una espera mucho más larga.
Figura: cálculo sintético y procedimiento de revisión; no es una captura de una prueba de juego.
La media aritmética del FPS instantáneo por fotograma tampoco equivale a dividir fotogramas totales por tiempo total. Ventana de muestreo, inclusión de cargas y definición estadística cambian la cifra.
Otra medida intuitiva es cuánto tiempo ocupan los fotogramas lentos. En 60 segundos hipotéticos con seis fotogramas de 100 ms, esos seis ocupan 0,6 segundos, el 1% del intervalo. Sigue siendo un cálculo artificial, pero conserva pausas escasas que un percentil puede omitir.
Figura: 100 fotogramas sintéticos. El eje horizontal es el índice, no tiempo equidistante. El fotograma 50 dura 100 ms; los otros 99, 10 ms cada uno.
Averigua qué fotogramas registra la herramienta
La página oficial de NVIDIA FrameView describe registro de FPS, tiempos y potencia, con archivos de resultados.[1] Ayuda a conservar datos del evento, pero la herramienta sola no demuestra «es un cuello de botella de CPU».
Antes de comparar informes, revisa fotogramas renderizados o mostrados, generación de fotogramas, sincronización vertical y límite. Mezclar generados y renderizados base puede aumentar el número sin mejorar proporcionalmente la respuesta. Algunos problemas de visualización quedan fuera del registro de renderizado; una gráfica estable no descarta todos los tirones visibles.
«1% low» ayuda a observar el rendimiento bajo, pero los programas pueden calcularlo de formas distintas. Conserva herramienta, versión, definición y duración. No lo equipares al fotograma más lento ni mezcles herramientas en una clasificación.
CapFrameX distingue expresamente percentiles ordenados por fotogramas y duración.[3] «El 99% de fotogramas supera un umbral» no equivale estrictamente a «el 99% del tiempo es fluido»: unos pocos lentos pueden ocupar mucho tiempo. También distingue percentiles y resúmenes de la fracción más lenta. Si solo aparece «1% low» sin algoritmo, conserva esa limitación.
Qué campos conviene leer juntos
Abre el CSV y verifica primero los encabezados. La documentación de consola de PresentMon define estos campos; la salida real depende de versión y opciones.[2]
| Campo | Significado documentado | Qué ayuda a investigar |
|---|---|---|
MsBetweenPresents |
Intervalo entre llamadas Present consecutivas | Si se alarga de golpe el ritmo de envío |
MsCPUBusy |
Trabajo de CPU antes de enviar este fotograma | Cambios del trabajo de CPU junto al fotograma largo |
MsGPUBusy |
Trabajo activo de GPU para este fotograma del proceso | Si la carga gráfica aumenta con la escena |
DisplayLatency |
Tiempo desde el inicio hasta mostrar el fotograma | Esperas en la ruta de visualización |
DisplayedTime |
Duración visible; puede ser NA si no se muestra | Si permanece demasiado en pantalla |
Son intervalos distintos y CPU y GPU pueden trabajar en paralelo. No sumes columnas exigiendo que igualen la duración total. MsGPUBusy tampoco es el porcentaje de uso del Administrador de tareas. Lee las definiciones antes de comparar cifras.
Si aumenta el intervalo de envío junto con el tiempo activo de GPU, merece revisarse el trabajo gráfico. Con GPU breve y espera larga pueden intervenir límite, suministro de CPU o planificación. Esto acota la búsqueda, no prueba insuficiencia de CPU. La documentación también recoge limitaciones según API y planificación de hardware; no alteres campos ausentes o limitados.[4]
Conserva pruebas con una ruta corta repetible
Elige una ruta repetible y fija resolución, calidad, movimiento de cámara y límite. Guarda los ajustes iniciales, registra y conserva el archivo. Etiqueta versión del juego, controlador, escena y configuración para comparar después.
Anota si el pico coincide con primera entrada, giro brusco, inicio de una aplicación de fondo o cada paso por el mismo punto. Mira conjuntamente métricas disponibles de CPU, GPU, memoria y almacenamiento. No rellenes con cero sensores no capturados.
Repite primero tres veces y guarda cada resultado. Si varían mucho, revisa escena, temperatura, caché y tareas de fondo antes de ampliar las pruebas. Elegir solo la mejor elimina la variación que necesitas explicar.
Esta es una plantilla inicial. Los 60 segundos y tres repeticiones son ilustrativos, no suficientes por garantía para todos los juegos.
| Registro | Ejemplo |
|---|---|
| Fragmento | Partir de una partida guardada fija y recorrer la misma ruta 60 segundos |
| Arranque en frío | Conservar aparte la primera entrada |
| Repeticiones | Tres pasadas iguales, CSV separados |
| Exclusiones | Decidir antes si cuentan menús y cargas |
| Variable | Bajar solo sombras, mantener lo demás |
Compara por separado arranque en frío y escenas ya recorridas. El tirón inicial también merece registro. Para carga sostenida, no mezcles primeras cargas en un grupo y ejecuciones precalentadas en otro.
PresentMon permite seleccionar proceso por nombre, duración y archivo CSV.[2] Con interfaz o consola, confirma el proceso para no mezclar lanzador y juego. Aquí no se capturó una partida real; las imágenes ilustran métricas.
Cambia una condición cada vez
Si sospechas carga gráfica, reduce una carga de renderizado concreta y repite. Si sospechas interferencia de fondo, cierra una aplicación conocida y prueba de nuevo. No cambies a la vez controlador, calidad, límite y reinicio: no sabrás qué produjo la mejora.
Si bajar calidad eleva el promedio pero el pico permanece, carga media y ese tirón pueden ser problemas distintos. Un tirón de primera pasada que mejora después puede relacionarse con recursos o caché, pero no basta para identificar la causa. Uso bajo de GPU también puede significar límite, espera de CPU u otras restricciones, no falta directa de potencia gráfica.
Guarda conclusiones ligadas a condiciones: «Las tres pasadas tuvieron un pico al entrar en la zona, incluso bajando sombras», en vez de «el PC tiene 30% de cuello de botella». La siguiente prueba podrá revisar ese punto y el cambio de sombras sin volver a adivinar desde cero.
Referencias
-
NVIDIA FrameView. Funciones de FPS, tiempo y registros; no implica prueba realizada, potencia comparable en todas las GPU ni software instalado.
-
PresentMon Console Application. Instantánea de main leída el 2026-09-27. Campos CSV, proceso y duración; cambian por versión y no implican captura local.
-
CapFrameX: Explanation of different performance metrics. Taxxor, 2020-05-31. Percentiles frente a x% low. Se usan conceptos, no una interfaz antigua como captura actual.
-
PresentMon: documentación y limitaciones. Verificado el 2026-09-27. API y planificación pueden afectar a la medición; registra el entorno, sin deducir directamente un cuello de botella.
