Pilotes 340.43 Bêta : NVIDIA se prépare pour BF : Hardline et GRID Autosport

Pilotes 340.43 Bêta : NVIDIA se prépare pour BF : Hardline et GRID Autosport

Mais aussi Plants vs. Zombies: Garden Warfare

Avatar de l'auteur
David Legrand

Publié dans

Sciences et espace

18/06/2014 2 minutes
10

Pilotes 340.43 Bêta : NVIDIA se prépare pour BF : Hardline et GRID Autosport

NVIDIA vient d'officialiser une nouvelle branche de ses pilotes graphiques avec la version 340.43 publiée hier dans la soirée. Elle n'apporte par contre que quelques améliorations, mais permet surtout de s'adapter à la sortie de Battlefield : Hardline, GRID Autosport et Plants vs. Zombies : Garden Warfare.

Battlefield Hardline

 

Avec sa nouvelle branche 340, NVIDIA n'inaugure pour le moment pas de nouvelles fonctionnalités. En efftet, dans la note de version de ses pilotes Bêta 340.43, le constructeur indique surtout de nouveaux profils SLI et 3D Vision. Les premiers concernent Sky Diver, le nouveau test de 3DMark, mais aussi Battlefield : Hardline, Dark Souls II, Elder Scrolls Online, WildStar et LuDaShi Benchmark. Pour le second, seuls trois titres sont évoqués : Banished, BioShock Infinite : Burial at Sea et Krater.

 

Mais cette nouvelle mouture est aussi et surtout l'occasion de se préparer à l'arrivée de prochains titres qui pourraient être des blockbusters : Si Plants vs. Zombies: Garden Warfare est mentionné, on pense surtout à GRID Autosport et à Battlefield : Hardline, dont la bêta vient de s'ouvrir à de nombreux joueurs et qui est attendu en version commerciale pour le 21 octobre prochain.

 

Comme toujours, pour les détails et le téléchargement, cela se passera par ici ou via l'outil de mise à jour intégré à GeForce Expérience.

Écrit par David Legrand

Tiens, en parlant de ça :

Sommaire de l'article

Introduction

Fermer

Commentaires (10)


Ishan
Le 18/06/2014 à 08h 02

Je sais pas si c’est la vieillerie qui m’atteinds mais j’ai bien plus envit d’éssayer Garden Warfare que Battlefield ou GRID <img data-src=" />


K2Death Abonné
Le 18/06/2014 à 08h 16

alerte envoyé pour le lien de téléchargement incorrect


Cara62
Le 18/06/2014 à 08h 17

Et pour Watch dogs version E3 2012 ?



=====&gt;[]


romjpn
Le 18/06/2014 à 10h 49

Pour un add-on de BF4 franchement y avait besoin ? <img data-src=" />


Guinnness
Le 18/06/2014 à 12h 18

Je trouve toujours aussi ridicule que les devs de pilotes graphiques soient systématiquement obligés de se creuser la tête pour fournir des “optimisations” (des correction de bugs quoi) spécifiques pour chaque nouveau jeu qui sort <img data-src=" />



Pour moi un pilote graphique devrait s’occuper uniquement et exclusivement du bon fonctionnement de la carte graphique elle même et de rien d’autre.



Il y a des docs techniques qui définissent ce qu’on obtient en sortie avec telle ou telle instruction en entrée, si les devs de jeu sont incapables de s’y conformer et bien qu’ils changent de métier, ça n’est en aucun cas aux devs de pilotes graphiques de se casser la tête à mettre en place des bidouilles plus ou moins efficaces pour tenter de palier à l’incompétence de certains devs de jeux. <img data-src=" />



Après s’il y a des bugs(et il y en a toujours) dans les pilotes qui affectent le rendu c’est bien entendu aux devs de ces pilotes de les corriger ça mais les bugs/conneries/mauvaises implémentations dans les jeux eux mêmes c’est aux devs de ces jeux de se démerder avec et à personne d’autre.



Si on arrêtait de raisonner à l’envers en cherchant toujours à corriger à postériori les conneries au lieu de le faire à la source on éviterait d’avoir des pilotes graphiques qui pèsent plus de 100Mo et des jeux qui ne fonctionnent correctement qu’avec telle ou telle version des pilotes.





Après je met les “optimisations spécial kikitoudur” pour accros aux benchmarks à part, là le bug c’est plutôt entre la chaise et le clavier qu’il se situerait <img data-src=" />


