Les contenus liés au tag CrossFire

Afficher sous forme de : Titre | Flux Filtrer avec un second tag : AMD; DirectX 12; GeForce; GeForce GTX 590; Radeon; Radeon HD 6990; Radeon HD 7990; Radeon Software; SLI; Surround gaming;

Pilotes AMD Radeon Software 16.8.1 beta

Publié le 10/08/2016 à 11:45 par Guillaume Louel

AMD a mis en ligne une nouvelle version beta de ses pilotes Radeon Software pour cartes graphiques. La nouveauté principale est le support des dernières Radeon RX470 et RX460, mais l'on y retrouve aussi un bon nombre de correctifs.

Les possesseurs de Radeon RX480 noteront la fin des crashs sous Overwatch en mode Crossfire, la possibilité d'overclocker la mémoire sous WattMan, et la correction des ralentissements sous Wolfenstein : The Old Blood.

D'autres correctifs génériques sont au programme, pour The Division par exemple en mode Crossfire qui scale désormais mieux dans les résolutions les plus basses, et de meilleures performances sous DOTA2 toujours en Crossfire.

On notera enfin que l'accélération matérielle du décodage pouvait faire planter Firefox, un bug désormais corrigé.

Comme toujours, vous pourrez retrouver ce téléchargement directement sur le site du constructeur .

AMD lance la Radeon Pro Duo à 1650€

Publié le 26/04/2016 à 15:16 par Damien Triolet

Annoncée le mois dernier à l'occasion de la GDC, c'est aujourd'hui que la Radeon Pro Duo est officiellement lancée. Fabriquée en petites quantités, cette carte bi-GPU est positionnée sur le segment de la réalité virtuelle et introduite à pas moins de 1650€.

 
 

Comme nous l'expliquions lors de l'annonce de la Radeon Pro Duo, l'intérêt des cartes bi-GPU est discutable, tout comme le multi-GPU en lui-même, d'autant plus en cette période où son support dans les jeux est plus qu'aléatoire. Les titres qui ne proposent que des gains réduits, demandent de désactiver certains effets graphiques ou ne supportent pas du tout le multi-GPU sont actuellement trop nombreux pour que ce type de solution puisse être conseillée aux joueurs sans de très lourdes réserves.

Face à cette situation, AMD et Nvidia ont longtemps hésité à proposer une solution bi-GPU ultra haut de gamme. Ce dernier a d'ailleurs fini par abandonner l'idée d'une carte basée sur 2 GPU GM200, l'expérience de la GTX Titan Z à 3000€ ayant de toute évidence été une bonne leçon. AMD par contre était bien décidé à lancer une telle carte graphique mais pas dans n'importe quelles conditions.

Si le but reste évidemment toujours l'argument de la première place en termes de performances brutes, ce n'est pas sous cet angle aux résultats potentiellement très mauvais, suivant les jeux testés, qu'AMD veut présenter son nouveau bébé. D'autant plus qu'il souffre d'une limitation plutôt gênante pour les très hautes résolutions : sa solution ne peut embarquer que 4 Go de mémoire par GPU.

Face à des jeux qui peinent à supporter le multi-GPU et face à une limite de 4 Go qui ne correspond pas aux résolutions extrêmes, AMD a décidé de réorienter sa carte bi-Fiji vers la réalité virtuelle (VR). Ce type de rendu est capable de profiter plus facilement du bi-GPU et a plus besoin de performances que de mémoire vidéo. Reste que si le support efficace est plus simple, il demande un développement spécifique qui n'est pas encore intégré dans la plupart des applications grand public.

Au final ce n'est pas simplement la VR que vise AMD mais bien la niche des systèmes de développement et de démonstration dédiés à la VR. AMD en profite d'ailleurs pour introduire une nouvelle certification : VR Ready Creator. Une solution qui du coup rentre dans la catégorie semi-pro, à la manière des GeForce Titan. Pour cela AMD a décidé de nommer sa carte Radeon Pro Duo. Et bonne nouvelle, contrairement à Nvidia avec les GeForce Titan, AMD va jusqu'au bout de ce positionnement hybride et proposera au choix les pilotes Radeon classiques ou les pilotes FirePro.

Bien entendu, les joueurs qui recherchent la carte graphique la plus rapide du moment restent une cible, mais une cible non-avouée par crainte de voir des tests orientés dans ce sens. Contrairement à son approche habituelle, AMD a fortement limité le nombre d'échantillons de test disponibles pour les médias tels que Hardware.fr.

 
 

Pour la Radeon Pro Duo, AMD reprend un design similaire à celui de la R9 Fury X. Un système de watercooling spécifique a été développé et se charge de refroidir les 2 modules Fiji + HBM ainsi que leurs étages d'alimentation. Le radiateur reste de type 120x120mm mais gagne en épaisseur. Un PCB musclé a été mis au point avec pas moins de 3 connecteurs 8 broches, de quoi autoriser jusqu'à 525W. En pratique cependant, AMD se contente d'une limite inférieure.

