Cargas de CPU y GPU

PCBenchmarkX ejecuta sus cargas sintéticas con un volumen de trabajo fijo en cada repetición, por lo que se pueden comparar entre distintas sistemas. En tales pruebas no se usan grabaciones de juego, y las cifras finales no equivalen a «FPS en un juego concreto». El ciclo de medición completo se describe en la metodología.

La descripción corresponde al motor 0.8.0. Entre versiones cambió la ejecución de los escenarios de GPU, por lo que las mediciones antiguas no pueden considerarse equivalentes a las nuevas solo tras recalcular los puntos. Para comprobar el controlador o el overclocking, use una misma versión del motor.

CPU: simulación de objetos

En el bloque de CPU se crean 65 536 objetos con coordenadas, velocidades y flags. En cada paso se recalculan el movimiento, los rebotes en los bordes y la visibilidad. El hilo principal primero procesa 8 192 objetos seguidos, luego pasa la parte restante a los hilos de trabajo y en paralelo realiza la preparación. Después los hilos se sincronizan.

El número de hilos de trabajo se elige según la regla:

workers = clamp(physical_cores − 1, 1, 6)

Si se desconoce el número de núcleos físicos, se toma una estimación por los procesadores lógicos. Los núcleos para los hilos no se fijan manualmente. Este enfoque imita el modelo de «un líder» con ayuda limitada, y no una ejecución totalmente paralelizada en cada núcleo.

El estado y el orden de recorrido de los objetos son deterministas. Antes de cada medición de la sección de CPU, este se restablece y ejecuta 512 fotogramas preparatorios fuera de la cuenta, para no arrastrar a la serie el estado residual del intento anterior.

El determinismo de la carga no significa un tiempo de ejecución idéntico: las frecuencias, la temperatura, el planificador y los procesos en segundo plano siguen influyendo en la medición.

Tres cargas de GPU

La parte de GPU funciona a través de Direct3D 12. Las texturas de trabajo internas tienen un tamaño fijo de 1920×1080, independientemente del tamaño de la ventana y del escritorio.

Carga	Trabajo de cómputo	Qué ayuda a distinguir
Geometry	6 dibujados de la escena por 9 216 instancias y 2 pasadas de posprocesado	El procesamiento de geometría y el suministro de trabajo gráfico
Shader	1 dibujado de la escena, 16 pasadas de posprocesado, parámetro de complejidad del shader 24	La carga de píxeles y de texturas
Compute	Rejilla 1920×1080, grupos 8×8, cálculos enteros con 96 iteraciones	La ejecución del shader de cómputo
Combined	Simulación de CPU y canal gráfico fijo	El trabajo conjunto de CPU, controlador y GPU

Estos son escenarios separados con distinto volumen de trabajo. Por ejemplo, 8 000 fotogramas condicionales de Compute no pueden leerse como 8 000 FPS en un juego ni compararse directamente con 800 fotogramas de Geometry. Para unificarlos se aplica la normalización por escenario, descrita en el cálculo de puntos.

Las cargas están escritas en un nivel de capacidades portable: shader model 5.0 y feature level 11_0 sin extensiones de proveedor. El mismo código se ejecuta en distintas generaciones y fabricantes de tarjetas gráficas, sin una rama separada para un proveedor concreto.

La corrección de la ejecución de la carga se comprueba aparte de la velocidad. En caso de error, guíese por el mensaje del programa y repita la prueba tras eliminar la causa.

En este conjunto no hay pruebas separadas de velocidad del disco ni de ancho de banda de la RAM. La memoria y el controlador influyen en la ejecución de las cargas, sin embargo el benchmark no calcula evaluaciones separadas de SSD y RAM.

Repetición de bloques

Las cinco cargas de rendimiento se ejecutan en tres rondas con reordenación:

Ronda	Orden
1	CPU → Geometry → Shader → Compute → Combined
2	Shader → Compute → Combined → CPU → Geometry
3	Combined → CPU → Geometry → Shader → Compute

El lugar de cada carga en la secuencia cambia de una ronda a otra. Esto reduce su influencia en la comparación. El calentamiento todavía puede alterar los resultados, por lo que para los bloques se guardan además la dispersión de la velocidad de ejecución y su cambio del primer bloque al último.

Para evaluar un escenario se toma la media aritmética del throughput de sus tres bloques. La mediana y la media geométrica de los bloques pueden consultarse como diagnóstico adicional, pero el indicador final sigue siendo esa media.

Por qué la baja resolución no aligera la prueba principal

Las cargas de CPU, GPU y Combined se ejecutan fuera del búfer de pantalla. Su ruta de envío de comandos no provoca Present ni espera la limitación de la cola de presentación. Las texturas internas siguen siendo 1920×1080, incluso si el escritorio está cambiado a 800×600.

La interfaz y la prueba de latencia funcionan a través de una ruta de salida separada. Por eso, cambiar la resolución del escritorio por sí solo no aligera la carga en sí. Sin embargo, tampoco se puede leer un resultado «absolutamente idéntico» en cualquier resolución: en el tramo de salida participan el controlador y el estado actual del sistema.

La comprobación de archivo de la versión 0.5.2 con 1920×1080, 1280×768 y 800×600 se presenta en el artículo sobre repetibilidad. No sustituye a una nueva serie tras el cambio de los escenarios de GPU.

Controladores y comparación de tarjetas gráficas

Geometry, Shader y Compute comprueban distintas rutas de ejecución. Una tarjeta gráfica puede ser más rápida en un escenario y más lenta en otro. La versión del controlador, las frecuencias, los límites de potencia y el suministro de comandos pueden cambiar el resultado. Un Compute distinto no basta para atribuir la diferencia solo al controlador. Compare varias repeticiones, la versión del motor y cada escenario por separado.

Reducir la resolución del escritorio no reduce la rejilla de trabajo de Compute. Esta prueba usa su propio shader de cómputo, y no los FPS de visualización de la ventana. El peso de Compute en el GPU Score base es del 10%; los detalles se presentan en la fórmula.

Comprobado para la implementación descrita: 2026-10-02.