Les derniers contenus liés au tag GCN

Afficher sous forme de : Titre | Flux Filtrer avec un second tag : AFDS; AMD; APU; FirePro; Hawaii; Mantle; R9 290X; Radeon; Radeon HD 7000; Radeon R9;

AMD lance les Bristol Ridge desktop OEM

Publié le 05/09/2016 à 17:50 par Guillaume Louel

Après avoir annoncé les versions mobiles en juin, AMD lance aujourd'hui la version desktop de ses APU de "7ème génération", les Bristol Ridge. Le lancement s'est fait par le biais d'un simple communiqué de presse  en ce jour férié aux Etats-Unis.

Le lancement est pourtant important puisque c'est en simultanée la première apparition de la nouvelle plateforme AM4 d'AMD, qui acceuillera non seulement les Bristol Ridge, mais également les Zen Summit Ridge. Une apparition toute relative puisque ce lancement est réservé aujourd'hui uniquement aux OEM.

Par rapport aux APU desktop précédentes (Kaveri/Godavari), on trouve un peu plus de changement que côté mobile, en grande partie parce que Carrizo (duquel Bristol Ridge est très très proche) n'avait pas été décliné sur le socket FM2+.

On reste bien entendu sur l'architecture Bulldozer, mais dans sa version Excavator contre SteamRoller précédemment, tandis que côté graphique on passe à la version 3 de GCN. De quoi proposer des gains d'efficacité par rapport a Kaveri... lancé début 2014.

Cela permet à AMD de faire baisser le TDP : bien que l'on reste en 28nm, ces nouvelles APU sont annoncées pour 65 watts. Le modèle le plus haut de gamme, l'A12-9800 est cadencé à 3.8/4.2 GHz pour ses deux modules (4 coeurs), et 1108 MHz pour les 8 CU côté graphique. Des versions 35 watts sont également lancées.

Les Bristol Ridge sont pour rappel des SoC et intègrent entre autre 8 lignes PCIe Gen3, la gestion de quatre ports USB 3.0 ainsi que 2 SATA et deux lignes PCIe Gen3 supplémentaires pouvant être utilisées pour des ports NVMe. AMD lance en simultanée deux chipsets, les A320 (!) et B350 qui rajoutent des ports USB, y compris des ports 3.1 ainsi qu'un plus grand nombre de ports SATA et de lignes PCIe. Un modèle spécifique "Enthusiast" sera annoncé plus tard, on l'imagine à l'occasion de la sortie de Zen.

AMD indique que ces puces seront disponibles dans un premier temps uniquement dans des configurations HP et Lenovo, et que d'autres OEM suivront.

Le communiqué de presse évite par contre la question d'une disponibilité de ces puces en dehors des OEM, ce qui élude la question du prix (la liste de prix d'AMD  n'a pas encore été mise à jour au moment ou nous écrivons ces lignes).

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

 
 

AMD annonce Polaris, sa future architecture GPU

Publié le 04/01/2016 à 15:00 par Damien Triolet

Enfin, après 4 années de GCN en 28nm, les Radeon vont accueillir une nouvelle architecture gravée en 14nm : Polaris. Et pour AMD le focus se portera sur l'efficacité énergétique avec un bond en avant annoncé sans précédent !


