Charges CPU et GPU

PCBenchmarkX lance ses charges synthétiques avec un volume de travail fixe à chaque répétition, ce qui permet de les comparer entre différents systèmes. Ces tests n’utilisent pas de captures de jeu, et les chiffres finaux ne sont pas égaux aux « FPS dans un jeu précis ». Le cycle de mesure complet est décrit dans la méthodologie.

La description se rapporte au moteur 0.8.0. Entre les versions, l’exécution des scénarios GPU a changé, c’est pourquoi les anciennes mesures ne peuvent pas être considérées comme équivalentes aux nouvelles après un simple recalcul des points. Pour vérifier un pilote ou un overclocking, utilisez une seule version du moteur.

CPU : simulation d’objets

Dans le bloc CPU, 65 536 objets sont créés avec des coordonnées, des vitesses et des indicateurs. À chaque étape, le mouvement, les rebonds sur les bords et la visibilité sont recalculés. Le thread principal traite d’abord 8 192 objets d’affilée, puis transmet la partie restante aux threads de travail et effectue en parallèle la préparation. Ensuite, les threads sont synchronisés.

Le nombre de threads de travail est choisi selon la règle :

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

Si le nombre de cœurs physiques est inconnu, une estimation basée sur les processeurs logiques est utilisée. Les cœurs pour les threads ne sont pas fixés manuellement. Cette approche imite le modèle d’un thread « meneur » unique avec une aide limitée, et non une exécution totalement parallélisée sur chaque cœur.

L’état et l’ordre de parcours des objets sont déterministes. Avant chaque mesure de la section CPU, il est réinitialisé et exécute 512 images préparatoires hors évaluation, afin de ne pas entraîner dans la série un état résiduel de l’exécution précédente.

Le déterminisme de la charge ne signifie pas un temps d’exécution identique : les fréquences, la température, le planificateur et les processus en arrière-plan continuent d’influencer la mesure.

Trois charges GPU

La partie GPU fonctionne via Direct3D 12. Les textures de travail internes ont une taille fixe de 1920×1080, indépendamment de la taille de la fenêtre et du bureau.

Charge	Travail de calcul	Ce qui aide à distinguer
Geometry	6 rendus de scène par 9 216 instances et 2 passes de post-traitement	Le traitement de la géométrie et la soumission du travail graphique
Shader	1 rendu de scène, 16 passes de post-traitement, paramètre de complexité du shader 24	La charge de pixels et de textures
Compute	Grille 1920×1080, groupes 8×8, calculs entiers avec 96 itérations	L’exécution du shader de calcul
Combined	Simulation CPU et pipeline graphique fixe	Le travail conjoint du CPU, du pilote et du GPU

Ce sont des scénarios distincts avec un volume de travail différent. Par exemple, 8 000 images conditionnelles de Compute ne peuvent pas être lues comme 8 000 FPS dans un jeu ni directement comparées à 800 images de Geometry. Pour l’unification, une normalisation par scénario est appliquée, décrite dans le calcul des points.

Les charges sont écrites sur un niveau de capacités portable : shader model 5.0 et feature level 11_0 sans extensions de fabricant. Le même code s’exécute sur différentes générations et différents fabricants de cartes graphiques, sans branche séparée pour un fabricant précis.

La correction de l’exécution de la charge est vérifiée séparément de la vitesse. En cas d’erreur, fiez-vous au message du programme et répétez le test après avoir éliminé la cause.

Il n’y a pas de tests séparés de vitesse du disque et de bande passante de la RAM dans cet ensemble. La mémoire et le pilote influencent l’exécution des charges, cependant le benchmark ne calcule pas d’évaluations séparées du SSD et de la RAM.

Répétition des blocs

Les cinq charges de performance sont exécutées en trois tours avec une permutation de l’ordre :

Tour	Ordre
1	CPU → Geometry → Shader → Compute → Combined
2	Shader → Compute → Combined → CPU → Geometry
3	Combined → CPU → Geometry → Shader → Compute

La place de chaque charge dans la séquence change d’un tour à l’autre. Cela réduit son influence sur la comparaison. L’échauffement peut encore modifier les résultats, c’est pourquoi, pour les blocs, la dispersion de la vitesse d’exécution et son évolution du premier bloc au dernier sont en outre conservées.

Pour évaluer un scénario, on prend la moyenne arithmétique du throughput de ses trois blocs. La médiane et la moyenne géométrique des blocs peuvent être consultées comme diagnostic supplémentaire, mais l’indicateur final reste malgré tout sur cette moyenne.

Pourquoi une basse résolution ne facilite pas le test principal

Les charges CPU, GPU et Combined sont exécutées hors du tampon d’écran. Leur chemin d’envoi des commandes n’appelle pas Present et n’attend pas la limitation de la file d’affichage. Les textures internes restent en 1920×1080, même si le bureau est commuté en 800×600.

L’interface et le test de latence fonctionnent via un chemin de sortie séparé. C’est pourquoi le changement de résolution du bureau en lui-même ne facilite pas la charge elle-même. Néanmoins, on ne peut toujours pas lire un résultat « absolument identique » à n’importe quelle résolution : sur le segment de sortie, le pilote et l’état actuel du système participent.

Une vérification archivée de la version 0.5.2 avec 1920×1080, 1280×768 et 800×600 est donnée dans l’article sur la répétabilité. Elle ne remplace pas une nouvelle série après la modification des scénarios GPU.

Pilotes et comparaison des cartes graphiques

Geometry, Shader et Compute vérifient différents chemins d’exécution. Une carte graphique peut être plus rapide dans un scénario et plus lente dans un autre. La version du pilote, les fréquences, les limites de puissance et la soumission des commandes peuvent modifier le résultat. Un Compute différent ne suffit pas pour attribuer la différence uniquement au pilote. Comparez plusieurs répétitions, la version du moteur et chaque scénario séparément.

La réduction de la résolution du bureau ne réduit pas la grille de travail de Compute. Ce test utilise son propre shader de calcul, et non les FPS d’affichage de la fenêtre. Le poids de Compute dans le GPU Score de base est de 10% ; les détails sont donnés dans la formule.

Vérifié pour l’implémentation décrite : 2026-10-02.