Les contenus liés au tag AMD

En parallèle de la Titan Z de Nvidia qui exploitera deux GPU GK110 totalement fonctionnels (voir cette actualité), AMD devrait également proposer sous peu une carte graphique exploitant deux GPU Hawaii, une carte annoncée via un tweet pas vraiment cryptique du constructeur.

Attendue sous le nom de Radeon R9 295 X2, la carte semble s'être montrée sur le forum chiphell .


Pas vraiment de détails sur les caractéristiques au-delà de spéculations, mais l'on notera sur les deux photos ci-dessus que le constructeur aurait opté pour un système de refroidissement hybride liquide/air. On notera également la présence de deux connecteurs 8 broches sur la photo, permettant théoriquement de fournir chacun 150 watts (le port PCI Express permet également de récupérer 75 watts d'alimentation supplémentaires, pour un total supposé de 375 watts). Selon les rumeurs, le lancement pourrait s'effectuer durant la première moitié du mois d'avril.

Il y a une semaine de cela, nous évoquions l'arrivée sur une fiche technique de HP d'un « APU » assez spécial, un modèle Richland en FM2 utilisant une dénomination commerciale de « FX ». Un mélange des genres marketing pour le moins étrange, la marque FX n'ayant jamais été utilisée jusqu'ici sur des APU (avec partie graphique intégrée), et encore moins sur socket FM2.

La fiche technique de HP évoque un APU avec GPU intégré
AMD est revenu vers nous ce matin avec quelques précisions supplémentaires :

”The AMD FX-670K was configured by AMD to HP specifications for a unique HP offering. The part uses the AMD design codenamed “Richland”, found in many popular APU products. The AMD FX-670K is a package FM2 CPU which features four x86-64 cores running at 3.7 GHz base and 4.3GHz Turbo clocks, with a 65W TDP. The AMD FX-670K does not, as a CPU, offer APU graphics.”

AMD confirme plusieurs points importants, à commencer par le fait qu'il s'agissait bien d'un produit destiné uniquement aux OEM. L'autre point important concerne l'absence de la partie graphique, ce qui explique pourquoi, sur une autre carte mère, cette puce ne semblait pas en disposer. La fiche technique de Hewlett Packard était donc erronée et AMD nous a confirmé qu'elle serait corrigée rapidement. Le constructeur n'a pas répondu à la question de savoir si l'on retrouverait la marque FX à l'avenir dans des APU. Pour rappel, les marques Athlon et Sempron, réservées aux CPU jusqu'ici feront leur apparition dans quelques jours dans des APU sur la plateforme AM1.

S'il y a bien un mot qui était tabou lors de toutes les sessions de la GDC consacrées à Direct3D 12, c'était Mantle. Microsoft, Nvidia et même AMD ont tout fait pour éviter de devoir mentionner cette autre API de bas niveau. Direct3D 12 est-il le résultat de la sortie de Mantle ? Voici ce qui nous semble être la meilleure actuelle théorie sur le sujet…

Durant la GDC, seul Oxide a osé un timide acte de rébellion en déclarant que "porter leur moteur depuis d'autres API modernes était plus simple que de porter de Direct3D 11 vers Direct3D 12". A chacune de ces sessions pourtant, la première question qui était posée était systématiquement la suivante : "comment se compare Direct3D 12 à Mantle ?". Eclats de rire assurés dans la salle mais aucune réponse en retour.


Nvidia, de son côté, explique travailler avec Microsoft sur DirectX 12 depuis plus de 4 ans et en collaboration rapprochée depuis un an. C'est sans aucun doute autant la réalité qu'un baratin énorme pour éviter d'admettre avoir été poussé dans cette direction par l'API Mantle d'AMD.

Microsoft travaille constamment avec ses partenaires au sujet de possibles évolutions de ses API. La machine ne s'arrête pas quand DirectX 11 sort, les discussions et autres phases de recherche continuent. Quand Nvidia indique travailler depuis plus de 4 ans avec Microsoft sur DirectX 12, cela veut simplement dire que Nvidia a poursuivi sa collaboration avec Microsoft au-delà de DirectX 11, comme tous les autres fabricants de GPU. Cela ne veut pas dire que Nvidia travaille depuis 4 ans sur le Direct3D 12 qui est présenté aujourd'hui.