Le Radeon Technology Group d'AMD profite de ce début d'année pour lever un (très petit) coin du voile qui entoure sa prochaine génération de GPU, notamment en donnant un nom de code à son architecture : Polaris (l'étoile polaire). Et pour positionner sans équivoque ses objectifs avec cette architecture, AMD explique avoir opté pour ce nom de code en faisant le parallèle entre l'efficacité des étoiles à générer des photons et l'efficacité demandée aux GPU pour générer des pixels.

Comme vous le savez, l'architecture actuelle des Radeon est globalement en retrait par rapport à l'architecture Maxwell de Nvidia au niveau de l'efficacité énergétique. Fort de larges parts de marché et ayant bien anticipé le très long passage par le procédé de fabrication 28nm (exploité pour les GPU depuis 4 ans déjà !), Nvidia a développé deux architectures pour celui-ci : Kepler et Maxwell. En face, AMD est resté sur une architecture GCN moins efficace en se contentant d'évolutions mineures de son cœur. Pourquoi ? Probablement parce que, contrairement à Nvidia, AMD avait parié sur l'exploitation d'un procédé en 20nm qui ne s'est jamais concrétisée pour les GPU.

Tout cela va enfin changer en 2016 avec l'arrivée de GPU fabriqués en 16nm FinFET+ chez TSMC et en 14nm LPP chez GlobalFoundries et Samsung. Ces nouveaux procédés de fabrication ont pour point commun de donner enfin aux GPU l'accès à la technologie FinFET, de quoi donner un coup de pied dans une fourmilière bien trop tranquille à notre goût !

Introduit par Intel en 2012 sous les noms de "transistors tri-gates" ou de "transistors 3D", le FinFET se détache de la construction planaire classique des transistors en donnant une troisième dimension à la porte ce qui permet d'en augmenter la surface de contact et de mieux l'isoler. Les courants de fuite, qui peuvent représenter une grosse partie de la consommation d'un transistors classique, sont alors nettement réduits.


Autant, voire plus, que la finesse de gravure, c'est ainsi le passage au FinFET qui autorise une avancée significative dans les performances des transistors, ce qui peut se traduire par un gain de fréquence, une nette réduction de la consommation ou un mélange de ces deux points selon le positionnement de la puce. Autre avantage selon AMD, le FinFET permet d'obtenir un comportement plus homogène de l'ensemble des transistors, ce qui réduirait la variabilité dans les échantillons produits.

Comme c'est traditionnellement le cas pour les Radeon, c'est lors de ce changement de process qu'AMD va introduire une évolution significative de son architecture GPU, sur laquelle le Radeon Technology Group va bien entendu vouloir communiquer. Et pour cela il faut pouvoir lui mettre un nom.

La nomenclature des architectures GPU d'AMD, ou plutôt son absence, a été source de confusion ces dernières années. En l'absence de communication d'AMD, nous avons ainsi fait référence à GCN 1.1 et GCN 1.2 pour parler des petites évolutions apportées depuis la Radeon HD 7970 de décembre 2011. AMD préfère cependant concentrer le terme GCN sur les unités de calcul du GPU (ses "cœurs"), d'autres éléments du GPU pouvant évoluer indépendamment. Polaris représente ainsi le nom global de la nouvelle architecture et GCN 4 la nouvelle version de ses unités d'exécution (après GCN 1 / 1.0, GCN 2 / 1.1 et GCN 3 / 1.2).

Raja Koduri, qui dirige Le Radeon Technology Group, nous a indiqué vouloir faire en sorte que les cartes graphiques qui embarqueront un GPU de type Polaris soient clairement identifiables. Pragmatique et réaliste, il est bien conscient qu'avec une éventuelle future gamme de cartes graphiques, il pourra être difficile pour ses équipes de résister à la tentation d'y intégrer d'anciens GPU. Il sera ainsi important de permettre aux GPU Polaris d'être mis en avant de manière explicite.


Avec Polaris, à peu près tous les blocs du GPU vont être mis à jour. Nous vous avons déjà parlé de l'aspect affichage et vidéo le mois passé. Pour rappel, les GPU Polaris supporteront le HDMI 2.0a, le DisplayPort 1.3 et le décodage des vidéo 4K en H.265.

Les processeurs de commandes (grahiques et compute), les processeurs géométriques, le cache L2 et le contrôleur mémoire seront également revus pour accompagner le passage aux Compute Units (CU) de type GCN de 4ème génération. Sur ce dernier point AMD précise que Polaris pourra supporter soit un bus GDDR5 soit un bus HBM, suivant les GPU.

Malheureusement, AMD en dit très peu sur les évolutions et ne donne que ces quelques maigres détails :


AMD indique tout d'abord que le cœur de l'architecture a été amélioré pour une meilleure efficacité énergétique. Comme Nvidia a commencé à le faire à partir de la génération Kepler, nous pouvons supposer qu'AMD va essayer de ne plus avoir besoin d'une logique d'ordonnancement complexe et gourmande à l'intérieur des CU, là où le comportement d'une suite de certaines instruction est totalement déterministe et peut donc se contenter d'un ordonnancement statique préparé lors de la compilation.

AMD parle également d'amélioration des ordonnanceurs matériels, mais cette fois nous supposons qu'ils ne font pas référence aux CU mais au front-end et aux tâches globales initiées par les processeurs de commandes. Il s'agit ainsi probablement d'améliorations destinées au support du multi-engine de Direct3D 12. Il est également question de nouveaux modes de compression. Il pourrait s'agir de la compression ASTC, coûteuse à implémenter (mais le 14nm règle ce problème) et qu'AMD et Nvidia avaient évité jusqu'ici, contrairement aux concepteurs de GPU pour SoC pour lesquels quelques transistors de plus ne sont jamais trop chers payés pour économiser de la bande passante mémoire et de l'énergie.

Enfin, AMD mentionne un Primitive Discard Accelerator, soit un système d'éjection des triangles masqués du pipeline de rendu. Pour rappel, statistiquement, à peu près la moitié des triangles d'un objet tournent le dos à la caméra et peuvent être éjectés du rendu dès que cet état est confirmé. Pouvoir le faire rapidement permet de booster les performances géométriques en situation réelle.

Actuellement, les moteurs géométriques des Radeon ne sont pas capables d'effectuer cette tâche plus rapidement que le rendu d'un triangle, contrairement aux GeForce qui en profitent pour se démarquer dans certaines scènes, notamment quand la tesselation génère de nombreux triangles masqués. Avec Polaris, AMD devrait enfin combler ce déficit, probablement en doublant le nombre de moteurs d'éjection des primitives par moteur de rastérisation (Nvidia a opté pour une autre approche en décentralisant une partie du traitement géométrique mais nous ne nous attendons pas à ce qu'AMD suive cette voie).


