Les derniers contenus liés aux tags Microsoft et DirectX 12

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

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

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

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

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

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

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

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


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

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


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

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

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

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

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

Microsoft a dévoilé cet après-midi l'organisation des feature levels, soit des nouveaux niveaux de fonctionnalités de Direct3D 12. Finalement ce seront 2 nouveaux niveaux qui vont être introduits : 12_0 et 12_1.

Le niveau 12_1 apporte spécifiquement le support des Raster Ordered Views et de la Conservative Rasterization. La première fonctionnalité permet de contrôler le respect de l'ordre de rendu des différents éléments de la scène, ce qui est par exemple nécessaire lorsqu'il y a plusieurs niveaux de transparence à respecter, et la seconde permet de vérifier si une primitive est présente dans n'importe quelle petite partie de la zone couverte par un pixel et pas simplement présente en son centre. De quoi pouvoir mieux évaluer sa couverture, ce qui est nécessaire pour certains algorithmes.

Nous vous avions déjà parlé de ces fonctionnalités lors du lancement de la GeForce GTX 980 et de Maxwell de seconde génération, ce qui implique que ces GPU Nvidia récents supporteront bien le niveau 12_1 en plus du 12_0.

Nous ne savons pas encore quels GPU supporteront le niveau 12_0, AMD ne nous ayant pas encore répondu par exemple. Il n'est pas impossible que certains GPU de génération DirectX 11 en soient capables. Rappelons qu'il sera bien entendu également possible d'exploiter à travers Direct3D 12 le matériel limité aux niveaux de fonctionnalités inférieurs, du moment que le GPU supporte une MMU (Memory Management Unit). Les niveaux 11_x seront ainsi exploitables pour la plupart des GPU de la génération DirectX 11 (pas avant GCN chez AMD).


Une autre segmentation existera pour les GPU supportés avec 3 niveaux (Tiers) de capacités de gestion des différentes ressources (Resource Binding). Un GPU devra supporter au moins le Tier 2 pour pouvoir prétendre au niveau de fonctionnalité 12_0. Sans donner plus de détails, Microsoft indique 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. Des chiffres qui seront tirés vers le haut d'ici la sortie de Windows 10.

Nous avons pu poser quelques questions à Microsoft après la présentation et ainsi confirmer que ces niveaux de fonctionnalités 12_0 et 12_1 seront également exposés à travers Direct3D 11.3. Cette mise à jour pour Direct3D 11 ne sera par contre pas proposée en dehors de Windows 10. Microsoft tient d'ailleurs à insister à ce sujet sur le fait qu'un nouvel OS gratuit à la place d'une mise à jour de l'API n'est pas un mauvais deal pour les joueurs, ce qui n'est pas faux il est vrai.

Enfin, au niveau des améliorations matérielles éventuelles à apporter pour parfaire le support de Direct3D 12, Microsoft nous a indiqué qu'un point inhabituel jusqu'ici était ressorti : les processeurs de commandes des GPU peuvent être saturés. C'est assez logique puisque Direct3D 12 permet d'augmenter fortement le nombre de commandes de rendu qu'ils doivent prendre en charge. Muscler ces processeurs de commandes pourra ainsi être bénéfique à l'avenir.

AnandTech a publié un article  consacré à DirectX 12 se concentrant principalement sur des benchmarks obtenus sous Windows 10 Technical Preview 2 sous une version Direct3D 12 de Star Swarm Stress Test fournie par Oxide et Microsoft. Ce nom ne devrait pas vous être inconnu puisque cette démo dispose d'une version Mantle utilisée par AMD pour démontrer les bienfaits de son API à son lancement, mais elle a aussi déjà été utilisée en août dernier en version DX12 par Intel et Microsoft pour montrer les avantages du futur Direct3D.

Avant de passer aux résultats, nos confrères ont eu la confirmation par Microsoft que DirectX 12 ne sera disponible que sous Windows 10. Sachant que la mise à jour sera gratuite si effectuée durant la première année du lancement, cette annonce n'est pas problématique. Pour supporter DirectX 12, Windows 10 intègre la version 2 du WDDM. Côté GPU AMD et Nvidia disposent bien sûr de pilotes beta WDDM 2.0 et DX12, ce sont les versions 394.56 et 15.200 qui ont été fournies à nos confrères. A l'heure actuelle les pilotes AMD supportent les GPU GCN 1.0, 1.1 et 1.2, mais pour le moment Star Swarm Stress affiche des bugs de texture sur GCN 1.0. Côté Nvidia le support des Kepler et Maxwell est fonctionnel, mais les Fermi ne sont pas encore gérés.

Côté benchmark c'est donc sans grande surprise que les résultats obtenus sont très bons dans ce test très lourd en termes de draw calls. Ainsi une GeForce GTX 980 passe de 26,7 fps en D3D11 à 66,8 fps en D3D12, alors qu'une Radeon R9 290X est à 8,3 fps en D3D11, 42,9 fps en D3D12 et 45,6 fps sous Mantle. On note ici un avantage à Mantle sur ce test effectué avec 4 cœurs et confirmé avec 6 cœurs, mais avec 2 cœurs seulement c'est D3D12 qui reprend l'avantage avec 42,9 fps au lieu de 37,6 fps. Ces écarts sont en partie liés à un temps de traitement des lots de commande plus important sous Mantle du fait d'une optimisation du moteur effectuant une seconde passe côté CPU pour les optimiser, ce qui permet d'alléger la charge GPU au dépend de la charge CPU. Une fois celle-ci désactivée le temps de traitement des lots de commande est équivalent entre les deux API, par contre D3D12 repasse devant puisque sur 4 coeurs Mantle passe à 39,3 fps.

Pour rappel, pour contrer l'offensive Mantle, Nvidia a optimisé tant que possible les performances des commandes D3D11 via des optimisations génériques mais aussi spécifiques à certaines applications dont Star Warm. C'est ce qui explique que la version D3D11 soit 3,2 fois plus rapide sur GTX 980 que sur R9 290X, alors qu'AMD a orienté ses ressources sur Mantle qui reste 71% plus rapide. En Direct3D 12, l'avantage du dernier GPU Nvidia est probablement lié à des performances supérieures dans le traitement de la géométrie et/ou des commandes dans ce cas extrême.


DirectX 12 est donc toujours sur la bonne voie pour tenir les promesses d'une API bas niveau en termes d'allègement et de meilleure répartition entre les cœurs CPU de la charge liée aux commandes de rendu. Des bons résultats qui ont déjà été démontrés par AMD avec l'API Mantle qui a heureusement enfin fait bouger les lignes. Microsoft a encore beaucoup de choses à dévoiler sur DirectX 12, ce qui devrait se faire à l'occasion de la GDC 2015 en mars – on pense notamment au nouveau niveau de fonctionnalité 11_3 ou 12_0. Reste qu'au-delà de l'API et des démos technologiques, il faudra bien sûr voir ce que les développeurs de jeux en feront !