Au niveau des spécifications, la Radeon Pro Duo ressemble comme deux gouttes d'eau à une double Radeon R9 Nano. AMD parle d'une spécification typique de 350W, qui correspond à priori à une consommation maximale de +/- 380W et à 150W par module Fiji + HBM, comme sur la Radeon R9 Nano.

C'est relativement peu par rapport à la limite du même module sur les R9 Fury X, fixée à 300W, ce qui implique que les GPU Fiji de la Radeon Pro Duo évolueront souvent sous leur fréquence maximale de 1 GHz, ce qui nous avons voulu souligner en présentant les débits de ces cartes à 850 MHz, fréquence que nous observons régulièrement sur la R9 Nano. Ce type de comportement est normal pour les GPU modernes, c'est ce qui permet de booster leur rendement énergétique.

La Radeon Pro Duo sera disponible dans les jours qui viennent au tarif de 1650€. C'est beaucoup par rapport à une paire de Radeon R9 Nano et comme vous pouvez vous en douter, les volumes seront faibles. Selon nos informations la production mondiale serait inférieur à 3000 pièces dont seulement quelques dizaines seraient prévues pour la France.

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 :

 
 

Focus : CrossFire et Radeon R9 Fury X, Fiji vs GM200, round 2 !

Publié le 29/06/2015 à 21:00 par Damien Triolet

Ayant eu l'opportunité d'avoir deux Radeon R9 Fury X à notre disposition, nous avons bien entendu voulu observer comment elles se comportaient en CrossFire face aux GeForce GTX 980 Ti en SLI.

Mise en place

Bien que les cartes soient très courtes, le recours au refroidissement à base de watercooling AIO complique quelque peu l'installation d'un système CrossFire (CFX) à base de deux Radeon R9 Fury X (ou plus). Chaque carte graphique conserve son circuit dédié ce qui implique de parvenir à placer plusieurs...

[+] Lire la suite

DirectX 12 supportera un mix de GPU

Publié le 02/05/2015 à 04:51 par Damien Triolet

Microsoft avait réservé pour sa conférence Build 2015 les détails concernant une énième nouvelle fonctionnalité de Direct3D 12 : le support explicite du multi-GPU. Il ouvre en théorie la voie aux combinaisons de tous types de GPU, y compris de marques différentes, mais la pratique ne sera pas aussi simple.

Direct3D 12, la composante graphique du prochain DirectX, supportera plusieurs modes de multi-GPU (multiadapter). Le premier est un mode de multi-GPU implicite, similaire à ce qui est utilisé actuellement par AMD et Nvidia sous Direct3D 11 ou OpenGL pour supporter le CrossFire et le SLI. Avec ce mode, les développeurs n'ont pas trop à se soucier du multi-GPU, les pilotes se chargeant de son support de façon à peu près transparente, même s'ils doivent faire en sorte qu'il n'y ait pas de dépendance entre les images, puisqu'il s'agit en général d'un rendu des images en alternance (AFR).


La nouveauté c'est le support du mode multi-GPU explicite, ou plutôt des modes explicites. Dans ces cas de figures, le contrôle du multi-GPU revient aux développeurs qui pourront en faire à peu près tout ce qu'ils veulent. Ce support est basé sur l'extension de la gestion par Direct3D de différents moteurs pour piloter un GPU (graphics, compute, copy), fonctionnalité qui permet pour rappel de profiter du parallélisme entre différents types de tâches, comme expliqué ici. En multi-GPU explicite, ces différents moteurs seront exposés pour chaque GPU.

A partir de là, deux sous modes peuvent être exploités. Le multi-GPU explicite lié (linked) est proche des CrossFire et SLI actuels (il en exploite le moteur de composition), si ce n'est que les développeurs prennent le contrôle. L'ensemble est vu comme un seul gros GPU qui dispose de plus de moteurs de types graphics, compute et copy. Ce mode pourrait par exemple permettre de supporter plus facilement un rendu de type AFR malgré certaines dépendances entre images. Microsoft n'est pas rentré dans les détails à ce niveau et s'est contenté d'indiquer qu'ils seraient communiqués plus tard. Nous ne savons pas non plus si AMD et Nvidia conserveront la mains sur les combinaisons supportées (par exemple 2 GTX 980 et pas GTX 980 + GTX 970).

Enfin, le multi-GPU explicite non-lié (unlinked) est le mode qui autorise tout type de combinaisons de GPU. Direct3D 12 est très flexible et permet aux développeurs de gérer les synchronisations entre GPU, leurs mémoires respectives, des buffers distincts ou partagés, les transferts entre GPU… Bref de quoi faire à peu près tout ce qui peut leur passer par la tête pour exploiter tous les GPU du système.