Pour introduire Polaris, contrairement à ce qui se passe habituellement (à l'exception de Maxwell 1 et des GTX 750), AMD met en avant non pas son futur haut de gamme mais un petit GPU prévu pour les PC compacts et pour les portables. Il est équipé de mémoire GDDR5. Nous n'avons pas encore de nom pour ce GPU et n'avons pu l'apercevoir que brièvement sans pouvoir en prendre une photo. Tout juste de quoi apercevoir qu'il s'agit effectivement d'une petite puce et d'un packaging compact.

Sans confirmer que ce serait le premier GPU Polaris disponible, AMD a indiqué que ce petit GPU était important pour sa division graphique, qu'il serait lancé mi-2016 et qu'il serait fabriqué en 14nm chez GlobalFoundries. En précisant ne pas exclure que d'autres GPU soient fabriqués ailleurs, chez Samsung (probablement) ou chez TSMC (de moins en moins probable).

Au niveau de ses spécifications, nous ne saurons rien. Il faudra encore patienter quelque peu, le but d'AMD aujourd'hui étant de nous mettre l'eau à la bouche pour nous faire patienter quelques mois de plus.


Nous avons par contre pu voir ce GPU en action dans une version alpha lors d'un événement presse organisé il y a quelques semaines. AMD a voulu illustrer les gains d'efficacité énergétique apportés par Polaris par rapport à un GPU Maxwell, déjà très efficace. Des chiffres à prendre avec des pincettes, puisqu'ils restent dans le fond assez vagues et avec des conditions de mesure discutables, mais qui font état d'une progression fulgurante du rendement de l'architecture GCN.

Un système équipé d'un petit GPU Polaris est ainsi capable de maintenir 60 fps dans Star Wars Battlefront avec une consommation totale mesurée à la prise de 86W là où un même système équipé d'une GTX 950 demande 140W. Difficile d'en déduire exactement la consommation GPU et ce gain peut en partie être lié à la combinaison d'une puissance GPU supérieure avec un V-Sync à 60 Hz qui permet de rester à une plus faible fréquence, d'ailleurs le GPU utilisé est configuré à 850 MHz pour 0,8375v seulement. Mais de toute évidence Polaris en 14nm va enfin permettre à AMD de faire mieux que Maxwell en 28nm.

AMD tient d'ailleurs à préciser que cette démonstration a été effectuée avec un support partiel de Polaris par les pilotes. Les gains d'efficacité proviennent ainsi uniquement du 14nm et des CU GCN 4, le support des nouveaux mécanismes dédiés à économiser de l'énergie n'ayant pas encore été implémenté.

Bien entendu, les GPU Polaris n'auront pas simplement affaire aux GPU Maxwell actuels mais bien aux GPU Pascal et peut-être à de petits GPU Maxwell 2 fabriqués en 16/14nm. Et il est beaucoup trop tôt pour savoir comment s'opposeront ces futurs concurrents. Pour la première fois depuis très longtemps, il est d'ailleurs intéressant de noter qu'un élément tiers pourra venir semer le trouble dans le combat AMD vs Nvidia : les fondeurs. En effet, il semble de plus en plus probable qu'AMD exploite principalement les process 14nm de GlobalFoundries et Samsung alors que Nvidia exploiterait plutôt le 16nm de TSMC. Si l'un de ces process s'avère meilleur que l'autre, le fabricant de GPU qui aura misé sur le bon cheval s'en trouvera mécaniquement avantagé même si le process ne fait pas tout.

Vous retrouverez la présentation complète ci-dessous :
 
 

Dossier : AMD Radeon R9 380X : les cartes Asus Strix et Sapphire Nitro en test

Publié le 30/11/2015 à 08:00 par Damien Triolet

Pour renforcer son offre face aux GTX 900, AMD introduit la Radeon R9 380X avec un GPU Tonga qui monte enfin en puissance. Est-ce suffisant pour faire la différence ? La réponse dans notre dossier complet.

[+] Lire la suite

Dossier : AMD Radeon R9 Nano, la carte Fiji compacte en test

Publié le 10/09/2015 à 14:00 par Damien Triolet

AMD compte bien se démarquer de la concurrence en proposant pour la première fois une carte graphique haut de gamme ultra compacte destinée aux mini-PC. Cette Radeon R9 Nano trouvera-t-elle sa niche ?

[+] Lire la suite

Les GTX 900 supportent-elles correctement DirectX 12 ?

Publié le 09/09/2015 à 00:00 par Damien Triolet

Comme à chaque introduction de nouvelle API graphique, la question du support optimal de Direct3D 12 par les cartes graphiques du moment se pose. Ashes of the Singularity, le premier benchmark issu d'un jeu compatible avec cette API, ne met pas réellement en avant les GeForce GTX 900 qui souffriraient d'une mauvaise gestion de l'Async Compute. Explications.


Oxide, le développeur d'Ashes of the Singularity et qui est par ailleurs plutôt proche d'AMD, a sorti il y a quelques semaines un benchmark qui découle de son futur jeu et qui a la particularité de supporter autant DirectX 11 que DirectX 12. Le but premier de la démonstration est de mettre en avant l'intérêt de la nouvelle API de Microsoft pour réduire le surcoût CPU et multiplier le nombre d'unités en action à l'écran, mais d'autres aspects de DirectX 12 sont également de la partie. C'est le cas de l'Async Compute, technique sur laquelle nous allons revenir et qui permet de gagner des performances en exploitant mieux le GPU.

Les premiers résultats publiés, par exemple chez nos confrères de PCPerspective  sont loin d'avoir été flatteurs pour les GeForce :


Dans cet exemple, qui se concentre sur les performances dans la partie la plus lourde du benchmark, la GeForce GTX 980 a un net avantage sur la Radeon R9 390X en DirectX 11, ce qui est lié aux pilotes Nvidia qui ont été particulièrement bien optimisés. La situation s'inverse par contre dans le mode DirectX 12 où les performances explosent pour la Radeon alors qu'elles progressent peu voire régressent pour la GeForce.

La réaction de Nvidia ne s'est pas fait attendre et son service de communication s'en est pris sans ménagement à ce benchmark :
The alpha benchmark will run a series of pre-selected scenes and will give you a score at the end to show how well your system ran that series of scenes. The game looks intriguing, but this alpha benchmark is primarily useful to understand how your system runs a series of scenes from the alpha version of Ashes of Singularity.
We believe there will be better examples of true DirectX 12 performance and we continue to work with Microsoft on their DX12 API, games and benchmarks. The GeForce architecture and drivers for DX12 performance is second to none – when accurate DX12 metrics arrive, the story will be the same as it was for DX11.

Nvidia entend donc balayer du revers de la main les résultats de ce benchmark qualifié d'alpha et d'inexact et affirmer que l'architecture et les pilotes des GeForce lui permettront de dominer autant dans DirectX 12 que dans DirectX 11.

Nvidia aime également rappeler aux journalistes que toutes les démonstrations de Microsoft ont été faites sur des GeForce. En pratique, cela ne veut cependant rien dire du tout, ces choix sont politiques plus que techniques, notamment parce que Microsoft avait à cœur de se détacher de l'API Mantle dont DirectX 12 s'est inspiré.

Entre un Nvidia plutôt de mauvaise foi et un AMD qui crie victoire et veut laisser penser que les Radeon vont gagner des points avec DirectX 12, il peut être difficile de savoir quoi penser et il y a eu pas mal d'agitation sur certains forums.

Probablement en concertation avec AMD mais également avec Nvidia, Oxide a finalement communiqué fin août quelques explications sur le forum d'Overclock.net, tout d'abord ici  et là .

En voici les extraits principaux :
Personally, I think one could just as easily make the claim that we were biased toward Nvidia as the only 'vendor' specific code is for Nvidia where we had to shutdown async compute. By vendor specific, I mean a case where we look at the Vendor ID and make changes to our rendering path. Curiously, their driver reported this feature was functional but attempting to use it was an unmitigated disaster in terms of performance and conformance so we shut it down on their hardware. As far as I know, Maxwell doesn't really have Async Compute so I don't know why their driver was trying to expose that.

I suspect that one thing that is helping AMD on GPU performance is D3D12 exposes Async Compute, which D3D11 did not. Ashes uses a modest amount of it, which gave us a noticeable perf improvement. It was mostly opportunistic where we just took a few compute tasks we were already doing and made them asynchronous, Ashes really isn't a poster-child for advanced GCN features.

Our use of Async Compute, however, pales with comparisons to some of the things which the console guys are starting to do. Most of those haven't made their way to the PC yet, but I've heard of developers getting 30% GPU performance by using Async Compute. Too early to tell, of course, but it could end being pretty disruptive in a year or so as these GCN built and optimized engines start coming to the PC. I don't think Unreal titles will show this very much though, so likely we'll have to wait to see.

AFAIK, Maxwell doesn't support Async Compute, at least not natively. We disabled it at the request of Nvidia, as it was much slower to try to use it then to not.

Whether or not Async Compute is better or not is subjective, but it definitely does buy some performance on AMD's hardware. Whether it is the right architectural decision for Maxwell, or is even relevant to its scheduler is hard to say.

P.S. There is no war of words between us and Nvidia. Nvidia made some incorrect statements, and at this point they will not dispute our position if you ask their PR. That is, they are not disputing anything in our blog. I believe the initial confusion was because Nvidia PR was putting pressure on us to disable certain settings in the benchmark, when we refused, I think they took it a little too personally.

Grossièrement, Oxide explique avoir dû modifier le moteur de rendu d'Ashes of the Singularity pour désactiver l'Async Compute sur les GeForce qui supportaient très mal cette fonctionnalité alors qu'elle apporterait un gain sur les Radeon, malgré son utilisation très basique. Oxide en profite pour lancer une pique à Nvidia qui aurait tenté de faire pression pour que le benchmark soit modifié à son avantage.

Il y a quelques jours, Oxide est revenu sur le sujet à travers ce post  :
Regarding Async compute, a couple of points on this. First, though we are the first D3D12 title, I wouldn't hold us up as the prime example of this feature. There are probably better demonstrations of it. This is a pretty complex topic and to fully understand it will require significant understanding of the particular GPU in question that only an IHV can provide. I certainly wouldn't hold Ashes up as the premier example of this feature.

We actually just chatted with Nvidia about Async Compute, indeed the driver hasn't fully implemented it yet, but it appeared like it was. We are working closely with them as they fully implement Async Compute. We'll keep everyone posted as we learn more.

Oxide tient à rappeler qu'il ne s'agit que d'une première exploitation de l'Async Compute, qu'il y en aura probablement de meilleures démonstrations et que c'est un sujet complexe dont la bonne maîtrise devra se faire avec la coopération d'AMD et de Nvidia. De toute évidence, Oxide s'est mis d'accord avec Nvidia au sujet de cette communication pour apaiser les esprits en renvoyant le problème vers des pilotes toujours en chantier.

Que ce soit vrai ou pas il s'agit évidemment de la meilleure réponse que pouvait apporter Nvidia pour éviter de ne voir cette polémique sortir du verre d'eau pour prendre de l'ampleur. Ce n'est cependant pas suffisant pour éviter que nous ne nous posions quelques questions.


Direct3D 12 : rappels
Avant de rentrer dans le vif du sujet, il est important de rappeler certains points, notamment parce que dans la fourmilière qu'est le net, nous pouvons lire à peu près tout et n'importe quoi au sujet de Direct3D 12. Une confusion qui est liée à un manque de communication claire de la part de Microsoft et des différents fabricants de GPU. Direct3D 12 est l'API graphique bas niveau de DirectX 12, inspirée par l'API Mantle d'AMD. Sa finalisation a pris de nombreux mois pendant lesquels tous les acteurs de l'industrie se sont concertés pour en ajuster les spécifications et le comportement. Plus qu'une concertation il s'agit en fait d'un lobbying intense compte tenu de l'importance stratégique que représente une nouvelle API graphique. Microsoft, dans son rôle d'arbitre, a essayé de prendre en compte les demandes de chacun tout en veillant bien entendu à ses propres intérêts.

Avec Windows 10, de nouveaux niveaux de fonctionnalités graphiques ont fait leur apparition : 12_1 et 12_0. Contrairement à ce que leur numérotation peut laisser penser et à ce qui s'est passé auparavant avec les niveaux 10_x ou 11_x, ceux-ci ne sont pas liés à Direct3D 12. Ils sont également disponibles sous Direct3D 11. Seules les GeForce GTX 900 (et le GPU de Skylake) supportent le niveau 12_1 mais cela n'implique en rien que ces GPU supportent plus ou moins bien Direct3D 12 qu'un autre GPU. Ces fonctionnalités supplémentaires n'ont aucun lien avec une API graphique de bas niveau. Elles permettront éventuellement de mettre en place des effets graphiques plus complexes et/ou plus performants, autant dans Direct3D 11 que dans Direct3D 12.

Alors qu'est-ce qui définit un bon support de l'API Direct3D12 ou D3D12 en abrégé ? La seule réponse simple est probablement "que le GPU puisse traiter efficacement ce que lui demande de faire le développeur". Le principe d'une API de plus bas niveau et de transférer plus de flexibilité et de contrôle à ce dernier, en partie à l'image de ce qui se fait sur console, ce qui a de nombreux avantages en termes de surcoûts CPU et d'exploitation des CPU multithreads. Mais encore faut-il que le GPU soit lui aussi assez flexible pour traiter efficacement de nouvelles façons d'organiser le rendu 3D.


Les Tiers
L'un des niveaux de support importants pour D3D12 est le Resources Binding Tier. Grossièrement il s'agit d'un paramètre exposé par la GPU pour indiquer le nombre d'éléments qui peuvent être exploités par le pipeline de rendu 3D : textures, buffers en tous genres, constantes… Plus le Tier est élevé (1, 2 ou 3), moins le développeur doit se soucier des différentes limites. Toutes les Radeon récentes (GCN) supportent le Tier 3 alors que les GeForce Maxwell et Kepler se contentent du Tier 2.

Contrairement au niveau de fonctionnalité, le Resources Binding Tier 3 indique un meilleur support de D3D12 que le Tier 2. Mais est-ce que cela fait une grosse différence en pratique ? Probablement pas. Si un développeur a besoin de plus que ce qu'offre le Tier 2, il pourra en général mettre en place un jeu de chaises musicales avec les ressources disponibles. C'est un peu plus contraignant et il peut y avoir un impact sur les performances mais rien n'est impossible.

Nvidia aurait d'ailleurs probablement pu trouver des astuces pour proposer un support du Tier 3, quitte à implémenter directement dans les pilotes un tel jeu de chaises musicales. Mais stratégiquement cela n'aurait eu aucun sens. D'une part le grand public n'entendra jamais parler de cette différence entre Tiers et d'autre part se contenter du Tier 2 permet de forcer les développeurs à rester dans un cadre optimal pour les performances de ses GPU. L'existence du Tier 2 est donc en quelque sorte une victoire pour le lobbying de Nvidia auprès de Microsoft.


Le Multi Engine
D'autres spécificités de D3D12 font partie du cœur de l'API. Mais bien que dans ce cas de figure leur support soit inévitable, il n'y a pas d'obligation de résultat de la part de Microsoft, l'implémentation matérielle qui en découle étant laissée à l'appréciation des fabricants de GPU. C'est le cas du Multi Engine dont l'Async Compute découle. Une fonctionnalité dévoilée relativement tard par Microsoft et dont nous vous avions déjà parlé ici  et que Microsoft documente là .

Grossièrement le Multi Engine permet aux développeurs de prendre le contrôle sur la synchronisation entre différentes tâches et dans certains cas d'exécuter ces tâches simultanément ou en concomitance. Et sur ce point Microsoft a repris exactement la structure qu'AMD avait mise en place avec son API Mantle. Une victoire cette fois pour AMD qui a dessiné le Multi Engine en suivant les contours de l'architecture de ses GPU.

De quoi s'agit-il ? A la base de leur moteur D3D12, les développeurs créent des Command Queues qui sont des files d'attente dans lesquelles vont prendre place des listes de commandes de rendu qui seront exécutées séquentiellement par le GPU pour créer la représentation 3D de la scène. La 10ème liste de commandes à y prendre place devra toujours attendra que les 9 autres aient été exécutées par le GPU avant d'être traitée.

Mais avec D3D12, il est possible d'exploiter plusieurs Command Queues, ce qui permet par exemple de faire traiter certaines tâches en priorité mais aussi en parallèle. L'exemple le plus simple concerne le contrôle direct sur le multi-GPU, une Command Queue pouvant être attribuée à chaque GPU du système si le développeur se charge de répartir le travail de cette manière.


Tout comme Mantle, D3D12 définit 3 types de Command Queues : Copy, Compute et Graphics. Copy peut recevoir toutes les commandes liées aux déplacements de données (avec conversion de formats dans certains cas) telles que le streaming des textures ou encore le transfert au CPU d'une tâche traitée par le GPU. Compute y ajoute les commandes de calcul et de tout ce qui y est lié alors que Graphics supporte l'ensemble des commandes de D3D12.

Graphics est un superset de Compute qui est un superset de Copy. Il est donc possible de n'exploiter qu'une seule Command Queue de type Graphics, cela correspond d'ailleurs à ce qui se passe avec les anciennes API. Exploiter différents types de ces files d'attente peut permettre de gérer différents niveaux de priorité, par exemple exploiter le temps GPU non-utilisé par le rendu 3D pour faire du GPU Computing en arrière-plan.


Mais ce n'est pas tout et nous en arrivons enfin au point qui nous intéresse : l'exécution concomitante (concurrency). Même si le système ne contient qu'un seul GPU, les développeurs peuvent segmenter le travail entre plusieurs Command Queues dans le but de permettre au GPU de les traiter en même temps, en concomitance. De quoi espérer des gains de performances.

Cela implique un travail important pour les développeurs qui vont devoir faire pas mal de profilage pour déterminer ce qui a du sens dans le cadre d'un traitement concomitant. Par exemple si deux commandes de rendu saturent les unités de calcul, il n'y a aucun intérêt à essayer de les traiter en parallèle par rapport à une exécution en série classique. Par contre si une partie du rendu sature les unités de calcul alors qu'une autre sature l'interface mémoire, l'intérêt est évident et le gain de performances peut être substantiel.

C'est à cette sous-possibilité du Multi Engine qu'AMD fait référence en parlant de l'Async Compute. Une terminologie poussée par le service communication d'AMD que nous estimons d'ailleurs très mal choisie puisqu'il est possible de traiter deux tâches de manière asynchrone sans que cela ne se fasse en parallèle.

Exploiter plusieurs Command Queues en vue d'un traitement concomitant implique également que les développeurs s'assurent de la robustesse de leur code. Ils doivent notamment prévoir des barrières de synchronisation là où elles sont nécessaires en prenant en compte l'inconnue liée aux futurs GPU (cet aspect inexistant sur console permet d'y faire quelques raccourcis). Ces barrières (fences) peuvent avoir un coût important en termes de performances et il faut donc faire en sorte de les utiliser avec parcimonie pour que l'ensemble soit bénéfique. Entendez par là que l'intérêt est plutôt d'essayer de traiter tout le post processing en parallèle du rendu de la scène que de calculer la position d'une particule en même temps que le rendu d'un brin d'herbe.

