Cargas de CPU y GPU
En esta página
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.
Actualmente se aplican el motor 0.5.2 y la carga phase4.6-dev-1. La versión hay que tenerla en cuenta: el cambio de escenario hace que los resultados de distintas versiones sean directamente incomparables.
CPU: simulación de objetos
Sección titulada «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 el número de núcleos físicos es desconocido, 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 hilo 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 de la ejecución 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
Sección titulada «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 escena de 9 216 instancias y 2 pasadas de posprocesado | El procesamiento de geometría y la entrega de trabajo gráfico |
| Shader | 1 dibujado de 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 canalización gráfica fija | El trabajo conjunto de CPU, controlador y GPU |
Son escenarios separados con distinto volumen de trabajo. Por ejemplo, 8 000 fotogramas condicionales de Compute no se pueden leer como 8 000 FPS en un juego ni comparar directamente con 800 fotogramas de Geometry. Para unificarlos se aplica la normalización por escenario, descrita en el cálculo de puntuaciones.
Las cargas están escritas sobre un nivel de capacidades portátil: 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.
Tras las mediciones, el motor comprueba la salida de cada carga de GPU: para Geometry, Shader, Compute, Combined y la prueba de latencia cargada se ha fijado una firma de control —el aspecto esperado de un pequeño fragmento del resultado. El fragmento leído tras la finalización se compara con el esperado; una discrepancia significa que la carga se ejecutó incorrectamente y hace que la ejecución no sea válida. La comprobación se realiza después de las mediciones válidas y no influye en los propios números.
En este conjunto no hay pruebas separadas de velocidad de disco ni de ancho de banda de 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
Sección titulada «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 se pueden consultar como diagnóstico adicional, pero el indicador final sigue siendo esa media.
Por qué la baja resolución no aligera la prueba principal
Sección titulada «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 práctica con 1920×1080, 1280×768 y 800×600 se presenta en el artículo sobre la repetibilidad.
Verificado para la implementación descrita: 2026-09-20.