Les contenus liés aux tags AMD et DirectX 12

Nous vous en parlions en mai dernier, DirectX 12 ajoute un support explicit du multi-GPU, laissant aux développeurs la possibilité de contrôler eux-mêmes le multi-GPU. A l'époque, une première démonstration sous l'Unreal Engine 4 combinait un GPU et un iGPU, le premier se chargeant du gros du rendu alors que le post-processing et l'affichage était pris en charge par l'iGPU. Dans la démonstration, on obtenait un gain de performance de 10%, avec comme désavantage une augmentation de la latence du rendu qui passait de 28 à 45ms.

Oxyde a fourni à AnandTech  une version alpha de son bench DirectX 12, basé sur le moteur de son jeu Ashes of the Singularity. Cette dernière va plus loin puisqu'il s'agit cette fois d'effectuer alternativement le rendu sur l'une ou l'autre des GPU intégré dans le système. Si ce rendu alternatif nécessite toujours deux GPU de performances proches pour être pertinent, l'avantage de ne plus passer par le SLI ou le CrossFire est que l'on n'est plus limité par les associations imposées par les constructeurs au sein de leur propre gamme, et que l'association d'un GPU AMD et d'un GPU Nvidia DirectX 12 est possible !


En pratique les gains sont bels et bien là, et étonnamment les plus importants sont enregistrés en couplant une R9 Fury X et une GTX 980 Ti avec selon que l'une ou l'autre soit utilisée en GPU primaire +64 à +75% en 2560x1440 contre +66% en ajoutant une Fury à une Fury X, ou +46% en couplant une Titan X à une GTX 980 Ti. En 3840*2160 les gains les plus importants sont obtenus en ajoutant une 980 Ti à une Fury X (+66%), l'inverse gagnant nettement moins (+40%).

Un autre test sur des GPU plus anciens montre par contre que le GPU primaire peut avoir un impact encore plus grand, ainsi si on adjoint à une HD 7970 une GTX 680, on obtient un gain de 55%. Par contre si les positions des cartes sont inversées alors les performances baissent de… 40% !

Ces résultats sont donc très intéressants et montrent le potentiel immense qu'offre une API donnant le contrôle aux développeurs. Reste que ce sont bien eux qui auront la main, et vu le marché relativement faible du multi GPU, il n'est pas certain que beaucoup exploitent comme Oxyde cette possibilité offerte par l'API. Il ne faut pas oublier non plus qu'au-delà des performances, d'un point de vue qualitatif une association AMD/Nvidia en AFR pourrait poser problème du fait de petites différences au niveau du filtrage des textures ou de l'anti-aliasing.

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.

En bas de page, nous avons mis à jour cette actualité initialement publiée le 16 mars. AMD nous a transmis une nouvelle présentation sur le sujet et Nvidia nous a précisé ce dont étaient également capables ses GPU en terme de traitement simultané des tâches.

De nombreuses sessions dédiées à Direct3D 12 étaient organisées à la GDC. Après celle de Microsoft consacrée à Direct3D, lors de laquelle les niveaux de fonctionnalités ont été mentionnés et des démonstrations ont été faites sur du matériel Nvidia, nous avons assisté à la session d'AMD. Lors de celle-ci, il a été question d'une nouvelle opportunité d'optimisation : améliorer les performances GPU en profitant du traitement simultané de certaines tâches liées au rendu 3D.

Si l'intérêt des API de plus bas niveau est avant tout d'optimiser les performances au niveau du CPU, en réduisant le surcoût des commandes des rendus et en profitant mieux de tous les cœurs, des gains peuvent également être obtenus au niveau du GPU. Dans la plupart des démonstrations auxquelles nous avons pu assister jusqu'ici, les gains mis en avant concernaient avant tout les GPU intégrés dont l'enveloppe thermique limite les performances. Si la charge CPU est réduite, le GPU a plus de marge au niveau de sa fréquence turbo et c'est ce qui permet de faire grimper ses performances.

