Les contenus liés au tag GDC

Durant la journée des tutoriaux, la session dédiée à Direct3D 12 à laquelle nous avons assisté était destinée à donner quelques conseils aux développeurs intéressés par cette API. Une poignée de spécialistes des moteurs graphiques ont fait partie de la phase d'essai de D3D12 et ont travaillé sur des portages betas, souvent en collaboration avec AMD et Nvidia. Des premières expériences qui ont permis de façonner les détails de l'API et de partager certains conseils.

Durant cette présentation, Evan Hart, Principal Engineer chez Nvidia, et Dave Oldcorn, D3D12 Technical Lead chez AMD, ont rappelé que "de grands pouvoirs impliquent de grandes responsabilités". Entendez par là que le niveau de contrôle plus élevé donné aux développeurs leur permet de faire plus de choses et plus efficacement, mais uniquement s'ils exploitent correctement l'API. Une implémentation hasardeuse peut causer plus de problèmes qu'elle ne tente d'en résoudre.

Une expérience des développeurs sur console, même si elle n'est bien entendu pas obligatoire, est clairement en avantage puisqu'il y a des similitudes entre leurs API propriétaires et les nouvelles API de plus bas niveau. Il est d'ailleurs utile de rappeler qu'un certain niveau d'abstraction reste présent et que les développeurs doivent s'attendre à ce que les pilotes gardent en partie la main sur certains points.

Un portage d'API bête et direct vers D3D12 n'a pas réellement de sens. Pour réellement profiter de l'API, une réflexion en amont sur ses possibilités et ce qu'il est possible d'en faire en pratique est nécessaire. Il faut ainsi par exemple prévoir un bon multithreading, D3D12 ne s'en charge pas tout seul par magie. Il revient aux développeurs de bien segmenter et organiser toutes les tâches liées au rendu, et de préciser dans certains cas explicitement quand elles ne peuvent pas être traitées en parallèle. Par sécurité D3D11 présume qu'il y a d'office une dépendance entre certaines tâches, ce qui empêche leur exécution en parallèle et freine les performances. Tout cela disparaît avec D3D12, mais le développeur doit alors indiquer quand il y a une réelle dépendance, sans quoi il y aura bien entendu des problèmes.

Parmi les autres premiers retours abordés, citons ceux-ci :

- Le mieux est l'ennemi du bien et il peut être nécessaire de rechercher un compromis entre réduction maximale du surcoût CPU, via exécution groupées de nombreuses listes de commandes, et latence globale.

- Attention au budget mémoire. Si le développeur alloue trop de mémoire résidente (soit spécifiée en mémoire vidéo), un plantage peut arriver très vite. C'est particulièrement le cas en mode fenêtré dans lequel l'OS reprend la main sur une partie de la mémoire vidéo. En cas de possibilité de passer du plein écran au fenêtré il faut prévoir d'agir très vite sur la quantité de mémoire utilisée, par exemple en supprimant directement les plus hauts niveaux des mipmaps.

- Faire attention aux bus ! Vu qu'une API telle que D3D12 permet d'envoyer beaucoup plus d'objets, des nouveaux goulets d'étranglement peuvent apparaître, c'est par exemple le cas du bus PCI Express qui peut être saturé.

Vous pourrez l'intégralité de cette partie de la présentation ci-dessous :

La Game Developers Conference (GDC) de San Francisco vient d'ouvrir ses portes et nous sommes sur place pour couvrir l'évènement, tout du moins la partie qui nous intéresse, celui-ci étant particulièrement vaste.

Cette année, ce sont le streaming, la réalité virtuelle et Direct3D 12 qui sont particulièrement mis à l'honneur avec de nombreuses conférences, démonstrations et autres tutoriaux. Cette première journée est d'ailleurs tournée entièrement vers ce dernier point avec des Bootcamp divers et variés en parallèle desquels sont organisés toute une série de tutoriaux sur Direc3D 11 et 12.

Ces tutoriaux sont présentés mains dans la main par AMD et Nvidia, accompagnés de quelques développeurs qui font partie des premiers à avoir expérimenté Direct3D 12. AMD et Nvidia tiennent d'ailleurs à insister sur le fait d'avoir été agréablement surpris d'être totalement sur la même longueur d'onde concernant les réflexions partagées sur cette API, alors qu'il y avait traditionnellement plus de désaccords plus ou moins stratégiques.

Si vous n'avez pas suivi les premiers développements concernant Direct3D 12, voici un bref rappel de ses caractéristiques :


A noter que Direc3D 12 ne sera pas la seule API de plus bas niveau discutée à la GDC, puisque Khronos sera également de la partie et dévoilera officiellement "OpenGL Next", dont nous vous parlerons demain matin à la levée de l'embargo le concernant.

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

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


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

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

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

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

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

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

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


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

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

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

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

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

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

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