De quoi imaginer la combinaison d'une GeForce avec une Radeon ? Oui et non. C'est théoriquement possible, mais en pratique différents problèmes vont se poser, que ce soit en termes de performances via les optimisations spécifiques des pilotes, ou en termes de qualité avec de petites différences dans le rendu des images (notamment au niveau du filtrage des textures ou de l'antialiasing) qui vont entraîner un clignotement. Des modes de types AFR ou SFR avec un mix de GPU ne sont donc pas réalistes, tout du moins pour l'instant.

Rappelons cependant que dans la documentation de Mantle, nous avons pu découvrir qu'AMD avait prévu un mécanisme pour demander à ses cartes graphiques de rentrer dans un mode "neutre" en terme de qualité de manière à uniformiser le rendu autant que possible entre des GPU Radeon différents. Dans le futur ce principe pourrait être étendu à Intel et Nvidia, mais mettre tout le monde d'accord ne sera pas simple, d'autant plus que l'intérêt commercial sera limité.

Dans l'immédiat, l'utilisation réaliste du multi-GPU explicite non-lié est différente. Il s'agit plutôt de faire traiter par chaque GPU différentes étapes du rendu, ce qui évite tout souci de qualité et de clignotement. C'est d'ailleurs ce qu'a choisi d'illustrer Microsoft qui a pour l'occasion modifié quelque peu l'Unreal Engine 4 de manière à déporter certaines tâches d'une carte graphique Nvidia vers un GPU intégré Intel.


Dans cette démonstration, le plus gros du rendu est traité par la carte graphique mais la fin du post processing est traitée par le GPU Intel qui se charge ensuite de l'affichage. Travailler de la sorte au niveau du post processing permet d'exploiter toute la puissance de calcul disponible en minimisant les échanges de données via le bus PCI Express puisqu'il suffit en gros de transférer le frame buffer et le Z-Buffer.

Choisir où scinder le rendu est essentiel pour s'assurer qu'il y ait bel et bien un gain de performances. Microsoft explique à ce sujet avoir fait en sorte que le GPU intégré prenne toujours moins de temps à faire son travail que la carte graphique. Celle-ci reçoit un coup de boost mais reste l'élément qui définit les performances.


Plus spécifiquement, l'opération permet de passer de 35.9 à 39.7 fps, soit un gain de 10%. En observant de plus près cet exemple, il apparaît que le GPU intégré prend beaucoup plus de temps pour traiter la partie finale du post processing que la carte graphique, mais ce dernier n'ayant rien d'autre à faire, cela permet un gain de performances. C'est probablement surtout vrai pour les GPU d'entrée voire de milieu de gamme (Microsoft ne précise pas la configuration) alors qu'il serait peut-être contreproductif de vouloir aider une GeForce GTX Titan X avec un GPU intégré.

Par contre, il y a un désavantage évident à cette technique qui apparaît sur ce graphique : elle augmente la latence. Dans l'exemple de Microsoft, la partie de la latence liée au rendu passe de 28ms à plus ou moins 45ms quand le GPU intégré entre en action. Suivant le mode d'affichage, cela peut correspondre à l'ajout de l'équivalent d'une image de latence, ce qui ne plaira pas aux joueurs exigeants sur ce point.

Du coup est-ce bien utile pour les développeurs de jeux vidéo d'essayer de proposer ce type d'optimisations ? Une démonstration telle que celle de Microsoft est relativement facile à mettre en place grâce à Direct3D 12, mais dans la pratique, sur PC, il y a un nombre énorme de combinaisons possibles à prendre en compte pour que l'opération ne soit pas contre-productive. Et mettre en place un système de load balancing automatique dans les moteurs est loin d'être simple, même si ce n'est pas impossible.

Dans l'immédiat, il nous semble donc probable que cette possibilité de mélanger différents types de GPU reste avant tout dans la zone d'expérimentation pour les développeurs de jeux vidéo, même si les gros moteurs graphiques pourraient la supporter rapidement. Un peu plus tard, la première utilisation commerciale pourrait concerner certains PC d'entrée de gamme. Nous pensons par exemple aux plateformes Dual Graphics d'AMD (APU + GPU) ou encore aux portables Optimus de Nvidia (GeForce associée à un GPU Intel). Avec un petit effort de la part des développeurs de jeux vidéo, AMD et Nvidia pourraient prendre le relais avec des profils adaptés pour booster certaines de leurs plateformes.

Vous pourrez retrouver ci-dessous l'ensemble des slides de la présentation de Microsoft effectuée lors de la Build 2015 (section multiadapter à partir de la page 11) :

 
 

Top articles