Nous ne pensons pas que le fait que la démonstration de Microsoft d'un prototype de portage vers Direct3D 12 de Forza Motorsport ait été réalisée sur un GPU Nvidia, la GeForce GTX Titan Black, soit un élément significatif. Il est logique que Microsoft opte pour un GPU Nvidia pour mettre en avant l'aspect universel de sa solution. Une démonstration sur un GPU AMD aurait entraîné plus de liens vers Mantle et l'architecture d'AMD puisque le code de base de Forza Motorsport provient de la Xbox One équipée en GPU AMD.

Après de très nombreuses discussions avec tous les acteurs impliqués, à la GDC mais également auparavant, nous sommes convaincus que Mantle a été le déclencheur et l'accélérateur de la direction retenue pour Direct3D 12, quoi qu'en dise Nvidia. Cela ne veut pas dire que Direct3D 12 est un clone de Mantle, mais qu'il semble bel et bien avoir été bâti sur les mêmes bases ou tout du moins fortement tiré dans la même direction. Des bases qui impliquent de transférer une partie significative de la responsabilité des performances et des optimisations du pilote vers le moteur du jeu. Bien sûr, ce n'est pas un monde en noir et blanc, tout le pouvoir ne passe du pilote au moteur de jeu, les deux restent importants mais l'équilibre est modifié en faveur du second.

C'est selon nous la clé pour comprendre la position de chacun et la chronologie des évènements. Il ne faut pas être naïfs, AMD et Nvidia n'opèrent pas de virage important par pure conviction technologique, tous ces choix se font également avec une bonne dose de politique et de stratégie.

Pourquoi AMD a-t-il sorti Mantle ? Parce que Nvidia dispose de la meilleure équipe de développement des pilotes. Pourquoi Nvidia aurait-il été réticent jusqu'alors à faire évoluer Direct3D vers un niveau d'abstraction plus bas ? Parce que Nvidia dispose de la meilleure équipe de développement des pilotes.

Plus une API graphique est complexe, prend des chemins torturés et accuse un surcoût ou overhead élevé, plus les fabricants de GPU ont d'opportunités de se démarquer de la concurrence via leurs pilotes. Cela ne veut pas spécialement dire qu'AMD et Nvidia font ou ont fait volontairement en sorte de complexifier les API, mais que les simplifier et transférer une plus grosse part de la responsabilité de l'optimisation vers les développeurs pose des questions stratégiques importantes qui peuvent les inciter à trainer des pieds face à certaines évolutions.


Les avantages d'une API de plus haut niveau, selon Nvidia.
Le travail important nécessaire pour obtenir des performances de premier plan, que ce soit globalement au niveau des pilotes ou spécifiquement au cas par cas pour chaque application, a permis à AMD et Nvidia de bénéficier de la sécurité d'un marché difficilement accessible à d'autres acteurs. Des sociétés telles que S3, Matrox, XGI etc. s'y sont cassé les dents, en partie pour cette raison. C'est également ce qui a permis à AMD et Nvidia de tenir Intel à l'écart.

Au cours de ses années les plus difficiles, AMD a dû se séparer de nombreux ingénieurs qui travaillaient sur ses pilotes alors même que Nvidia renforçait ses rangs. Même si AMD a récemment revu à la hausse ses investissements auprès du support des développeurs, il est évident que Nvidia dispose d'une force de frappe nettement plus importante sur le plan du développement des pilotes. AMD a probablement fini par prendre conscience du danger que cela pouvait représenter et revu sa stratégie en conséquence. Le réflexe qui pouvait être de trainer des pieds par rapport à un transfert de pouvoir des pilotes vers l'application n'avait plus lieu d'être. Au contraire, il a fini par devenir évident que pousser le marché dans cette direction serait utile pour la compétitivité de la société.