C'est à peu près ce qu'AMD nous avait répondu au mois de mars :
HFR: Let's say developers do an amazing job with fences and barriers in D3D12 to get the most of current GPUs, running tasks concurrently in an optimal fashion. What happens with future GPUs when paradigms and bottlenecks move ? What is optimal for current GPUs might move close to bad cases for future architectures. Will you have room to tweak fences in the drivers to align tasks in a different fashion ? Or would you advise developers not to optimize too deeply and “simply” try to combine mostly compute intensive with mostly memory intensive tasks ?

AMD: At the moment we're recommending the latter. Micro-optimising is probably not worth it and carries pitfalls; in particular the cost of fences is not insignificant. If applications can do their best efforts to use a couple of fences per frame to line up a few fairly obviously dissimilar workloads, we expect that to provide the majority of the benefit for minimal application effort and acceptable risk in the future.

Par ailleurs, dans bien des cas, ce traitement concomitant va impliquer une augmentation de la latence, ce qui pourra ne pas être adapté à tous les types de jeux. Par exemple le calcul du post processing pour une image donnée ne peut pas débuter avant la fin du rendu de la scène et ne sera donc traité qu'en même temps que le rendu de l'image suivante. Cela augmente quelque peu la latence par rapport à un traitement en série classique mais au profit d'un débit plus élevé.