Durant la GDC, Nvidia n'a pas seulement parlé de Direct3D 12 mais a également tenu à revenir sur le travail qui a été fait au niveau de son pilote Direct3D 11, de manière à réduire autant que possible le coût de la gestion des commandes de rendu. Nvidia estime qu'il disposait depuis longtemps d'un petit avantage sur ce point par rapport à la concurrence et l'annonce de Mantle l'a incité à aller plus loin dans ce sens.

Ses ingénieurs ont ainsi mis les bouchées doubles pour réduire le coût de plusieurs fonctions de Direct3D 11 mais également pour peaufiner l'implémentation des "deferred contexts". Pour rappel, ceux-ci permettent aux développeurs d'implémenter un support du multi-threading au niveau de la préparation des commandes de rendu. Malheureusement, ils sont peu efficaces et difficiles à implémenter compte tenu des interactions hors de contrôle entre l'application, l'API et les pilotes.

Nvidia a cependant estimé qu'il y avait moyen de mieux faire. Sa première implémentation des "deferred contexts" était très sommaire mais fonctionnelle et un peu plus performante que l'émulation proposée directement par l'API en cas de non intégration dans les pilotes comme cela serait le cas du côté d'AMD. Même si l'implémentation de Nvidia restait supérieure, ses résultats n'étaient pas très enthousiasmants pour les développeurs, ce qui explique la mauvaise réputation de cette fonctionnalité de Direct3D 11 auprès des développeurs. La deuxième implémentation de Nvidia serait par contre nettement plus efficace et rendrait la fonctionnalité enfin réellement bénéfique, si bien entendu les développeurs y font appel.

Nvidia nous a présenté quelques slides qui mettent en avant des gains observés en interne, autrement dit à prendre avec des pincettes même si la tendance affichée est probablement réaliste :


Ces slides comparent les pilotes Catalyst 14.2 aux pilotes r331, r334 ainsi qu'à une nouvelle version de ses pilotes qui ne devrait plus tarder à sortir (r336 ?). Suite à ces différentes évolutions, Nvidia met en avant des réductions du coût CPU de plusieurs fonctions de D3D11 de l'ordre de 2x, 4x, 5x, voire 8x dans le cas le plus favorable.

Avec ces gains associés à l'amélioration du support des "deferred contexts", Nvidia estime pouvoir même surpasser la solution d'AMD en version Mantle dans Star Swarm et Thief. Bien entendu il s'agit probablement ici de cas très favorables plus que de moyennes représentatives, mais force est de constater que Nvidia a entrepris un réel effort au niveau de ses pilotes Direct3D 11. Mantle aura décidemment été bénéfique pour tous !

Durant les sessions de la GDC consacrées à Direct3D 12, Microsoft et ses partenaires se sont abstenus de rentrer dans trop de détails concernant le support matériel et logiciel. Nous avons cependant pu nous entretenir avec de nombreux ingénieurs et architectes de Microsoft et ses partenaires, qu'ils soient concepteurs de GPU ou de moteurs graphiques. Si tout le monde préfère éviter une déclaration officielle sur les points délicats, nous avons pu en apprendre un peu plus, notamment au sujet de ce qui devrait se passer pour Windows 7...

Il faut tout d'abord bien comprendre que Microsoft a dévoilé Direct3D 12 bien plus tôt dans son processus de développement qu'à l'accoutumée. Les détails sont ainsi toujours en cours de discussion et pourraient être amenés à évoluer même si tout le monde est d'accord pour nous dire que les points principaux sont fixés.

Pour finaliser les spécifications de son API, Microsoft explique avoir voulu intégrer beaucoup plus de retours de ses partenaires, notamment au niveau logiciel. Ainsi, des débuts de portage de moteurs vers Direct3D 12 ont été entrepris avant la finalisation de ses spécifications, de manière à profiter de cette expérience pour les fixer. Microsoft entend s'assurer d'éviter que de bonnes idées sur le papier deviennent des problèmes en pratique, et surtout, que les développeurs conservent leur préférence pour Direct3D dans le monde PC.

Une API avec un niveau d'abstraction globalement plus bas ouvre de nombreuses portes, donne bien plus de marge de manœuvre aux développeurs en faisant disparaître la plupart des limites actuelles. Sans rentrer dans le détail, Microsoft a cependant indiqué que certaines limites artificielles pourraient être imposées notamment pour éviter que les développeurs ne fassent des choses néfastes pour le rendement énergétique, un point important dans le cadre de l'utilisation de Direct3D 12 dans le monde des tablettes ou dans un futur Windows Phone. Microsoft profite à ce sujet de l'arrivée de Qualcomm dans le premier cercle des partenaires de développement de son API.

