Les derniers contenus liés aux tags Nvidia et SLI

MAJ : Pilotes GeForce 375.57 pour Civ VI, BF1...

Publié le 24/10/2016 à 12:05 par Guillaume Louel

MAJ 24/10 : Nvidia à mis en ligne une nouvelle version de son pilote baptisée 375.63 pour corriger principalement des problèmes sous Windows 10 au niveau du menu démarrer. Une version Windows 7 est également disponible mais le constructeur n'a pas, au moment ou nous écrivons ces lignes, posté de releases notes. Nous avons mis à jour les liens pour cette nouvelle version.

NVIDIA Logo 2010 Dans la foulée de son concurrent, Nvidia vient de mettre en ligne de nouveaux pilotes pour ses cartes graphiques. Cette version 375.57 apporte des optimisations pour les gros titres du moment, à savoir Civilization VI, Battlefield 1 et Titanfall 2.

Sans surprise ces pilotes apportent aussi des optimisations pour les mêmes jeux VR, à savoir Eagle Flight VR et Serious Sam VR.Nvidia ajoute également un profil SLI pour Lineage Eternal : Twilight Resistance.

Côté correctifs de bugs, les possesseurs de GTX 650 trouveront un correctif pour le jeu GTA V ou des points apparaissaient sur les personnages. Les utilisateurs de Windows 10 notteront des améliorations dans Overwatch (corruption de textures sur les décals) et Mirror's Edge Catalyst. Un crash système au passage de 144Hz à 240 Hz sur des moniteurs BenQ à également été corrigé.

Ceux qui le souhaitent trouveront plus de détails dans les release notes  (PDF). Le téléchargement s'effectue sur le site du constructeur :

GDC: D3D12, multi-GPU et frame pipelining

Publié le 25/03/2016 à 04:57 par Damien Triolet

Lors de la journée de la GDC consacrée aux tutoriaux liés à DirectX 12, organisée par AMD et Nvidia, c'est ce dernier qui s'est chargé de présenter la partie multi-GPU et de distiller des conseils d'utilisation réalistes pour le nouveau mode explicite. Les combinaisons exotiques laissées de côté, c'est le frame pipelining sur base d'une configuration de GPU identiques qui est mis en avant.

L'an passé, Microsoft a annoncé avoir intégré à DirectX 12 un support explicite très flexible pour le multi-GPU. Pour rappel, la nouvelle API conserve tout d'abord un mode implicite, similaire au SLI et CrossFire sous DirectX 11. Avec ce mode les pilotes sont censés se charger en toute transparence de donner vie au multi-GPU via le mode AFR.

Mais comme l'explique Nvidia, entre la théorie et la pratique il y a un gouffre et dans de plus en plus de cas le multi-GPU ne fonctionne pas, ou avec de très faibles performances, notamment quand des techniques de rendu dites "temporelles" sont exploitées. Celles-ci englobent toute approche qui a besoin de données issues d'images précédentes pour en calculer une nouvelle, par exemple certains filtres d'antialiasing. Vu que ces images précédentes ont été calculées par un autre GPU, ces données ne sont pas facilement accessibles.

Pour résoudre ce type de problème, et bien d'autres, DirectX 12 supporte une gestion explicite du multi-GPU. Cette fois il ne fonctionne plus automatiquement et il revient aux développeurs de prévoir leur moteur pour qu'il prenne conscience du nombre de GPU et les contrôle explicitement. Plusieurs possibilités existent alors.

Celle qui a fait le plus parler d'elle est le mode explicite non-lié (unlinked) qui permet d'associer tout type de GPU, de marques différentes, de génération différente et de niveau de performances différent. C'est le mode qu'a choisi d'implémenter Oxide dans Ashes of the Singularity, probablement pour pousser le plus loin possible ses expérimentations avec la nouvelle API, mais ce n'est pas celui qui va intéresser la majorité des développeurs, celui-ci impliquant la prise en compte de trop nombreuses combinaisons. Le multi-GPU est une niche du marché PC, ce qui implique que ce n'est pas sur ce point que les développeurs veulent investir le plus de temps en implémentation et en validation.

Reste alors le mode explicite à noeud lié (linked node), un noeud représentant un ensemble de GPU activé au niveau des pilotes. Autant AMD que Nvidia exposent un tel noeud dès que le CrossFire ou le SLI sont enclenchés dans leurs panneaux de contrôle. Attention, cela ne veut pas dire que le multi-GPU fonctionnera automatiquement ! Tout le contrôle reste dans les mains des développeurs mais ils ont alors l'assurance d'avoir affaire à des GPU identiques ou similaires, ce qui simplifie leur travail. Tout du moins pour le moment puisqu'il n'est pas impensable qu'AMD et Nvidia autorisent des noeuds hétérogènes dans le futur.