De quoi sont capables les GPU ?
Les GPU disposent tous d'un processeur de commande qui en est en quelque sorte la porte d'entrée. C'est par là que passent toutes les commandes qu'ils vont devoir exécuter et il peut bien entendu y avoir des différences importantes d'un GPU à l'autre. Des processeurs de commandes plus évolués vont pouvoir accepter un débit de commandes plus élevé, gérer plusieurs files d'attente ou encore essayer de dégager du parallélisme.

Il est difficile de savoir précisément ce dont sont capables les processeurs de commandes des GPU. Il s'agit généralement d'une zone d'ombre très peu décrite par AMD et Nvidia qui se contentent de simplifications grossières. Voici ce qu'AMD et Nvidia nous avaient indiqué au mois de mars :

Chez AMD :

Tous les GPU GCN supportent l'exécution concomitante Graphics/Compute/Copy mais il y a des limitations pour les GPU GCN 1.0 (Tahiti, Pitcairn, Cape Verde, Oland) par rapport à la synchronisation des tâches de type Copy.

En plus d'un processeur de commande graphique principal, tous les GPU GCN intègrent des Asynchronous Compute Engines (ACE) qui peuvent traiter les tâches Compute en concomitance et des DMA engines qui font de même avec les tâches Copy. Le nombre d'ACE par GPU peut varier ainsi que le nombre de files d'attentes par ACE. Plus il y a d'ACE, plus il y a de tâches qui peuvent être traitées en parallèle. Plus il y a de files d'attente, plus les ACE ont de flexibilité pour trouver une tâche à exécuter sans conflit de synchronisation avec une autre.

