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 d’enregistrements de jeu, et les chiffres finaux ne correspondent pas aux « FPS dans un jeu précis ». Le cycle de mesure complet est décrit dans la méthodologie.

Actuellement, le moteur 0.5.2 et la charge phase4.6-dev-1 sont utilisés. Il faut garder la version à l’esprit : un changement de scénario rend les résultats de différentes versions directement incomparables.

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 flux 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 flux « 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 décompte, afin de ne pas traî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 de 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 scores.

Les charges sont écrites sur un niveau de capacités portable : shader model 5.0 et feature level 11_0 sans extensions de fournisseur. Le même code s’exécute sur différentes générations et fabricants de cartes graphiques, sans branche spécifique à un fournisseur donné.

Après les mesures, le moteur vérifie la sortie de chaque charge GPU : pour Geometry, Shader, Compute, Combined et le test de latence chargé, une signature de contrôle est fixée — l’aspect attendu d’un petit fragment du résultat. Le fragment lu après l’achèvement est comparé à celui attendu ; une non-concordance signifie que la charge s’est exécutée incorrectement et rend le lancement inutilisable. La vérification est effectuée après les mesures prises en compte et n’influence pas les chiffres eux-mêmes.

Il n’y a pas de tests séparés de vitesse du disque ni 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 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 également conservées.

Pour l’évaluation d’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 ne provoque pas de 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 passé en 800×600.

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

Une vérification pratique avec 1920×1080, 1280×768 et 800×600 est présentée dans l’article sur la répétabilité.

Vérifié pour l’implémentation décrite : 2026-09-20.