Pas facile cependant de convaincre tout le monde de bouger dans ce sens... Il nous semble évident que stratégiquement Nvidia n'avait au premier abord aucune raison d'abonder dans le sens d'AMD, et préférait opter pour d'autres approches de réduction du surcoût CPU, peut-être moins ambitieuses, qui lui auraient évité d'abandonner autant de contrôle sur les optimisations. Du côté de Microsoft il y avait probablement du pour et du contre, pas mal d'hésitation et d'avis contradictoires.

En développant et en concrétisant Mantle, avec le support de développeurs très enthousiastes, nous pouvons supposer qu'AMD a décidé de donner un coup de pied dans cette fourmilière. Le risque était limité. Dans le pire des cas, AMD pourrait bénéficier d'un mode spécifique dans quelques jeux, et dans le meilleur des cas, en profiter pour forcer la main des acteurs réticents de manière à pousser l'industrie dans une direction plus intéressante pour la société d'un point de vue compétitif.

De premiers résultats encourageants, l'engouement instantané de plusieurs développeurs pour les principes de Mantle (pas spécialement pour l'utilisation d'une API propriétaire !), la position délicate de la Xbox One, la menace de Steam OS, …, tout cela a mis en place une atmosphère qui a permis à tout le monde d'accepter d'aller vers un changement plus radical que certains ne le voulaient au départ pour Direct3D 12. Au final, avec Mantle, AMD a pu influencer significativement Direct3D 12, en plus d'apporter un bonus dans quelques jeux pour les utilisateurs de Radeon, ce qui est toujours bienvenu sur le plan commercial.

Sur la base de la même réflexion, nous pouvons supposer qu'OpenGL ES va évoluer rapidement vers une version à overhead réduit, alors qu'il sera beaucoup plus lent et difficile de faire évoluer OpenGL dont l'importance dans le monde professionnel en fait un élément stratégique crucial. Un responsable du développement d'un des moteurs de jeux majeurs nous a d'ailleurs confirmé qu'un tel OpenGL ES était déjà sur la table.

Nous pouvons par contre supposer que Nvidia sera extrêmement prudent par rapport à une évolution d'OpenGL qui pourrait impacter son très rentable marché professionnel. Même si la tendance va de plus en plus vers une exploitation de toute la puissance des GPU, de nombreuses applications professionnelles liées à la 3D restent fortement limitées par le CPU et les performances du pilote. Une caractéristique qui, comme vous pourrez l'imaginer, fait bien les affaires de Nvidia.

Nos confrères de Guru 3D  ont repéré un thread du forum  de Hardware Canucks ou a été posté une capture d'un processeur assez particulier, un AMD FX 670K… pour socket FM2. Ce processeur a été trouvé dans une machine HP Pavillon 500-266ea dont la fiche technique le présente comme APU FX-670K avec Radeon HD 8670D intégrée, pour une fréquence de 3.7 GHz, quelque chose qui ressemble à première vue à un APU Richland A10-6700.

On se souviendra qu'il existe bien un APU Richland avec un nom proche, l'Athlon X4 760K lancé en juin dernier et qui – comme tous les Athlon jusqu'ici – est dépourvu de GPU intégré. La fréquence ne semble cependant pas correspondre, 3.7 GHz contre 3.8 GHz et d'après la fiche technique d'HP, cet APU « FX » aurait bel et bien son GPU intégré d'actif ce qui n'est pas le cas de l'Athlon.

Quelque chose qui reste cependant à vérifier puisque branché sur une autre carte mère, cet APU un peu spécial ne voit pas son GPU intégré reconnu. S'agit-il d'une erreur sur la fiche technique d'HP, ou d'un problème de détection par la carte mère de cette référence jusqu'ici inconnue ?

