AMD et NVIDIA optimisent leurs drivers pour Far Cry Primal

La sortie récente du jeu Far Cry Primal est donc l’occasion pour AMD et NVIDIA de mettre en ligne de nouveaux drivers, respectivement estampillés « Radeon Software Crimson Edition 16.2.1 » et « GeForce 362.00 Game Ready », bien entendu optimisés aux petits oignons (réglages GeForce Experience ainsi que profil CrossFireX dédiés).

Corrections de bugs, améliorations de performances

AMD en profite également pour corriger quelques bugs dans Fallout 4, World of Warcraft et Rise of the Tomb Raider, de même qu’un problème touchant les configurations en CrossFire avec FreeSync d’activé. Du côté de NVIDIA, ces pilotes certifiés WHQL apportent également des améliorations de performances dans Gears of War Ultimate Edition et Dying Light.

Bref, pour ceux qui veulent télécharger ces nouveaux pilotes Radeon Crimson (pour Windows 7, 8.1 et 10) et GeForce (Windows Vista à Windows 10), suivez ces liens :

Posez une question dans la catégorie Les news : vos réactions du forum
Cette page n'accepte plus de commentaires
10 commentaires
    Votre commentaire
  • magellan
    C'est tout de même affolant de constater que ce sont les constructeurs qui collent des patchs sur leurs pilotes pour que les jeux en profitent, alors qu'il serait logique que ce soit plutît l'inverse!

    Je vois venir ceux qui ne saisissent pas le pourquoi... le raisonnement est le suivant: quand vous allez à la pompe essence, est-ce à la pompe de s'adapter à votre voiture, ou à votre voiture d'être adaptée à la pompe? Techniquement, pourquoi les pompes seraient revues pour UNE voiture?

    ça n'a vraiment pas de sens, surtout quand on liste le nombre de "bidouillages" dans les pilotes pour améliorer certains jeux... En un mot: lamentable.
    0
  • mitch074
    Les bidouillages de pilotes sont nécessaires sous DirectX et OpenGL, puisque le créateur du jeu n'a pas accès à un paquet de paramètres de rendu par défaut qui ne peuvent être définis qu'au niveau du pilote. De plus, il y a régulièrement des fonctions qui ne sont soit pas implémentées correctement dans un pilote (jamais vraiment testée en condition réelle, ou qui mériterait une optimisation). Pour donner un exemple de chacun de ces cas:
    - l'implémentation de la tessellation sous DirectX11: il n'y a pas moyen de dire au pilote quel est le nombre maxi de segments rendus pour un vertex donné; résultat, les cartes AMD se traînaient sous Witcher 3 parce que le pilote faisait un rendu par défaut à 1024 segments par vertex - ce qui, dans les cas d'affichage de fourrure (à 15 000 vertex par bestiole) représentait une MASSE de calcul pour rien (chaque vertex étant rendue sur 3 à 8 pixels); les pilotes Nvidia, qui détectaient l'utilisation d'une lib proprio de Nvidia, baissaient ce rendu à 8 ou 16 segments. AMD a donc sorti un nouveau pilote, qui incluait un profil restreignant le rendu à 8 ou 16 segments par vertex lorsque Witcher 3 tournait.
    - les Unified Buffer Objects (OpenGL, émulateur Dolphin): les développeurs Intel du pilote Linux ont dit cash au créateur de l'émulateur qu'ils avaient implémenté les UBO, mais qu'ils les optimiseraient lorsque quelqu'un s'en servirait. Résultat, lorsqu'ils ont eu une build de l'émulateur à tester, ils ont réécrit toute leur implémentation pour qu'elle soit plus juste et plus rapide.

    A noter que sous Mantle, DX12 et Vulkan, les développeurs ayant un accès quasi direct au matériel il y a peu de chance que le pilote ait encore autant d'impact sur les performances.
    0
  • magellan
    Anonymous a dit :
    Les bidouillages de pilotes sont nécessaires sous DirectX et OpenGL, puisque le créateur du jeu n'a pas accès à un paquet de paramètres de rendu par défaut qui ne peuvent être définis qu'au niveau du pilote. De plus, il y a régulièrement des fonctions qui ne sont soit pas implémentées correctement dans un pilote (jamais vraiment testée en condition réelle, ou qui mériterait une optimisation).

    Ce qui sous-entend clairement deux défauts fondamentaux.
    1- on crée des fonctionnalités non validées
    2- les développeurs s'y adossent sans avoir la moindre certitude.

    Dans ce cas là, c'est au constructeur de fournir des pilotes qui soit intègrent des choses qui marchent, soit ne fournissent pas la fonction... Mais pas une solution bâtarde où l'on patche PAR JEU.

    Anonymous a dit :
    Pour donner un exemple de chacun de ces cas: - l'implémentation de la tessellation sous DirectX11: il n'y a pas moyen de dire au pilote quel est le nombre maxi de segments rendus pour un vertex donné; résultat, les cartes AMD se traînaient sous Witcher 3 parce que le pilote faisait un rendu par défaut à 1024 segments par vertex - ce qui, dans les cas d'affichage de fourrure (à 15 000 vertex par bestiole) représentait une MASSE de calcul pour rien (chaque vertex étant rendue sur 3 à 8 pixels); les pilotes Nvidia, qui détectaient l'utilisation d'une lib proprio de Nvidia, baissaient ce rendu à 8 ou 16 segments. AMD a donc sorti un nouveau pilote, qui incluait un profil restreignant le rendu à 8 ou 16 segments par vertex lorsque Witcher 3 tournait.

    Sauf qu'encore une fois, on patche pour UN jeu. Il n'y a pas là une belle connerie côté développeurs du jeu? Si l'on utilise quelque-chose que l'on SAIT bridé et/ou mal foutu, c'est un choix et pas un impératif.
    Anonymous a dit :
    - les Unified Buffer Objects (OpenGL, émulateur Dolphin): les développeurs Intel du pilote Linux ont dit cash au créateur de l'émulateur qu'ils avaient implémenté les UBO, mais qu'ils les optimiseraient lorsque quelqu'un s'en servirait. Résultat, lorsqu'ils ont eu une build de l'émulateur à tester, ils ont réécrit toute leur implémentation pour qu'elle soit plus juste et plus rapide.

    Là ça fonctionne par réciprocité, c'est à dire un échange de bons procédés.

    Anonymous a dit :
    A noter que sous Mantle, DX12 et Vulkan, les développeurs ayant un accès quasi direct au matériel il y a peu de chance que le pilote ait encore autant d'impact sur les performances.

    Note tout de même que tous les jeux ne pâtissent pas de problèmes de ce genre... parce que les choix faits au moment du développement ne sont nécessairement pas les mêmes, et que cela implique aussi de connaître la cible.

    Par analogie élémentaire: quand tu prépares une maison, tu fais avec les matériaux que tu sais être viables, ou bien tu prends le risque de choisir des matériaux jamais validés, et qu'au surplus en cas de souci tu n'aies pas de recours? A tout choisir...
    0