Ce mode explicite lié donne également accès à un lien dédié éventuel, soit au point SLI dans le cas des GPU Nvidia, AMD ayant abandonné le lien CrossFire au profit exclusif du PCI Express. Cet accès spécial n'est cependant exploité que si le multi-GPU implémenté est de type AFR. Le reste des transferts se fait via le bus PCI Express mais directement de GPU à GPU.

Les développeurs pilotent le multi-GPU à travers le multi engine, cette même fonctionnalité présente au coeur de DirectX 12 et qui permet de booster les performances à travers l'exécution concomitante de files de commandes (Async Compute). Il suffit de dédoubler la ou les files de commandes pour alimenter deux GPU.

D'ailleurs, pour maximiser les performances, il est important d'avoir recours à une file dédiée de type copy pour organiser les transferts entre GPU. De quoi effectuer ces opérations en parallèle du rendu 3D et en masquer le coût. Si les GPU Nvidia ont du mal avec les files graphics et compute, ils n'ont par contre pas de problème pour traiter simultanément des files graphics et copy, tout du moins dans le cas des GPU Maxwell 2 qui disposent de deux moteurs de transferts DMA. A ce point, nous ne savons pas si les GPU précédents qui s'en contentent d'un seul pourraient être affectés.

Nvidia rappelle ensuite qu'il existe différents tiers pour le partage de ressources à l'intérieur d'un noeud. Ce niveau de support est exposé à travers D3D12_CROSS_NODE_SHARING_TIER. Deux niveaux sont possibles : le tiers 1 ne supporte que les copies entre GPU alors que le tiers 2 autorise les accès à certaines ressources présentes dans la mémoire d'un autre GPU. Un dernier mode, le tiers 1 émulé est également proposé et consiste à implémenter dans les pilotes un mécanisme de transfert lorsque la copie directe de GPU à GPU n'est pas supportée.

Nous avons vérifié rapidement quel était le niveau de support proposé par AMD et Nvidia. Sur les GeForce Maxwell 2 il est de type tiers 2 alors qu'AMD se contente du tiers 1 sur GCN 1.1 et 1.2 (Hawaii et Fiji). Nvidia précise cependant que si les accès autorisés par le tiers 2 peuvent sembler pratiques, dans bien des cas il sera plus efficace d'effectuer une copie complète et de se contenter des fonctions du tiers 1.

Si exploiter le mode explicite lié peut permettre de faire de l'AFR (alternate frame rendering) avec un peu plus de flexibilité qu'en mode implicite, son intérêt réside surtout dans la possibilité d'implémenter d'autres modes de rendu, notamment pour résoudre les problèmes liés aux techniques qui font appel à une composante temporelle.

 
 

La solution à ces problème est appelée frame pipelining par Nvidia. Elle consiste à débuter le rendu d'une image sur un GPU et à transférer ces premiers éléments au second GPU en vue de la finalisation du rendu. Les GPU et leurs moteurs de copies travaillent alors à la chaine, d'où le nom de cette approche. Il est alors possible de prendre en charge sans problème un antialiasing temporel par exemple.

Pour mettre en place le frame pipelining, il faut parvenir à scinder son rendu en deux phases qui représentent une charge à peu près similaire et à un niveau qui permette de limiter les données à transférer. Il ne faut en effet pas oublier qu'un transfert de 64 Mo à travers un bus PCIe 3.0 8x prend au moins 8 ms, en général un peu plus en pratique. Pour éviter de transférer trop de données il peut alors être censé de dédoubler sur chaque GPU le calcul de certains éléments.

 
 

Dans l'exemple pris par Nvidia, le bi-GPU implémenté via le frame pipelining permet à la base de passer de 22 à 31 fps (+41%) et de monter à 37 fps (+68%) en exploitant le copy engine. Cet exemple est cependant un stress test en haute résolution (2160p) qui implique le transfert de la shadow map, du depth buffer et du SSAO, ce qui représente 87.3 Mo et prend à peu près 15 ms en PCIe 3.0 8x. Un temps de transfert qui limite le nombre de fps à +/- 60.

Le problème restant avec cette approche concerne la latence qui augmente à peu près comme en mode AFR. Le GPU1 effectue tout son travail, les données sont transférées puis le GPU effectue son travail. A 60 fps, et par rapport à un gros GPU de puissance équivalente, cela implique un triplement de la latence (de 16.7 ms à près de 50 ms). Heureusement, la partie liée au transfert de cette latence supplémentaire peut être masquée, exactement comme le fait Oxide pour le mode Async Compute d'AotS. Il suffit de décomposer le rendu en plus petits groupes de commandes et de transférer progressivement les éléments entre les GPU à travers le copy engine.