Nous avons contacté AMD pour essayer d'en savoir plus et dans l'attente de leur réponse, on ne peut que s'étonner des choix de nommages récents opérés par le constructeur. S'il n'est pas rare de voir des processeurs « originaux » dans des machines OEM, l'utilisation de la marque FX pour un APU est une nouveauté. Ce n'est pas le premier mélange de marque qu'opère AMD ces derniers temps, on se souvient aussi de l'annonce de la plateforme AM1 en début de mois ou des APU Kabini desktop seront vendues sous les marques Sempron et Athlon, avec GPU intégré. On notera d'ailleurs que les Athlon AM1 commencent à être disponible outre atlantique d'après nos confrères de CPU-World  qui les ont repérés. Le lancement officiel de la plateforme avait été annoncé par AMD pour le début du mois d'avril.

Comme prévu Microsoft vient de lever le voile sur sa future API DirectX 12 ou pour être plus précis sur sa composante graphique Direct3D 12. Lors de la première session consacrée au sujet, Microsoft n'est pas rentré dans le détail et s'est contenté de nous donner les grandes lignes de son API. Des grandes lignes qui correspondent à ce qu'AMD propose avec son API propriétaire Mantle.

Direct3D 12 propose un niveau d'abstraction plus bas que les précédents Direct3D, la responsabilité du contrôle du GPU se retrouve alors en partie transférée de l'API et des pilotes vers l'application et les développeurs. Le premier intérêt est de réduire le surcoût CPU de la gestion des états et du rendu 3D en lui-même. L'API et les pilotes ont moins de vérifications à faire, ce qui réduit la pression au niveau du CPU. Par ailleurs, regrouper une grosse partie du contrôle en un seul endroit, l'application, permet d'enfin exploiter le multithreading de manière efficace. Actuellement, le développeur ne sait pas ce que vont faire de ses commandes le pilote et l'API et il lui est donc impossible de prévoir un multithreading efficace.




Plus spécifiquement, Direct3D 12 va tout d'abord réduire le coût des changements d'états à travers des "pipeline state objects", sorte d'empreinte de l'état du GPU pour un type de tâche particulière. De quoi pouvoir préparer les changements d'états en amont et appliquer ces changements en bloc. Ensuite, Direct3D 12 fait appel au concept de "bundles", des groupes de commandes de rendu liés à un objet particulier de la scène qui, une fois préparés, pourront être stockés en cache et réutilisés autant de fois que les développeurs le jugent nécessaire, que ce soit à l'intérieur d'une même image ou dans des images successives. Direct3D 12 supporte également un nouveau modèle de listes de commandes asynchrones pour faciliter le bon support du multithreading, une gestion des ressources plus flexibles, mieux adaptée aux GPU modernes etc.

Tout cela est très proche voire identique à ce que fait AMD avec Mantle. Oxide Games estime d'ailleurs que les performances de son renderer Direct3D 12 seront similaires à celles de son renderer Mantle.


Direct3D 12 apportera également quelques nouvelles fonctionnalités, mais ce n'est pas l'objectif principal. Sans rentrer dans le détail, Microsoft cite par exemple le support du blending programmable, d'un OIT (order independant transparency) efficace ou encore d'une rastérisation conservative.

Microsoft a tenu à donner un exemple de la différence que peut faire Direct3D 12 en se basant sur 3DMark 11, dont le code lui a été fourni par Futuremark :



D3D11 à gauche, D3D12 à droite
Comme attendu, Direct3D 12 permet de réduire drastiquement le temps CPU qui est réduit par 2 sur la partie graphique. Plus important, le thread principal se retrouve nettement allégé au niveau de l'API et des pilotes (UMD et KMD), cette fois d'un facteur 5x. Un tel exemple met en avant la possibilité d'exploiter mieux de "petits" CPU multicores.


L'autre démonstration de Microsoft concernait le portage de Forza Motorsport de l'API D3D11.X de la Xbox One vers D3D12. Celui-ci aurait été très rapide, l'équivalent du temps de travail de 4 ingénieurs sur un mois.

Ensuite, lors de cette première session consacrée à Direct3D 12, Microsoft a tenu à inclure ses partenaires en les invitant tour à tour à prendre la parole et en organisant une improbable photo de famille de tous ces concurrents :


