Comptotuto • Bidouiller Cyberpunk pour son CPU AMD |
————— 13 Décembre 2020 à 23h52 —— 31559 vues
×
Avant/après : le résultat est visuel !
Comptotuto • Bidouiller Cyberpunk pour son CPU AMD Depuis le retour en grâce d’AMD, les processeurs rouges sont devenus monnaie courante chez les joueurs, même si la victoire face à Intel en matière de jeu ne s’est avérée qu’avec les tout derniers modèles sous architecture Zen 3. Mais, avant Zen se trouvait une autre architecture, bien moins réussie : Bulldozer, qui avait également tenté la carte de multicœurs à foison (8 cœurs là où la norme n’était que 4 à l’époque) au prix de rassemblement en modules cassant les performances monocoeurs.
Quel rapport avec notre Cyberpunk ? Nous y venons : AMD développe depuis quelque temps GPUOpen, une initiative visant à proposer des bibliothèques de programmation ouvertes disposant d’un panel étoffé d’effets préoptimisés pour les cartes graphiques, entres autres les filtres FidelityFX. Or, dans ce code, nous y trouvons une méthode de détection des cœurs/threads d’un processeur assez... étrange. En effet, dans le cas d’un processeur Intel, la fonction de détection utilisée pour calculer le nombre de processus à lancer retournera le nombre de threads (cœurs logiques) : pas de soucis. Dans le cas d’un ancien bouzin sous architecture Bulldozer, idem, le nombre de cœurs logiques est également renvoyé (soit 2 par module). Mais, dans les autres cas — comprenez, par exemple et à tout hasard, un processeur Ryzen — seuls le nombre de cœurs physiques est renvoyé : aux oubliettes le SMT ! Un patch en assembleur est possible, et ne concerne que deux octets, mais la procédure nécessite le téléchargement et l’installation d’un éditeur binaire : pas du plus ergonomique.
Assez ironiquement, le problème serait donc directement en provenance des rouges, une situation assez cocasse lorsque l’on sait qu’Intel a un passif en ce qui concerne les idées pour désavantager le concurrent de manière logicielle. En effet, il est connu (et reconnu) que le compilateur ICC développé par les bleus contient des routines activant certaines optimisations uniquement dans le cas de puces en provenance de la maison-mère... chou blanc, ce n’est pas problème ici !
![Avant/après : le résultat est visuel ! [cliquer pour agrandir]](/images/stories/_jeux_videos/cyberpunk2077-reddit-patch_t.png "Ultra bouzotron HD max def")
Sans/Avec le patch : la répartition de la charge semble, au jugé, clairement meilleure
Pas de panique, le comptoir vous a préparé une archive toute fraîche du jeu patchée — version 1.04, attention à vous — de telle sorte que vous n’avez plus qu’à la télécharger, sauvegarder votre exécutable précédent et le remplacer par celui téléchargé, dans l’emplacement Cyberpunk\bin\x64 (vous pouvez vous rendre dans le répertoire d’installation via Steam par l’opération suivante : clic droit -> « Propriétés » -> onglet « Fichiers locaux » -> « Parcourir les fichiers locaux »). Notez que ce binaire devrait aussi être compatible avec les processeurs Intel, mais sera sans effet.
Au passage, cette recherche, tout droit sortie de Reddit, n’aurait pas pu se dérouler en présence de DRM et d’API fermée : de quoi donner matière à réfléchir quant à l’intérêt général de ces protections. Pour ce qui est des performances, le comptoir bûche déjà sur des mesures préliminaires ; néanmoins les retours des utilisateurs indiqueraient que la principale amélioration s’effectuerait sur les FPS minimum, et, selon la configuration, sur les FPS moyens, particulièrement lorsque le Ray Tracing est activé, sachant que ces gains seraient principalement présent sur les CPU équipés d'un seul CCX (i.e., les plus faibles en cœurs). Un comportement qui correspondrait tout à fait à un goulot d’étranglement plus faible au niveau CPU. Enfin, rappelons tout de même que les premiers Ryzen avaient du mal en multicore, particulièrement lorsque plusieurs CCX étaient chargés simultanément, ce qui expliquerait le comportement étonnant de GPUOpen, dont la dernière modification de fichier en cause remonte à septembre 2017 ! Affaire à suivre ; prochaine étape : la réponse de la firme ?
Les tests du non chevelu :
Nous avons donc entrepris de faire des mesures suite à l’observation d’une charge CPU plus grande comme en atteste notre capture avant/après. Toutefois, nous avons rencontré de gros problèmes pour mettre cela en évidence. La base de mesures précises, le plus possible, est fondée sur la répétabilité et il y a deux cas. Bien que la scène ait été en zone urbaine, quelle que soit la sauvegarde, le jeu modifie le nombre de PNJ, ce qui change systématiquement la fiabilité des mesures, car charge différente (les perfs ne sont pas les mêmes s’il y a 3 PNJ ou 50 !). Sur 3 runs réalisés sur 3 scènes urbaines, jamais nous n’avons relevé les mêmes résultats sur les valeurs mini, 1 % et 0,1 % Low, ou en tout cas des valeurs approchantes, que ce soit avec ou sans Ray Tracing. Sur les moyennes, pas de gain observé, comme la scène mesurée est longue, de l'ordre de la minute, les moyennes ne varient pas beaucoup mais suffisamment pour ne pas être reproductibles, les gros coups de charge étant dilués sur la durée.
Le seul moment où notre personnage se retrouve réellement seul, c’est dans le désert, au début du jeu. À ce compte-là, étant donné que la scène est strictement reproductible et sans interférence, les mesures sont valides et très proches. Sauf qu’à ce moment précis, la charge induite n’est pas un obstacle aux performances, avec ou sans Ray Tracing. Il n’y a aucune différence observée entre les perfs avec et sans le binaire. Comment donc savoir ?
Eh bien d’un point de vue protocole strict « scientifique », ce n’est pas possible puisque les seules scènes vraiment chargées sont en ville, et ça varie trop pour en tirer une vérité. Et ce, quel que soit le CPU, c’est une règle immuable du testeur, si la répétabilité n’est pas assurée, alors il ne peut y avoir de valeurs sûres à analyser. Il y a également un facteur non négligeable dont il faut tenir compte, c'est que le multi threading entraîne de grosses variations de mesures, d'où sa désactivation dans nos tests comme indiqué en protocole. En revanche, on sent qu’en Ray Tracing, ça semble mieux répondre aux mouvements du personnage central, mais ce n’est qu’une sensation qui n’est pas mesurable.
Si nous voyons bien le CPU se servir des cœurs logiques avec le nouveau binaire, il est impossible scientifiquement de prouver leur apport. Soyez donc vigilants sur les chiffres séduisants qu’on pourrait vous tendre surtout sur les mini, 1 % et 0,1 % Low ! Cela pose également des questions sur le mode opératoire des tests de performance GPU, sauf si la scène est dans le désert bien entendu.
Nous avons donc entrepris de faire des mesures suite à l’observation d’une charge CPU plus grande comme en atteste notre capture avant/après. Toutefois, nous avons rencontré de gros problèmes pour mettre cela en évidence. La base de mesures précises, le plus possible, est fondée sur la répétabilité et il y a deux cas. Bien que la scène ait été en zone urbaine, quelle que soit la sauvegarde, le jeu modifie le nombre de PNJ, ce qui change systématiquement la fiabilité des mesures, car charge différente (les perfs ne sont pas les mêmes s’il y a 3 PNJ ou 50 !). Sur 3 runs réalisés sur 3 scènes urbaines, jamais nous n’avons relevé les mêmes résultats sur les valeurs mini, 1 % et 0,1 % Low, ou en tout cas des valeurs approchantes, que ce soit avec ou sans Ray Tracing. Sur les moyennes, pas de gain observé, comme la scène mesurée est longue, de l'ordre de la minute, les moyennes ne varient pas beaucoup mais suffisamment pour ne pas être reproductibles, les gros coups de charge étant dilués sur la durée.
Le seul moment où notre personnage se retrouve réellement seul, c’est dans le désert, au début du jeu. À ce compte-là, étant donné que la scène est strictement reproductible et sans interférence, les mesures sont valides et très proches. Sauf qu’à ce moment précis, la charge induite n’est pas un obstacle aux performances, avec ou sans Ray Tracing. Il n’y a aucune différence observée entre les perfs avec et sans le binaire. Comment donc savoir ?
Eh bien d’un point de vue protocole strict « scientifique », ce n’est pas possible puisque les seules scènes vraiment chargées sont en ville, et ça varie trop pour en tirer une vérité. Et ce, quel que soit le CPU, c’est une règle immuable du testeur, si la répétabilité n’est pas assurée, alors il ne peut y avoir de valeurs sûres à analyser. Il y a également un facteur non négligeable dont il faut tenir compte, c'est que le multi threading entraîne de grosses variations de mesures, d'où sa désactivation dans nos tests comme indiqué en protocole. En revanche, on sent qu’en Ray Tracing, ça semble mieux répondre aux mouvements du personnage central, mais ce n’est qu’une sensation qui n’est pas mesurable.
Si nous voyons bien le CPU se servir des cœurs logiques avec le nouveau binaire, il est impossible scientifiquement de prouver leur apport. Soyez donc vigilants sur les chiffres séduisants qu’on pourrait vous tendre surtout sur les mini, 1 % et 0,1 % Low ! Cela pose également des questions sur le mode opératoire des tests de performance GPU, sauf si la scène est dans le désert bien entendu.
 | Un poil avant ?3 tests de performance GPU pour Cyberpunk 2077 | Un peu plus tard ...Gamotron • Un nettoyeur pas comme les autres | |