Cette structure à base d'ACE et de files d'attente permet de maximiser l'utilisation du GPU lorsque les tâches Compute sont petites et nombreuses. Cela a été mis en place avant tout dans l'optique du calcul professionnel mais cette approche autorise également le traitement concomitant dans le cadre du rendu 3D avec D3D12 et de multiples Command Queues même si dans ce cas un seul ACE aurait probablement été suffisant.

-Tahiti, Pitcairn, Cape Verde, Oland: 1 processeur Graphics + 2 ACE avec 1 file d'attente chacun
-Bonaire: 1 processeur Graphics + 2 ACE avec 8 files d'attente chacun
-Hawaii, Tonga et Fiji: 1 processeur Graphics + 8 ACE avec 8 files d'attente chacun

Quelques slides d'AMD permettent d'illustrer de manière simplifiée ce concept de traitement concomitant :

 
 

A gauche, un GPU basique qui ne supporterait aucun traitement concomitant : il alterne entre les tâches. Au milieu, un GPU qui souffrirait de la même limitation (AMD parle-t-il de Maxwell 2 ?) mais ferait appel à la préemption pour permettre à une tâche de passer devant une autre. Enfin à droite un GPU GCN capable de prendre en charge plusieurs flux de tâches en concomitance.


Chez Nvidia :

