Le lancement chez AMD des produits Ryzen d'une part puis de la gamme Threadripper d'autre part a sifflé le départ d'une nouvelle guerre des coeurs entre les deux acteurs du marché des processeurs. Une guerre qui nous a obligé à revoir notre protocole de test, afin qu'il colle aux spécifications des nouveaux processeurs haut de gamme de chaque fabricant.

Sur le fond, notre protocole de test reste toujours axé sur les performances applicatives d’une part, et sur les performances vidéoludiques d’autre part, qu’elles soient directes (performances en jeu) ou indirectes (performances en streaming de jeu). Toutefois, le dimensionnement inédit des puces Skylake-X comme Threadripper nous a obligés à faire évoluer quelque peu nos outils d’évaluation. Par exemple, nous utilisions précédemment les logiciels FritzChess et Winrar… Sauf que ces derniers ne sont pas capables de prendre en charge plus de 16 threads. C’est la moitié de ce qu’est capable de traiter le 1950X, et cela conduit immanquablement à des résultats biaisés. Aussi logiquement, nous avons choisi de les retirer de nos outils, pour en ajouter deux autres : Corona et FryBench. Chacun se base sur un moteur de rendu différent (Corona et FryRender en l’occurrence), et tous deux ont l’avantage de parfaitement supporter les processeurs Skylake-X comme Threadripper.

Derrière, nous utilisons toujours pour déterminer les performances d’un processeur donné un test de compression, sous 7Zip, un test d’encodage sous Handbrake, et 2 tests visant à caractériser les performances générales des processeurs, sur chaque cœur et/ou sur l’architecture dans son ensemble : Cinebench et Geekbench. Parallèlement, nous avons testé la consommation de nos différentes plateformes de test (à la prise), lors d'une forte sollicitation du processeur, sous Prime95 (Test In Place Large FTTs). Enfin, nous avons effectué quelques essais d'overclocking, afin de mesurer si une marge de performances intéressante restait disponible, pour ceux qui souhaiteraient l'exploiter.

En images, les jeux qui nous ont servis de base de travail pour ce dossier

Des changements, il y en a également eu quelques-uns sur la partie vidéoludique. Petit rappel : en jeu, CPU et GPU fonctionnent selon un rapport d’interdépendance. Pour reprendre un exemple concret, avant de pouvoir afficher un élément de décor détruit à l’écran, le GPU doit attendre que le CPU ait pris en compte la destruction de cet élément de décor… À l’inverse, si le process de rendu graphique traîne en longueur, c’est le CPU qui va se tourner les pouces, en attendant de pouvoir plancher sur l’évaluation des conditions de jeu de l’image suivante. De fait, et très naturellement, c’est en diminuant la charge sur le GPU que les limitations du CPU sont plus clairement retranscrites. Nous utilisons donc pour nos tests des réglages graphiques relativement bas, et une résolution 1920 par 1080 pixels. Sur cette base, nous cherchons à vérifier dans quelle mesure un CPU donné est en mesure de limiter les performances d’un GPU donné. À ce titre, chaque CPU est testé avec différentes cartes graphiques, de la GTX 1050 Ti à la GTX 1080 (A titre d'informations, nous nous arrêtions à la GTX 1070 auparavant).

Vous noterez maintenant que ces conditions de tests, si elles permettent de caractériser les limitations d’un CPU par rapport à un autre dans un cadre vidéoludique, ne sont pas toujours réalistes. Typiquement, on peut difficilement imaginer qu’un joueur disposant d’une GTX 1080 paramètre ses jeux à un niveau très bas en résolution Full HD, et se contentent d’une qualité visuelle dégradée pour le simple plaisir de tourner à 250 FPS… Du coup, si un défaut de performances en jeu devait se faire jour sur notre première batterie de tests, ils convenaient de se demander dans quelle mesure cette différence serait notable dans un contexte plus classique. C’est tout le but de la seconde partie de notre protocole, qui reprend les grandes lignes que nous venons de définir, mais avec des réglages graphiques plus réalistes, et donc, plus lourds.

Autre nouveauté dans notre liste de jeux de référence : nous avons décidé de faire l’impasse sur les deux Total War, pour les remplacer par The Division et Watch Dogs 2, qui se caractérisent par une utilisation du CPU et des architectures multi-coeurs assez forte. D’autre part, nous avons poussé nos essais de streaming plus loin que d’habitude. En effet, eu égard à la puissance développée par le i9-7980XE et par les processeurs Threadripper, les paramètres que nous appliquions jusqu’à présent à nos sessions d’encodage temps réel ne permettaient pas de les départager. Nous les avons donc poussés un cran au-dessus. Toujours sous OBS, nous sommes passés d’un flux d’encodage 720p / 60 FPS / x264 / birate max = "4000" / preset d'encodage = "Slow" à un flux 1080p / 60 FPS / FPS / x264 / birate max = "6000" / preset d'encodage = "Slow". La qualité du stream continue quant à elle d’être évaluée sur une échelle à 4 niveaux : une note de 4 correspondra à un flux parfait, tandis qu'une note de 1 reflètera une perte de frame ingérable, voire, des déconnexions de service. Enfin, pour chaque processeur, nous avons mesuré l’impact de la gestion du stream sur les performances en jeu.

Pour plus de clarté, nous avons rassemblé l’ensemble des tests et configurations de jeux appliqués lors de notre protocole dans le tableau ci-dessous.

> Tests applicatifs

> Configurations de nos tests vidéoludiques