Reste bien entendu à voir ce que feront les développeurs de tout cela et à quel point AMD et Nvidia pourront les aider. Même si implémenter le frame pipelining en prenant en compte uniquement des ensembles de GPU similaires est plus simple que d'autres modes de rendus avec des combinaisons exotiques, cela représente un travail supplémentaire que tous n'accepteront probablement pas de prendre en charge. Et nous ne parlons mêmes pas des modes tri-GPU et quadri-GPU dont le support exigerait des développements complémentaires spécifiques…

Vous pourrez retrouver l'intégralité de la présentation de Nvidia ci-dessous :

 
 

Dossier : Nvidia GeForce GTX Titan Z : la carte graphique à 3000€ en test

Publié le 01/08/2014 à 17:24 par Damien Triolet

Nous avons enfin pu mettre la main sur la GeForce GTX Titan Z, la dernière carte bi-GPU de Nvidia, proposée à 3000€. Comment se comporte-t-elle face à la Radeon R9 295 X2 ? Sur le plan des performances ? Des nuisances sonores ?

[+] Lire la suite

Nvidia améliore le jeu en 4K avec les pilotes 327.23

Publié le 19/09/2013 à 17:10 par Damien Triolet

Nvidia vient de rendre disponibles les pilotes 327.23 WHQL, les premiers annoncés comme optimisés pour le jeu en 4K / UHD soit en 3840x2160. De quoi permettre à Nvidia de prendre une avance sur AMD à ce niveau, raison pour laquelle le premier n'a pas hésité à nous prêter un moniteur 4K Asus PQ321, le premier à devenir "presque" abordable (3500€) pour prouver ses dire. De quoi également justifier de l'utilité des systèmes multi-GPU ultra haut de gamme.

Les écrans 4K actuels fonctionnent en mode "tiled", c'est-à-dire que du point de vue du système ils représentent un ensemble de 2 écrans placés côte à côte. Connecter ces écrans peut se faire via 2 connections HDMI, chacune vers un écran virtuel de 1920x2160, ou via une seule connexion DisplayPort en activant le MST (Multi Stream Transport) qui permet de transférer deux signaux vidéo à travers un seul câble.


Autant Nvidia qu'AMD supportent ces deux types de connexions. Nvidia a cependant rendu leur configuration automatique grâce au support d'un nouveau standard VESA EDID : le DisplayID v1.3. Le driver se charge de créer la surface multi-écrans de 3840x2160 automatiquement, de manière à rendre son existence transparente à l'utilisateur. Du côté d'AMD, il faut créer une surface Eyefinity, ce qui est moins pratique mais ne pose aucun problème une fois la première configuration passée.

Nvidia insiste sur le fait que sa technologie de Frame Metering, qui permet d'assurer une cadence d'affichage régulière en SLI est fonctionnelle en 4K… contrairement à ce qui se passe chez la concurrence. Rien de nouveau cependant sur ce point puisqu'AMD a toujours indiqué que le Frame Pacing, qui a une action similaire, était dans un premier temps limitée au 2560x1600 en simple écran et que son support pour les autres résolutions arriverait progressivement.

Nul doute que Nvidia est pressé de communiquer sur ce point avant qu'AMD ne déploie le support du Frame Pacing pour la 4K. AMD nous a indiqué que son support était imminent et que nous en saurions plus lors de la présentation des futures Radeon qui aura lieu la semaine prochaine. Il n'aurait donc pas été pertinent de notre part d'analyser aujourd'hui en détail les performances en 4K des Radeon en CFX contre celles des GeForce en SLI. Nous pouvons cependant confirmer que la fluidité est très mauvaise en l'état sur les Radeon en CFX, ce qui rend cette résolution 4K difficilement exploitable.

Un autre problème potentiel existe en multi-GPU combiné au multi-écran : le tearing vertical. Vous connaissez tous les tearing horizontal, cette cassure dans l'image qui apparaît quand la synchronisation verticale est désactivée. Le tearing vertical apparaît, lui, quand le rafraîchissement de tous les écrans n'est pas fait exactement en même temps. Un problème simple à régler avec synchronisation verticale mais complexe quand elle est désactivée. Si ce problème était resté dans l'ombre jusqu'ici c'est parce que dans un système surround / multi-écrans classique, la bordure entre ceux-ci masque le phénomène.