Pour tous ses GPU récents, Nvidia parle d'un seul gros processeur de commandes. Dans le cas des GPU Fermi et Kepler (sauf GK110/GK210), ils se contentent par ailleurs d'une seule file d'attente. Aucun traitement concomitant des tâches n'est donc possible. Si de multiples Command Queues sont exploitées par le moteur graphique, elles seront exécutées séquentiellement.

Les GK110/GK210 et les GPU Maxwell 1 (GM107/GM108) intègrent un processeur de commandes plus évolué avec une technologie baptisée Hyper-Q qui permet de supporter 32 files d'attente, mais uniquement dans un mode purement Compute. Les GK110/GK210 supportent par ailleurs 2 DMA Engines, mais ils sont réservés aux déclinaisons Quadro/Tesla. Hyper-Q permet d'exécuter des tâches de type Compute en concomitance mais il est peu probable que cela soit exploité en dehors du pilote CUDA.

Avec les GPU Maxwell 2 (GM200/GM204/GM206), Nvidia nous a indiqué avoir fait sauter toutes ces limitations. Tout d'abord, le second DMA Engine est bien actif sur les déclinaisons GeForce. Mais surtout, quand Hyper-Q est actif, une des 32 files d'attente peut être de type Graphics. Au niveau de l'implémentation logicielle, Nvidia nous a précisé en mars qu'un traitement concomitant complet de tous les types de tâches était supporté sous Direct3D 12 pour les GPU Maxwell 2.

-GeForce Fermi, Kepler et Maxwell 1 : 1 processeur de commandes avec 1 file d'attente Graphics
-GeForce Maxwell 2 : 1 processeur de commandes avec 32 files d'attente 1 Graphics + 31 Compute


Rectification d'AMD…
Tout cela c'était en mars. Quelques mois plus tard et probablement avec un peu d'expérience sur les nouvelles API, il y a quelques rectifications à faire. Tout d'abord du côté d'AMD qui a discrètement modifié sa façon de présenter les ACE lors des dernières présentations liées au GPU Fiji.


[ Fiji en juin ]  [ Fiji en août ]  

AMD ne parle plus de 8 ACE pour son GPU Fiji mais bien de 4 ACE + 2 HWS (Hardware Scheduler). Interrogé sur ce que cela signifiait, AMD nous a indiqué qu'un ACE pouvait être vu comme un processeur de commandes multitâche qui se charge de la sélection/préemption des tâches à travers ses files d'attente, de la distribution des tâches vers les unités de calcul et de l'exécution des commandes de synchronisation. Or seuls 4 ACE en sont capables ou ont été configurés de manière à l'être.

AMD explique que les 4 autres sont exploités pour soulager le CPU dans la gestion de l'ordonnancement des files d'attentes et des tâches sur les 4 ACE principaux, notamment dans le cadre de la virtualisation. AMD y fait dorénavant référence en tant que Hardware Schedulers (HWS). Nous ne savons cependant pas pourquoi AMD parle de 2 HWS et non de 4. Nos questions supplémentaires à ce sujet n'ont pas trouvé de réponse et nous ne savons pas si Tonga et Hawaii ont été configurés de la sorte ou si c'est spécifique à Fiji. Nous sommes cependant tentés de penser que c'est bel et bien le cas au vu de l'annonce récente du support matériel de la virtualisation sur des FirePro basées sur Hawaii.

Dans le cadre de D3D12, cette rectification de la part d'AMD ne fait aucune différence mais témoigne de la zone d'ombre que représentent les processeurs de commandes des GPU.


… et silence chez Nvidia
Si D3D12 impose de supporter de multiples Command Queues, il n'y a pas d'obligation au niveau de l'implémentation matérielle et du support du traitement concomitant. Au vu des résultats des GeForce GTX 900 dans Ashes of the Singularity et des déclarations d'Oxide, il était logique de se demander si les GPU Maxwell supportaient réellement ce que Nvidia nous avait affirmé en mars au niveau de leur processeur de commandes.

Nous avons donc questionné Nvidia sur le sujet dès le 31 août, qui nous a indiqué que nous recevrions une réponse dans la journée… tous les jours de la semaine passée. Mais aucune réponse ne nous est parvenue jusqu'ici ce qui signifie qu'il n'est pas simple pour Nvidia d'en rédiger une. De quoi nous laisser penser que les GPU Maxwell 2 souffrent au mieux de sérieuses limitations pour exploiter le traitement concomitant des tâches. Après l'histoire du bus mémoire limité de la GeForce GTX 970, cela commencerait à faire beaucoup d'imprécisions techniques dans la communication de Nvidia…


Quelques réflexions
La première déclaration d'Oxide mentionne que les GPU Maxwell 2 ne supportent pas nativement l'exécution simultanée de tâches Compute et Graphics et que Nvidia expose malgré tout le support des "Async Shaders" qui seraient émulés. Cela expliquerait pourquoi les performances sont mauvaises et Oxide aurait travaillé avec Nvidia pour mettre en place un mode spécial qui évite d'utiliser les "Async Shaders" mais qui est moins performant que le premier mode sur GPU AMD. Mais ce qu'indique Oxide ne nous semble pas tout à fait correct.