Mais il y a d'autres possibilités au potentiel important. AMD a ainsi mis en avant l'opportunité d'améliorer les performances GPU en profitant du traitement concomitant de certaines tâches. Avec les API classiques, toutes les étapes du rendu sont traitées en série par le GPU. Par exemple, le calcul de la physique, la préparation des ombres dynamiques, le remplissage du G-Buffer, l'éclairage et le post processing sont traités l'un après l'autre, aussi vite que possible par les GPU, mais en série.

Chacune de ces tâches n'exploite cependant pas la totalité des capacités d'un GPU. Par exemple, la préparation des ombres et le remplissage du G-Buffer vont plutôt saturer le sous-système mémoire alors que la physique, l'éclairage et le post processing ont plutôt tendance à saturer les unités de calcul. Il semble ainsi logique que traiter en même temps certaines de ces tâches représente une optimisation intéressante pour mieux exploiter les GPU.

Et ça tombe bien, Direct3D 12, l'autorise. L'API de Microsoft semble reprendre exactement la base de Mantle sur ce point et prévoit 3 types de files d'attentes, également appelées "moteurs", dont les tâches peuvent être traitées en concomitance : Graphics, Compute et Copy. Au niveau des fonctionnalités prises en charge, Graphics est un superset de Compute qui est un superset de Copy. Cela veut dire que par défaut seul le moteur Graphics peut être exploité, puisqu'il est polyvalent. Il revient aux développeurs de spécifier l'utilisation des autres moteurs pour potentiellement optimiser les performances.

Il faut noter que ce type d'optimisation permet d'exploiter les ACE (Asynchronous Compute Engines) des GPU Radeon de la génération GCN. Pour rappel, AMD a implémenté ces processeurs de commandes secondaires justement pour pouvoir exécuter efficacement des tâches de type Compute en même temps que des tâches de type Graphics. D'autres GPU ne disposent pas de files d'attentes spécifiques au niveau matériel pour tous ces types de tâches et doivent alors les traiter de manière classique, en série. Ainsi, il n'est pas certain que les GPU Nvidia puissent profiter autant que ceux d'AMD de ce type d'optimisation. A notre connaissance, ils ne peuvent pas traiter les opérations de type Compute et Graphics en concomitance, et seules les GeForce les plus récentes (GTX 900) peuvent le faire avec les opérations de type Copy, une fonctionnalité auparavant réservée aux Quadro et Tesla.


Une bonne compréhension des architectures GPU et un profilage avancé des demandes de chaque tâche sont nécessaires. Il est également crucial de mettre en place correctement les barrières de synchronisation nécessaires, sans quoi des tâches dépendantes l'une de l'autre pourraient être exécutées en parallèle et causer des problèmes. AMD a insisté lourdement sur ce point, précisant que l'absence de barrières de synchronisation adéquates pourra passer inaperçue dans l'immédiat, sans bug visible, mais être source de gros problèmes avec de futurs GPU dont l'augmentation des performances profitera plus à certaines tâches qu'à d'autres. Comme le sait très bien AMD, les développeurs seront peu enclins à proposer un patch 2 ou 3 ans après la sortie d'un jeu, et appliquer un correctif au niveau des pilotes sera alors un véritable casse-tête, voire impossible dans certains cas.


Mais avec un code robuste et un bon profilage, les gains peuvent être conséquents. Il est question de 20 à 25% dans des situations réalistes et avec des GPU capables d'en profiter. Deux exemples ont été mentionnés. Le premier, accompagné d'une démonstration, découple le remplissage du G-Buffer du calcul de l'éclairage qui est réalisé à travers un compute shader. Au lieu de traiter ces 2 opérations l'une après l'autre, elles sont effectuées en parallèle et de manière asynchrone : pendant que l'éclairage est calculé pour l'image 1, les opérations sur le G-Buffer sont traitées pour l'image 2 et ainsi de suite.

[ Concomitance OFF ]  [ Concomitance ON ]  