Selon plusieurs sources, Direct3D 12 et Direct3D 11 devraient continuer à évoluer en parallèle, tous les développeurs n'étant pas prêts à passer directement à un nouveau type d'API qui leur donne plus de responsabilité. Le niveau de support matériel devrait d'ailleurs être cette fois totalement découplé de la version de l'API. Ainsi il n'est pas impossible de voir de nouveaux niveaux de fonctionnalités pour Direct3D 11 qui s'arrête actuellement au 11_1.

Au niveau du support matériel de Direct3D 12, Microsoft a précisé qu'il était possible dès le niveau de fonctionnalité 9_3. Par contre, pour supporter Direct3D 12, en plus de supporter les fonctionnalités graphiques liées au niveau matériel minimum, l'architecture du GPU devra être capable de certaines choses. Le point principal est l'inclusion d'une MMU (Memory Management Unit) pour virtualiser et protéger la mémoire vidéo/système, ce qui est logique compte tenu de la manière dont fonctionne Direct3D 12. C'est la raison pour laquelle AMD et Nvidia ne peuvent pas proposer un support pour Direct3D 12 qui remonte aussi loin en arrière que leurs GPU de classe 9_3. Par contre dans le monde mobile il existe des GPU 9_3 relativement récents qui incluent une MMU et qui pourront donc supporter Direct3D 12. Rappelons qu'AMD a annoncé un support de la nouvelle API pour tous ses GPU GCN, Nvidia pour tous ses GPU depuis la génération Fermi et Intel pour les CPU Haswell. Dans le cas de Qualcomm, ses GPU récents sont capables du support et il sera proposé au cas par cas suivant les demandes de ses clients. Enfin, la Xbox One supportera Direct3D 12.

Y aura-t-il de nouveaux niveaux de fonctionnalités matérielles ? Bien entendu, Microsoft a d'ailleurs cité quelques exemples dès sa première conférence avec la rastérisation conservative et le blending programmable, mais tout en insistant sur le fait que, dans un premier temps, cela serait secondaire. Le but principal est d'apporter sous Windows une API avec overhead réduit et le plus gros des efforts est concentré sur ce point.

Il pourrait y avoir des niveaux 11_x supplémentaires et des niveaux 12_x, soit directement soit par la suite (Direct3D 12.1…). Il n'est d'ailleurs pas impossible que ces derniers soient rendus disponibles sous Direct3D 11. Les détails à ce niveau sont toujours en cours de finalisation, notamment entre ce qui fera l'objet d'un nouveau niveau ou de "caps". Nvidia indique que ses GPU Maxwell sont capables d'aller au-delà des niveaux de fonctionnalités actuels, sous-entendant qu'ils supporteront un éventuel niveau 12_0. Un point étrange alors même que le niveau 11_1 n'est pas supporté. Nous devrions en savoir plus cet été.

L'autre grande question concerne le support logiciel. Microsoft se contente d'indiquer discrètement dans une slide que les pilotes WDDM 2.0, qui devraient être spécifiques à Windows 9, apporteront des réductions du surcoût CPU de la gestion des commandes de rendu. Ce qui sous-entend que d'autres modèles de pilotes WDDM qui apporteraient moins de réduction pourraient être supportés. D'un autre côté, lors d'une session Direct3D 12 organisée en dernière minute par AMD, Johan Andersson (Frostbite Engine, EA/DICE) a clairement affiché son souhait d'un support de Direct3D 12 sous Windows 7, espérant que Microsoft en saisisse l'intérêt. Officiellement, c'est tout ce qui est ressorti des présentations.

En coulisses, les langues se délient quelque peu. En réalité tout le monde serait convaincu de la nécessité de proposer Direct3D 12 sous Windows 7, et particulièrement l'équipe DirectX de Microsoft qui y voit un bon moyen d'inciter les développeurs à passer rapidement vers la nouvelle API. De quoi également renforcer l'influence de Microsoft et de la plateforme Windows dans le monde du jeu vidéo, notamment par rapport à la menace que représente Steam OS.


Microsoft a déjà pris soin de s'assurer auprès des fabricants de GPU que tout cela était réaliste au niveau des pilotes et que les barrières éventuelles pouvaient être facilement contournées. Le seul frein actuel à l'annonce du support de Windows 7 et à la finalisation de son implémentation serait le management supérieur de Microsoft, qui resterait hésitant par rapport à son premier réflexe de vouloir associer les nouveautés à un nouvel OS. Tout le monde semble cependant convaincu qu'il ne s'agit que d'une question de temps avant que les responsables ne se résolvent à accepter l'évidence.

Selon tous nos interlocuteurs, sauf énorme surprise, le support de Direct3D 12 devrait donc bien être proposé sous Windows 7. Par contre il n'est pas certain que toutes les nouvelles fonctionnalités le soient. Microsoft pourrait ainsi opter pour un compromis de type Direct3D 11 et 12 limités aux niveaux de fonctionnalités 11_x sous Windows 7 avec de futurs niveaux 12_x exclusifs à Windows 9, ce qui serait un moindre mal. Affaire à suivre donc…