kervern
Le 18/06/2014 à 12h 32







Cara62 a écrit :



Et pour Watch dogs version E3 2012 ?



=====&gt;[]







aussi beau pourquoi pas mais qu’avant tout il fonctionne avec presque le double d’image quand t’utilise le SLI, parce que chez moi, avec ou sans SLI j’ai le même nombre d’image, et la surveillance du SLI par l’osd de nvidia me dit que le sli est a pleine charge sur mes 2 cartes :p



vampire7
Le 18/06/2014 à 14h 11







Guinnness a écrit :



…





+1

D’autant plus que ces “optimisations” entrainent un bon paquet de bugs. Là par exemple, c’est la 2ème version de suite qui cause des hachures dans le son de l’émulateur Dolphin. Du coup, me voilà bloqué au 335.23 pendant sûrement encore un bon moment.



Charly32
Le 18/06/2014 à 17h 50







Guinnness a écrit :



…





Le problème étant que les API accessible aux dev de jeux sont haut niveau (notamment directX jusqu’à 11.x). Ils n’ont pas la main sur tout ce qui se cache derrière les instructions utilisées, et c’est là que le fabricant de GPU intervient. Le pilote fait le lien entre les API supportée et le matériel.



Par exemple sur les archi VLIW d’AMD, le pilote devait se démerder pour “vectoriser” le code traité. C’était transparent pour les dev de jeux vidéo, mais ça demandait du boulot chez AMD.



4RB-bzh-
Le 18/06/2014 à 20h 24

J’ai voulu m’inscrire pour la beta de battlefield, quand j’ai la configuration requise j’ai fermé l’onglet j’ai regardé ma tour et j’ai pleuré!!!

Oui j’avais très mal au cul!!!! <img data-src=" />


Guinnness
Le 19/06/2014 à 17h 21







Charly32 a écrit :



Le problème étant que les API accessible aux dev de jeux sont haut niveau (notamment directX jusqu’à 11.x). Ils n’ont pas la main sur tout ce qui se cache derrière les instructions utilisées, et c’est là que le fabricant de GPU intervient. Le pilote fait le lien entre les API supportée et le matériel.



Par exemple sur les archi VLIW d’AMD, le pilote devait se démerder pour “vectoriser” le code traité. C’était transparent pour les dev de jeux vidéo, mais ça demandait du boulot chez AMD.





Justement, les devs de jeux ont des API (normalement) claires et précises à disposition et sont censé s’y conformer scrupuleusement, en évitant le “freestyle sauvage”.

Ce qui se passe derrière c’est pas leur problème, c’est justement à ça que ça sert de mettre en place des API standardisées.



La mise en place du pont API &gt; matos c’est le travail des devs de pilotes.

C’est eux qui doivent faire en sorte que chaque fonction de l’API soit exécutée le plus efficacement possible tout en conservant l’universalité de l’API. (une même fonction doit toujours s’exécuter exactement de la même façon indépendamment de la façon dont elle a été appelée sinon ça ne sert à rien de mettre en place des API standardisées)



Si chacun restait à sa place à faire, correctement, le boulot qui lui incombe et uniquement celui là on aurait nettement moins de soucis de compatibilité que ce qu’on a aujourd’hui.





Après j’y vois 2 exceptions possibles :




  • les devs de jeux ont besoin d’une fonction spécifique qui ne fait pas partie de l’API ce qui les oblige à bricoler en combinant de façon plus ou moins hasardeuses des fonctions plus ou moins détournées de leur but premier.

    Là le résultat peut très bien devenir imprévisible puisque les fonctions sont utilisées en dehors du cadre “normal” pour lesquelles elles ont été conçues et effectivement il va falloir faire collaborer les 2 parties pour trouver une solution



  • les devs de pilotes ont toujours sous le coude quelques fonctions cachées non standards et non documentées dont ils se réservent l’usage pour pouvoir pondre des démos graphiques qui poutrent du bébé chat au petit dèj mais ils en font exceptionnellement bénéficier les devs de jeux avec lesquels un partenariat a été négocié.

    Là forcément quand on tape dans du pas standard, parfois spécifique à un matos bien précis, faut pas s’étonner si la compatibilité devient hasardeuse et sans qu’il y ai forcément de solution.

    Là encore la faute incombe aux 2 parties : les devs de pilotes qui n’auraient jamais dû divulguer ces instructions spécifiques et les devs de jeux qui n’auraient jamais dû se reposer dessus.