Sans traitement concomitant des tâches Graphics et Compute, le temps de rendu total prend 3.346ms (299 fps), ce qui est la somme des 2.551ms de la partie Graphics (remplissage du G-Buffer) et des 0.747ms de la partie Compute (calcul de l'éclairage). En activant le traitement concomitant dans cette démonstration, le remplissage du G-Buffer prend 2.659ms, et le calcul de l'éclairage 2.822ms. Ces deux tâches prennent plus de temps à être traitées, mais elles le sont en même temps et le rendu total ne prend plus que 2.863ms (349 fps), ce qui représente un gain de 17%. La latence peut par contre être légèrement plus élevée.



Dans un autre exemple, AMD explique que streamer les textures et animer les particules via les moteurs Copy et Compute permet un petit gain puisque ces opérations sont alors traitées en concomitance avec les ombres et l'éclairage. Mais il est possible d'aller plus loin en constatant qu'il est plus efficace d'animer les particules en même temps que la préparation des ombres et de streamer les textures en même temps que le calcul de l'éclairage que de faire l'inverse. En évitant d'exécuter en même temps des tâches qui ont des demandes similaires en termes de ressources GPU, les gains sont plus importants. D3D12 offre des mécanismes aux développeurs pour pouvoir gérer cela.

Les GPU modernes doivent en général faire face à des limites de consommation directes ou indirectes (via la température) et mieux exploiter la totalité de leurs capacités revient bien entendu à les pousser plus souvent ou plus loin dans ces limites. La fréquence GPU des cartes graphiques est alors réduite quelque peu, ce qui impacte les performances, mais dans des proportions bien moins élevées que les gains liés à ce type d'optimisations. Elles restent donc totalement légitimes. A voir par contre si de tels moteurs graphiques seront qualifiés de "power virus" par AMD et Nvidia, comme c'est le cas de Furmark et d'OCCT qui font également en sorte de saturer toutes les unités des GPU…

Le set de slides de la session d'AMD à la GDC : (nous avons profité de la mise à jour pour remplacer nos clichés par des screenshots plus propres)




Mise à jour du 31/03 :

Quelques semaines après la GDC, AMD a décidé de mettre en avant ces possibilités d'optimisations auprès de la presse technique. Une présentation simplifiée nous a ainsi été distribuée il y a quelques jours. A noter que, bizarrement, elle était par contre accompagnée d'un embargo qui prenait fin ce matin… alors même que la présentation plus complète, dont nous vous avions parlé ci-dessus, est publique depuis la GDC. Peu de médias s'y étaient cependant intéressés et le département de marketing technique d'AMD a probablement voulu mettre en place une communication synchronisée sur le sujet.


Il n'y pas pas d'information supplémentaire dans cette présentation, mais elle est plus simple à comprendre et mieux finie que celle adressée aux développeurs, nous l'avons donc ajoutée à cette longue actualité. A noter que le marketing technique d'AMD parle d'Asynchronous Shaders pour faire référence à l'exécution concomitante de différentes tâches (même si les opérations de type Copy ne sont pas des shaders). Vous pourrez également observer le résultat obtenu sous une autre démo, que nous avions pu observer également pendant la GDC durant la présentation de LiquidVR. L'utilisation du traitement concomitant du rendu (Graphics) et du post processing (Compute) y permet un gain de performances de 46%.

Si cette stratégie de communication d'AMD ne nous en a pas appris plus, elle a par contre eu le mérite de pousser Nvidia à enfin communiquer sur le même sujet. L'occasion de faire le point sur ce dont sont capables tous les GPU récents, notre première supposition n'étant pas tout à fait correcte concernant les derniers GPU Maxwell.


Du côté d'AMD :

Tous les GPU de type GCN supportent le traitement concomitant des tâches Graphics/Compute/Copy. En plus d'un processeur de commande principal polyvalent, ils disposent au moins de 2 ACE (Asynchronous Compute Engine), dédiés aux tâches de type Compute, et de 2 DMA Engines dédiés aux tâches de type Copy.

Il y a par contre des limitations pour les GPU GCN 1.0 (Tahiti, Pitcairn, Cape Verde, Oland). Leurs DMA engines ne supportent pas toutes les fonctions de synchronisation avec le CPU, ce qui impose probablement des limites au niveau du traitement concomitant des tâches de type Copy. Ensuite, les GPU plus récents, GCN 1.1, supportent plus de files d'attente par ACE (8 au lieu de 1), qui peuvent par ailleurs être présents en plus grand nombre. Ils sont ainsi adaptés au traitement concomitant de nombreuses petites tâches de type Compute (par exemple pour la physique ?), contrairement à leurs prédécesseurs.

AMD a implémenté dans ses pilotes Direct3D 12 un support complet de traitement concomitant de tous les types de tâches, exactement comme c'est le cas sous Mantle. Par contre, nous ne savons pas si les pilotes AMD sont capables de profiter de certaines de ces possibilités pour apporter des optimisations sous certains jeux Direct3D 11.


Du côté de Nvidia :

Les GPU Fermi et Kepler se contentent d'un seul processeur de commandes qui ne peut pas prendre en charge simultanément des commandes de type Graphics et de type Compute. Soit il est dans un mode, soit dans l'autre, un changement d'état relativement lourd à opérer.

Par ailleurs, à l'exception des GK110/GK210, ces anciens GPU ne disposent que d'une seule file d'attente au niveau de leur processeur de commande qui doit traiter les tâches dans l'ordre dans lequel elles sont soumises. Cela limite fortement la possibilité d'en traiter plusieurs simultanément à l'intérieur du mode Compute lorsqu'il y a des dépendances entre elles.

Avec le GK110, Nvidia a introduit un processeur de commandes plus évolué, qui supporte une technologie baptisée Hyper-Q. Elle représente la capacité de prendre en charge jusqu'à 32 files d'attente, mais uniquement en mode Compute. Ce GPU, et les GM107/GM108 qui reprennent cette spécificité, sont ainsi adaptés au traitement concomitant de nombreuses petites tâches de type Compute (par exemple pour la physique ?). Le GK110 a également introduit un second DMA Engine, mais il est réservé aux déclinaisons Tesla et Quadro.

Enfin, avec les GPU Maxwell 2 (GM200/GM204/GM206), Nvidia a fait sauter toutes ces limitations, contrairement à ce que nous pensions. 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, un traitement concomitant complet de tous les types de tâches est supporté sous Direct3D 12 pour les GPU Maxwell 2. Il n'est par contre pas possible d'effectuer une exécution concomitante entre Direct3D 12 et CUDA, qui repose sur un pilote différent.

Nvidia a également implémenté dans ses pilotés un support limité de l'exécution concomitante sous Direct3D 11, pour les tâches compute uniquement. L'API ne permet pas d'y accéder explicitement, mais quelques astuces permettent aux pilotes d'activer un tel mode pour optimiser les performances (dans le cas de GPU PhysX ?). Nvidia nous a précisé que la question d'y ajouter le support d'un traitement concomitant complet de tous les types de tâches, comme sous Direct3D 12, restait en suspens. Ce n'est pas impossible si cela avait une utilité, mais aucun jeu Direct3D 11 actuel n'est prévu pour en profiter. Sans support explicité dans l'API il est très difficile pour les développeurs de faire en sorte que cela puisse fonctionner.


En résumé :

HD 7000 & Rx 240/250/270/280 : processeur de commandes x1 queue + 2 ACE x1 queue + 2 DMA engines
->Graphics/Compute/Copy avec limitations

HD 7790 & R7 260 : processeur de commandes x1 queue + 2 ACE x8 queues + 2 DMA engines
->Graphics/Compute/Copy

R9 285/290 : processeur de commandes x1 queue + 8 ACE x8 queues + 2 DMA engines
->Graphics/Compute/Copy

GTX 400/500/600/700 : processeur de commandes x1 queue + 1 DMA engine
->Pas de support

GTX 750/780/Titan : processeur de commandes x32 queues (limité) + 1 DMA engine
->Compute/Compute

GTX 900/Titan X : processeur de commandes x32 queues + 2 DMA engines
->Graphics/Compute/Copy

Au final, c'est surtout au niveau des anciens GPU que se différencient AMD et Nvidia, le premier ayant un support en place au niveau matériel depuis plus longtemps. Au niveau des cartes graphiques plus récentes, les GeForce GTX 900 pourront profiter pleinement des optimisations liées au traitement concomitant des tâches, tout comme le feront les Radeon R9 290 par exemple.

Par contre, il reste à voir ce qu'en feront les développeurs. Les gains ne seront pas automatiques et il faudra que les différentes étapes du rendu 3D s'y prêtent. Ce n'était de toute évidence pas le cas pour Battlefield 4 et le Frostbite Engine par exemple, dont la version Mantle ne profite pas réellement de ce type d'optimisation.

Comme nous l'expliquions il y a peu, Microsoft a dévoilé à la GDC les 2 nouveaux niveaux de fonctionnalités de Direct3D 12 : 12_0 et 12_1. Mais d'autres segmentations plus subtiles existent, de quoi nous laisser penser que les départements communications d'AMD et de Nvidia pourraient se battre à coups de niveaux de support de DirectX 12.

De toute évidence, Microsoft avait demandé à AMD et Nvidia de ne pas lancer de polémique à la GDC sur le niveau de support des spécifications de Direct3D 12 de leurs GPU. Il n'y a ainsi eu aucune communication officielle à ce sujet mais nous avons pu gratter quelques détails lors de discussions informelles ou en posant des questions à la fin des différentes sessions.

Tout d'abord, nous pouvons confirmer que les GeForce Maxwell de seconde génération (GTX Titan X, 980, 970 et 960) supportent bien le niveau de fonctionnalité le plus élevé : 12_1. Il a de toute évidence été modelé d'après les spécifications de l'architecture de Nvidia. Nous ne savons par contre toujours pas s'il existe des GPU actuellement commercialisés de niveau 12_0.

Cela ne veut pas dire pour autant que les dernières GeForce GTX supportent la totalité des possibilités de Direct3D 12. Ainsi, en plus des niveaux de fonctionnalités, des niveaux de support appelés Tiers existent pour différents points.

Le principal concerne les capacités de gestion des différentes ressources (Resource Binding) qui augmente en passant du Tier 1 au Tier 2 et atteint un niveau presqu'illimité au Tier 3. Microsoft a précisé que sur base des dernières statistiques de Steam, et en ne prenant en compte que le matériel compatible avec Direct3D 12, 39% du parc installé est limité au Tier 1, 44% au Tier 2 et 17% supporte le Tier 3. Mais quel GPU supporte quel Tier ?


Selon nos informations, les GPU Maxwell sont en fait limités au Tier 2, qui est nécessaire au support des niveaux 12_0 et 12_1 et qui a probablement lui aussi été modelé autour de leurs capacités. Une des différences les plus importantes avec le Tier 3 concerne la gestion des Constant Buffer Views (CBV) : ceux-ci ne sont pas virtualisés et sont limités en nombre à 14. Il est probable que l'architecture Maxwell soit capable de virtualiser les CBV, mais que l'implémentation logicielle/matérielle de Nvidia profite d'un mode plus performant avec une gestion "fixe" des Constant Buffers. Un compromis qui limite quelque peu la flexibilité accordée aux développeurs pour s'assurer que les GPU GeForce restent dans un mode optimal sur le plan des performances.

Mais alors à qui correspond les 17% de GPU compatibles Tier 3 ? Toujours selon nos informations, il s'agit des Radeon de type GCN qui profitent d'une architecture très flexible à ce niveau. D'un côté les GeForce GTX 900 supportent le niveau 12_1, d'un autre les Radeon R9 200 supportent le Resource Binding Tier 3. Un combat de spécifications en perspective ? Difficile pour AMD d'attaquer les GTX 900 sur base de cela pour l'instant… mais cela risque de changer avec Fiji. Si ce futur GPU supporte le niveau 12_1 et le Tier 3, nul doute que vous en entendrez parler ! Si par contre Fiji est limité au niveau 12_0 et Tier 3, chacun devra préparer ses arguments.

Au final, voici comment le support des Resource Binding Tiers est de toute évidence réparti sur PC :

Tier 1 : Nvidia Fermi, Intel Haswell et Broadwell
Tier 2 : Nvidia Kepler et Maxwell 1/2
Tier 3 : AMD GCN

A noter que pour les fonctionnalités spécifiques au niveau 12_1, les Raster Ordered Views et la Conservative Rasterization, il existe également des Tiers 1 et 2 dont les spécificités nous sont pour l'heure inconnues. L'implémentation de Nvidia se limiterait au Tier 1 et il pourrait être possible là aussi pour AMD d'essayer de se démarquer. Affaire à suivre.