Quand l'affichage multi-écrans se fait sur une seule dalle, la cassure verticale devient cependant visible, ce qui peut être gênant. Pour éviter ce problème, que nous avons rencontré sur Radeon avec les pilotes actuels, Nvidia a implémenté deux techniques : Fliplock et Scanlock. La première s'assure que les frames buffers de chaque écran (virtuels dans le cas du 4K), qui peuvent se situer dans la mémoire de différents GPU, basculent en même temps, de manière parfaitement synchrone. La seconde synchronise le transfert vers le système d'affichage.


Un exemple de tearing vertical.

Nvidia est ainsi le premier à offrir un support de qualité pour le jeu en 4K, la fluidité et le tearing étant bien maîtrisés. Reste bien entendu à assurer un niveau de performances suffisant : jouer en 4K natif n'est pas à la portée de toutes les cartes graphiques. Même une seule GeForce GTX Titan, en dehors des jeux anciens ou très légers, demandera en général de faire des compromis sur la qualité tels qu'il sera plus intéressant de baisser la résolution. Pour jouer en 4K aujourd'hui, il faut passer par la case multi-GPU. Voici ce que nous avons observé dans quelques jeux de notre protocole de test habituel avec 2 GeForce GTX 780 en SLI, en essayant d'obtenir un niveau de fluidité suffisant (50-60 fps) en 3840x2160 :

Anno 2070 : pas assez fluide en qualité maximale mais ok en très élevé
Battlefield 3 : ok en mode ultra avec MSAA 4x
Crysis 3 : pas assez fluide avec MSAA/SSAA ni en très élevé, mais ok en qualité élevée avec SMAA 1x
GRID 2 : ok en mode ultra avec MSAA 4x
Metro Last Light : ok en qualité très élevée à condition d'oublier le SSAA

De quoi confirmer que jouer en 4K est bel et bien possible avec un système multi-GPU haut de gamme, à condition en général de sacrifier l'antialiasing quand il est de type SSAA ou hybride MSAA/SSAA comme c'est le cas dans les jeux qui reposent sur un moteur de type rendu différé. Battlefield est l'exception sur ce point, il faut dire qu'il ne représente plus réellement de challenge pour les GPU actuels.

Est-ce utile de jouer en 4K ? Nous sommes toujours en train de forger notre avis sur ce point, notre temps de jeu dans ces conditions étant limité. Par rapport à un écran 30" en 2560x1600, jouer en 3840x2160 sur un écran 31.5" apporte un gain de finesse évident dans le rendu des jeux. Ce gain ne profite cependant pleinement qu'aux jeux qui proposent un rendu suffisamment riche et détaillé, comme c'est le cas dans Crysis 3 par exemple. Notez par ailleurs que malgré le gain en définition et en résolution, l'antialiasing reste selon nous utile. Sur un écran de 31.5" en 3840x2160, l'aliasing reste visible même si moins dramatique que dans d'autres conditions.

Nvidia devra cependant encore peaufiner quelque peu ses pilotes : durant nos premiers essais nous avons eu droit à 2 écrans noirs et à un problème d'activation du SLI au démarrage d'un jeu, résolu en revenant sur le bureau puis vers le jeu. A l'inverse, aucun des jeux cités ci-dessus n'était jouable sur un système CFX de Radeon HD 7970 GHz.

Reste à voir si cet avantage de Nvidia va perdurer dans le temps. AMD promet que non, mais mettre en place un contrôle de la cadence d'affichage en multi-écran est plus complexe puisque le transfert d'un GPU à l'autre se fait dans ce cas via le bus PCI Express et non via le connecteur CrossFire X. Par ailleurs la problématique du tearing vertical est nouvelle et demande une attention particulière. Nous ne savons pas si AMD pourra y apporter une solution générale pour tous ces GPU ou réservée à ses futurs produits. Les réponses à ces questions arriveront la semaine prochaine.

En attendant, un tiens vaut mieux que deux tu l'auras et la solution de Nvidia est fonctionnelle dès aujourd'hui pour les joueurs qui se sont sont jetés sur les premiers écrans 4K. Vous pourrez retrouver ces nouveaux pilotes GeForce 327.23 par ici .

Focus : Test GeForce GTX 580 3Go vs 1.5Go, SLI et surround

Publié le 25/08/2011 à 00:00 par Damien Triolet

   Alors que nous préparons un petit comparatif de GeForce GTX 580, nous avons voulu observer si les variantes 3 Go, qui se multiplient, présentaient un réel intérêt. Pour cela, nous avons effectué quelques tests en très haute résolution ainsi qu'en surround, le tout couplé à l'antialiasing, qui augmente significativement l'utilisation de mémoire vidéo.  

 

Les performances en haute résolution

Voici tout d'abord les résultats que nous avons obtenus en...

[+] Lire la suite

Top articles