Medición de latencias y PresentMon

PCBenchmarkX mide por separado la latencia interna de procesamiento y la latencia de salida del fotograma. Estas métricas de software no describen todo el recorrido desde el clic del ratón hasta el encendido del píxel en la pantalla. El ciclo de medición completo se describe en la metodología.

Estímulo de software propio

El flujo constante genera señales con intervalos deterministas de 8-12 ms. Si Windows lo permite, crea un temporizador de espera de alta precisión; en caso contrario, usa un temporizador de espera normal. La espera del evento prescinde de un sondeo continuo, que ocuparía el núcleo. La resolución global del temporizador del sistema no cambia con esto.

Para cada señal se registran el plazo planificado, el despertar del generador, la señal real, el despertar del receptor, la simulación, el envío de comandos, los timestamps de GPU y los eventos de presentación. Un identificador común de fotograma vincula todas las etapas.

Plazo planificado → despertar del generador → señal
                                            ↓
                               despertar del receptor
                                            ↓
                                CPU → comandos → GPU
                                            ↓
                            Present → evento de salida

En estas cintas se ven por separado tanto el retraso del temporizador como la latencia del despertar del receptor. El inicio de Core Latency es la señal real, por lo que el paso del plazo planificado a la señal no se cuenta en esta métrica.

Desglose por etapas del recorrido de latencia

El resultado contiene un desglose por etapas del recorrido medido latency_path — por separado para Baseline y Loaded. Las etapas se cuentan desde la señal real:

Etapa	Qué mide
signal_to_consumer_wake	de la señal al despertar del receptor
cpu_processing	el procesamiento de CPU: la simulación y la preparación de datos del fotograma
cpu_end_to_submit_start	la pausa desde el final del trabajo de CPU hasta el inicio de la preparación del envío
workload_submit_cpu_span	la preparación y el registro de comandos de la API gráfica
submit_start_to_gpu_begin	desde el inicio de la preparación hasta el inicio del trabajo de GPU; no es la latencia pura de la cola
gpu_execution	la ejecución misma del trabajo de GPU, en ciclos de GPU
presentation spans	la presentación: la envoltura Present y los intervalos desde la señal y desde el final del trabajo de GPU hasta ScreenTime

Cada etapa se da como una distribución con estadísticas y percentiles. Los segmentos se calculan para cada par de marcas por separado, y no restando dos medianas. Si la marca final de una etapa falta o no es fiable, su distribución queda vacía: no hay valores sustitutos. El retraso del temporizador (la discrepancia entre el plazo planificado y la señal real) se registra como un diagnóstico aparte antes de la señal y no entra en los valores totales del recorrido.

QPC y GPU timestamps propios

El tiempo de CPU se registra mediante QueryPerformanceCounter. Para la GPU, el motor coloca dos timestamp query alrededor del trabajo medido, obtiene la frecuencia de la cola mediante GetTimestampFrequency y convierte la diferencia de ciclos a milisegundos:

GPU work, ms = (GPU_end − GPU_begin) × 1000 / GPU_frequency

Según la documentación de Microsoft sobre D3D12 timing, timestamp query refleja el avance del trabajo hasta el final de la canalización, y los contadores de GPU y CPU se vinculan mediante GetClockCalibration.

El par de calibración GPU/QPC permite expresar la finalización del trabajo de GPU en la misma escala temporal que la señal:

GPU_completion_QPC = calibration_QPC +
  (GPU_end − calibration_GPU) × QPC_frequency / GPU_frequency

Core Latency, ms =
  (GPU_completion_QPC − signal_QPC) × 1000 / QPC_frequency

La precisión de esta estimación depende en gran medida de cuán exactamente se correspondan los relojes de CPU y GPU. Aun así, no cubre el recorrido USB del ratón, el tiempo de escaneo de la matriz ni la respuesta del píxel. Microsoft describe aparte los matices de las marcas QPC de alta precisión.

Baseline y Loaded

Baseline mide la latencia en la configuración mínima de esta carga. Loaded trabaja con una carga de GPU calibrada a 8,333333 ms, es decir, a un presupuesto de cómputo de aproximadamente 120 Hz. El monitor físico puede tener otra frecuencia.

La calibración modifica la complejidad dentro del shader en el rango 1-4096. El número de pasadas permanece fijo: cuatro posprocesados. Primero se ajusta el rango en torno al tiempo objetivo, luego se refina y se verifica la configuración elegida. Para ocupar el mismo tiempo en una tarjeta gráfica rápida, se necesita un trabajo más complejo.

En Performance el volumen de trabajo es fijo. En Loaded Latency la carga se calibra para que el tiempo de trabajo de GPU sea similar en distintas tarjetas gráficas. Las marcas temporales obtenidas no se normalizan tras la medición.

La salida de fotogramas de la prueba de latencia va por un recorrido de presentación aparte: ventana sin bordes en modo flip-discard, latencia máxima de fotograma (maximum frame latency) 1, objeto DXGI de espera y tearing, si el sistema lo admite. Este recorrido está separado de la carga fija de rendimiento, que se ejecuta fuera del búfer de pantalla y no provoca Present.

El papel de PresentMon

Para los eventos de presentación se usa la biblioteca PresentMon 2.5.1. Es un proyecto ETW de análisis de eventos gráficos en Windows, descrito por sus autores. Procmon / Process Monitor no se emplea en este conducto de medición.

PCBenchmarkX levanta su propia sesión de recopilación, filtra los eventos de su proceso y vincula los fotogramas con las señales de software. Para esto no se necesita un servicio aparte ni el lanzamiento manual de un PresentMon separado.

Se guardan intervalos adicionales:

• de la señal a Present;
• de Present a ScreenTime;
• de la señal a ScreenTime.

ScreenTime es un evento de software de presentación del fotograma; no se usa un fotodiodo para medir la luz de la pantalla. Las métricas de presentación no entran en PC Score; lo que sí entra se describe en el cálculo de puntuaciones. Levantar la sesión ETW puede requerir ejecutar como administrador o pertenecer al grupo «Usuarios del registro de rendimiento». Si no se pudo levantar la sesión, no habrá bloque de este diagnóstico, y el fallo se registra explícitamente en el resultado. La ausencia de datos no equivale a latencia cero.

El tiempo de GPU de PresentMon también se almacena por separado del tiempo propio de D3D12. Los desarrolladores de PresentMon señalan las limitaciones de precisión de las métricas de GPU con HAGS. Por eso el motor no sustituye los GPU timestamps propios por una estimación de ETW.

Qué se ha desarrollado en PCBenchmarkX

En PCBenchmarkX se han desarrollado el generador de señales, la correspondencia de etapas del fotograma, la simulación de CPU, las cargas de D3D12, la calibración de Loaded, el orden de los bloques repetidos, la recopilación de mediciones, el procesamiento estadístico y el modelo de puntuaciones. QPC y D3D12 los proporciona Windows. Para la recopilación de eventos gráficos mediante ETW se usa el proyecto abierto PresentMon.

Los datos técnicos y las fuentes externas se verificaron el 2026-09-20 para el motor 0.5.2.