D'après notre compréhension des spécifications de D3D12, Async Shaders n'en est pas une fonctionnalité de D3D12 que l'on peut ou pas exposer. C'est un concept mis en avant par le marketing technique d'AMD et qui représente une des possibilités qui découle de l'utilisation du Multi Engine et des multiples Command Queues dont le support est obligatoire.

Le problème qu'a pu rencontrer Oxide est probablement légèrement différent, mais il s'agit de spéculation de notre part. Par exemple il se peut tout simplement que les GPU Maxwell 2, comme tous les autres GPU Nvidia et comme le permet D3D12, exécutent séquentiellement les multiples Command Queues accusant alors le surcoût des barrières de synchronisation sans profiter du traitement concomitant.

Une autre possibilité est que les GPU Maxwell 2 alternent entre des listes de commandes de différentes Command Queues en souffrant à chaque fois d'un lourd changement d'état, toujours sans profiter du moindre traitement concomitant. Enfin, il est possible que les GPU Maxwell 2 exécutent bel et bien différents types de tâches en concomitance mais en accusant un surcoût important et une faible efficacité, ce qui rend l'opération néfaste sur le plan des performances.

Dans tous les cas, c'est probablement indirectement qu'Oxide a dû faire en sorte d'éviter ces écueils, probablement en repassant sur un modèle à base d'une seule Command Queue ou en mettant en place un système simplifié de barrières de synchronisation exclusivement destiné à forcer un traitement séquentiel.

Cela pourrait laisser penser que Nvidia n'a pas tout dit en indiquant que les GPU Maxwell 2 sont capables d'effectuer un traitement concomitant avec le support matériel d'une file d'attente Graphics associée à 31 files d'attentes de type Compute. Plusieurs éléments peuvent d'ailleurs aller dans ce sens.

Nvidia nous a par exemple expliqué dès le mois de mars que pour sa version de l'Asynchronous Timewarp, technique destinée à réduire la latence ressentie en réalité virtuelle, aucune exécution concomitante n'est mise ne place. Nvidia fait appel à la préemption avec un changement de contexte. Cela a un coût, mais il n'est payé qu'une seule fois puisque le rendu de l'image est interrompu totalement le temps de traiter le Timewarp. AMD fait de son côté appel au traitement concomitant avec une priorité plus élevée pour les threads du Timewarp mais Nvidia se justifie en expliquant qu'il est préférable de dédier tout le GPU à son exécution pour le traiter le plus rapidement possible.

Par ailleurs, la documentation technique liée à Hyper-Q nous laisse apercevoir que Nvidia propose pour ses cartes Tesla une surcouche logicielle appelée MPS (Multi Process Service) qui permet de combiner ensemble les tâches Compute de plusieurs process de manière à pouvoir les exécuter en concomitance. Sans cela, chaque process représente un contexte GPU distinct et aucune concomitance n'est possible entre tâches issues de process différents. Si les différents types de Command Queues sont considérés par le pilote de la même manière que des process différents, il est possible qu'une telle surcouche logicielle soit également nécessaire pour profiter du traitement concomitant sous D3D12 et éviter de lourds changements de contextes. Il pourrait alors y avoir un coût CPU et des limitations au niveau du GPU.

Bien entendu il est également possible que tout ceci soit lié à un malentendu suite à des pilotes qui ne seraient pas encore au point du côté de Nvidia. Mais cela nous paraît peu probable face au silence de Nvidia et au fait que ce spécialiste du GPU et des techniques de rendu à eu de très nombreux mois pour se préparer et n'ignorait pas que ce point allait prendre un aspect compétitif important.


Les Radeon vont-elles avoir l'avantage sous Direct3D 12 ?
Vous l'aurez compris, il est très probable que les GeForce GTX 900 basées sur l'architecture Maxwell de seconde génération souffrent de limitations qui les empêchent de profiter du Multi Engine de Direct3D 12 pour proposer un support efficient de l'exécution concomitante de tâches. Ces GeForce pourraient ainsi passer à côté de certains gains de performances.

A l'inverse, les Radeon semblent disposer d'une architecture bien adaptée pour en profiter et proposer différentes optimisations sur le plan des performances. De quoi peut-être gagner quelques points de compétitivité. Une démonstration technique d'AMD à laquelle nous avions pu assister en mars permettait de gagner 17% alors que sur console certains développeurs tireraient déjà des gains allant jusqu'à 30%.

Difficile cependant de savoir ce qu'en feront en pratique les développeurs sur PC, puisque ce sont eux qui auront en général le dernier mot. La situation est plus complexe que sur console et AMD nous a par exemple admis dès le mois de mars ne s'attendre qu'à des utilisations basiques dans un premier temps, notamment parce que des optimisations trop poussées sur les GPU actuels pourraient avoir un coût prohibitif au niveau des synchronisations ou être contreproductives dans le futur.

Par ailleurs, tous les types de rendus ne seront pas de bons candidats pour en profiter et en attendant sa prochaine génération de GPU, il ne fait aucun doute que Nvidia essaiera de se démarquer d'une autre manière dans les premiers jeux Direct3D 12, par exemple avec des effets graphiques spécifiques aux fonctionnalités supplémentaires des GPU Maxwell 2.

Dans l'immédiat, il serait utile que Nvidia documente clairement ce dont sont capables ses GPU sur ce point, ce qui permettrait au passage de comprendre en partie les possibilités d'optimisations éventuelles au niveau des pilotes. Il est par contre peut-être difficile pour l'égo de la société de communiquer des détails qui pourraient venir confirmer un avantage de la concurrence.

Top articles