Toujours plus de modifications possibles pour Cyberpunk 2077 ! |
————— 14 Décembre 2020 à 14h09 —— 25324 vues
Finalement, que de tumultes dans cette affaire concernant Cyberpunk 2077 ! Non content d’avoir découvert que seule la moitié des cœurs logiques étaient utilisée pour les processeurs AMD (découvrez par ici le patch CDH approved), voici que Reddit a trouvé toujours plus de « bugs » à ce niveau. Que vous ayez tâté le titre ou juste suivi l’actualité par les échos de la presse, sachez que certaines configurations parmi les plus testicouillues sont affectées par des chutes importantes du taux d’image par seconde, ainsi qu’une utilisation du GPU un peu trop faiblarde par rapport à ce qui était attendu.
En fait, CD Projekt Red, le studio à l’origine du développement, semble avoir oublié de modifier un fichier de configuration pour les versions PC, rendant uniquement 1,5 Gio de mémoire disponible pour le processeur, et 3 Go côté VRAM. Inutile de dire que les possesseurs d’une RX 6900 à 16 Gio de VRAM doivent l’avoir un peu mauvaise ! Nuançons néanmoins : de nombreux tests ont montré des consommations de RAM/VRAM largement supérieure à ces chiffres, il semblerait donc que ce ne soit pas le seul moyen pour le jeu de réserver de la mémoire, rendant, une fois encore, l’efficacité du correctif aléatoire.
Ce n’est pas tout : du fait de l’absence de protection du code (assembleur), des petits malins ont profité des modifications du binaire utilisé pour libérer les threads sur CPU AMD, pour développer davantage d’optimisations, notamment pour retirer le code permettant de corriger les vulnérabilités Spectre et Cie. Du fait de l’absence de mode multijoueurs, il est en effet peu probable que le jeu puisse être détourné pour lire le contenu de votre système, mais gardez à l’esprit que rien n’est impossible pour qui est assez déterminé — bien que hautement peu probable. De plus, un souci de connexion avec les contrôleurs tiers semble également être présent, et corrigé par les patchs disponibles sur le web.
Pour réaliser ces bidouilles, un GitHub dédié a été créé, afin que n’importe quel utilisateur spécialiste puisse participer, ainsi qu’un mod sur le site bien connu NexusMod, pour les habitués du genre. Pour l’installer, la procédure est courte : tout d’abord, annuler toutes les modifications précédentes (comprenez : assurez-vous que le binaire Cyberpunk.exe est bien celui original), puis télécharger le dossier compressé suivant :
Extrayez-le dans
Cyberpunk2077\bin\x64 en sauvegardant au préalable vos fichiers (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 »), et.. c’est tout ! Vous pouvez vous assurer du bon fonctionnement du patch en ouvrant le fichier Cyberpunk\bin\x64\performance_overhaul\performance_overhaul.log. Notez qu’un fichier de configuration est disponible, par ici pour en savoir plus, les options par défaut étant suffisantes pour l’écrasante majorité des joueurs.
Si la procédure de développement du patch fait appel à un reverse-engineering du code assembleur, il faut bien garder en tête que la rustine effectue en interne des remplacements à des endroits donnés — pour le patch activant le multicœur chez AMD, un saut conditionnel est transformé en saut —, ou selon des règles précises du pattern matching, c’est-à-dire de structure globale d’un morceau de code. Théoriquement, le compilateur s’est automatiquement chargé d’ajouter des barrières afin d’intercepter une potentielle attaque de Spectre : le correctif va alors modifier une instruction afin d’effectuer un saut évitant cette vérification. Rien de bien sorcier, même s’il est clair que ce genre de paramétrage aurait pu être effectué à la compilation du jeu... encore faut-il que les développeurs aient une connaissance fine du fonctionnement des compilateurs, ce qui est loin d’être le cas de tous — en particulier lorsque la programmation s’effectue sur des outils spécifiques dans lesquelles les options de compilations sont plutôt obscures à trouver et vérifier.
Notez que le README du patch fait mention de possibles ajouts d’instruction SIMD, c’est-à-dire aller remplacer des instructions x86 standards par des extensions AVX/AVX2, ce qui peut théoriquement améliorer le temps d’exécution... mais pas toujours, car ces remplacements peuvent mener à des latences plus grandes, puisque ces extensions sont désignées pour offrir un fort débit (= beaucoup d’opérations effectuées en parallèle), et pas forcément une accélération passagère lors d'une utilisation unique ! Comprenez que l’optimisation de code assembleur est une problématique bien plus large que quelques morceaux de code à remplacer selon une heuristique fixe, et que certains patchs bénéfiques pour certaines configurations peuvent se révéler néfastes pour d’autres.
Est-on entré dans une nouvelle ère du développement du jeu vidéo, où les utilisateurs sont désormais le dernier maillon du contrôle qualité d’un titre vidéoludique ? Espérons que non, mais ce genre d’événement ne peut que refléter un titre encore immature par rapport à sa date de sortie, un schéma malheureusement loin d’être anodin ces dernières années ; et cela ne semble pas près de s’améliorer vu les moults scandales concernant les conditions de travail des développeurs, récurrents à chaque nouveau produit. Affaire à suivre !
 | Un poil avant ?Plein de nouvelles RTX 3000 apparaissent chez AIDA64, desktop et mobile | Un peu plus tard ...Ventes de jeux vidéo : cyber black ops | |
Après le problème du sli/crossfire c'est autre chose. D'une part les fabriquant n'aiment pas que deux cartes à 250€ chacune dépassent une carte à 700€, ça demande aussi des efforts importants côté pilotes et devs pour un publique limité. Et enfin le shuttering , gros point noir de ces technos multi GPU. Au delà des moyennes alléchantes, quand on regarde en détail c'est pas toujours jojo et parfois pire qu'en mono GPU.
Du coup ça fait quelques années que ça a disparu ou presque pour le grand publique.