De gauche à droite, Chris Tector (Forza Motorsport, Microsoft), Anuj Gosalia (Microsoft), Eric Mentzer (Intel), Raja Koduri (AMD), Tony Tamasi (Nvidia), Eric Demers (Qualcomm, ex-ATI/AMD).
Tour à tour et par ordre alphabétiques, chacun a expliqué apprécier avoir travaillé en étroite collaboration avec Microsoft et abordé la question du support de cette future API :

AMD :


Du côté d'AMD, qui a évité de prononcer le mot Mantle durant cette présentation, le support concernera tous les GPU depuis la première génération GCN, soit les Radeon HD 7000 (hors renommages), HD 8000, R200 et supérieures.

Intel :

Intel souligne qu'il s'agit de la plus grosse évolution de ces dernières années. Si Intel a largement profité dans le monde PC de l'inefficacité de Direct3D pour justifier l'utilisation de ses CPU les plus performants, une API plus efficace l'intéresse également puisque cela va permettre de libérer ses GPU lorsque l'enveloppe thermique est limitée. Si les cores CPU peuvent se contenter d'une fréquence plus faible, cela laisse plus de marge pour le turbo du côté GPU. Le support de Direct3D 12 sera assuré pour tous les processeurs Core à partir de la 4ème génération (Haswell).

Nvidia :



Nvidia est probablement le fabricant qui devrait proposer le plus large support de Direct3D 12 pour ses anciens produits puisque cela concernera les générations Fermi, Kepler et Maxwell. De quoi permettre à Nvidia d'estimer qu'à sa sortie, le parc compatible Direct3D 12 sera à 40% composé de GeForce.

Nvidia indique avoir travaillé en étroite collaboration avec Microsoft depuis un an sur Direct3D 12 (la démonstration de Forza Motorsport tournait d'ailleurs sur une GeForce GTX Titan Black), et termine par citer Epic Games, un partenaire proche, qui annonce qu'ils travailleront main dans la main avec le fabricant de GPU pour porter l'Unreal Engine sous DirectX 12.

Qualcomm :

Enfin, Qualcomm explique voire dans Direct3D 12 de nouvelles opportunités d'augmenter le rendement énergétique, la priorité pour le fabricant de SoC. Ce dernier nous avait par ailleurs indiqué précédemment que les GPU Adreno 4xx, tels que l'Adreno 420 présent dans le Snapdragon 805, seraient compatibles avec ce nouveau Direct3D.


Au final, à partir de ce jour, Microsoft estime que tous les nouveaux GPU PC supporteront Direct3D 12, que 80% des nouveaux PC destinés aux joueurs supporteront Direct3D 12 et que 50% des joueurs seront équipés de matériel adapté lorsque l'API sera disponible. La Xbox One sera bien entendu compatible. Microsoft ne donne aucune information par rapport aux niveaux de fonctionnalités matérielles mais il est probable que tous les GPU compatibles Direct3D 12 n'en supportent pas toutes les fonctionnalités.

Malheureusement, il faudra encore patienter un petit peu pour cela. Dans l'immédiat, Microsoft propose un accès à une beta au cas par cas aux développeurs qui en font la demande et prévoit une préversion publique pour la fin de l'année. Le but visé par Microsoft concerne les jeux de Noël 2015, mais pour quel OS ? Un point que le géant de Redmond n'est pas encore prêt à aborder mais il est possible, sur PC, que passer à Windows 9 sera obligatoire pour profiter de DirectX 12 et Direct3D 12. De futures versions de Windows adaptées aux tablettes et aux smartphones profiteront elles aussi de cette API.

D'après le timing de Microsoft, AMD devrait encore disposer d'une fenêtre de plus d'une année pour profiter des avantages de Mantle. Et au vu de la proximité apparente entre les deux API, les développeurs devraient pouvoir réutiliser une grosse partie du travail fait autour de l'API propriétaire d'AMD.