Les contenus liés aux tags DirectX 12 et GDC 2015

Sur le stand de Microsoft, nous avons pu apercevoir le premier test Direct3D 12 de Futuremark. Toujours en phase beta, il devrait être proposé en même temps que la sortie de Windows 10.

Il s'agit d'un test synthétique destiné uniquement à mesurer la capacité des systèmes à encaisser un nombre élevé de draw calls, soit d'objets dans la scène. Une sorte de ville futuriste est rendue avec une complexité qui augmente jusqu'à ce que le niveau de performances se stabilise autour de 30 fps. Plus le système est performant, plus le test dure longtemps.

Sur le stand de Microsoft, le benchmark tournait sur un CPU Intel Core i7 4770R dont le core graphique était chargé du rendu. Voici les performances relevées :


D3D11 Single Thread : 0.664 million de draw calls / seconde
D3D11 Multi Thread : 0.698 million de draw calls / seconde
D3D12 (Multi Thread) : 2.166 millions de draw calls / seconde

Dans ce test, le multi-threading sous D3D11, visiblement peu optimisé, n'apporte qu'un maigre gain de 5%, alors que D3D12 multiplie les performances par un facteur de plus de 3x.

Par ailleurs il faut noter que si la fréquence du GPU Intel est relativement faible en mode D3D11, elle grimpe en mode D3D12, signe que le GPU est soumis à une charge bien plus élevée. Il est donc possible qu'il devienne le facteur limitant et que les gains soient encore plus élevés dans ce test avec une GeForce ou une Radeon dédiée.

Avec Mantle, AMD entendait faire bouger les lignes et démontrer qu'une API de plus bas niveau était quelque chose de réaliste, de réellement exploitable et non une source de complications insensée pour les jeux AAA. Il ne fait aucun doute que cet objectif a été atteint. Face à l'engouement des développeurs, Microsoft a rapidement annoncé prendre une voie similaire avec Direct3D 12 et le groupe Khronos a fait de même. Du coup, quel est l'avenir pour Mantle ?

Lors de l'annonce de Mantle, AMD avait indiqué avoir pour objectif, à termes, d'ouvrir son API à d'autres acteurs, si ceux-ci étaient intéressés. Toutes les options étaient alors sur la table, mais AMD avait bien insisté dès le départ sur le fait que son intention était d'apporter une solution à un problème et non de tenter de forcer l'utilisation d'une API propriétaire pour en obtenir un avantage stratégique.

Un premier billet  publié sur le blog d'AMD il y a quelques jours a pu laisser penser que Mantle était abandonné au profit de DirectX 12. AMD y expliquait en effet l'arrivée sous peu d'un guide de programmation de 450 pages pour Mantle, mais l'abandon du projet de rendre public le SDK complet. Mantle reste totalement supporté par AMD pour les développeurs qui l'utilisent déjà, mais AMD réoriente les autres vers les API telles que Direct3D 12 et ce qui était alors connu sous le nom de GLnext. L'API Vulkan n'ayant pas encore été annoncée, AMD n'était pas très clair dans sa communication.

Un second billet  publié après l'annonce de Vulkan a clarifié quelque peu la situation. De notre côté, à la GDC, nous avons pu aborder la question avec AMD et plus particulièrement avec Raja Koduri, Corporate Vice President Visual Computing, et Richard Huddy, Chief Gaming Scientist. Grossièrement, pour AMD, Vulkan est ce qu'aurait été un éventuel "open Mantle", et ce dernier n'a du coup plus aucune raison d'être.

AMD a offert Mantle comme base de travail au groupe Khronos, ce qui lui a permis d'avancer plus vite qu'à l'accoutumée. Il n'y avait bien entendu pas de raisons de réinventer la roue et de nombreux aspects de Vulkan sont très proches, voire identiques, à Mantle. Selon AMD, les modifications les plus importantes qui ont été apportées sont liées aux spécificités des GPU de type TBDR (PowerVR etc.). Nvidia, qui semble plutôt de mauvaise foi sur ce coup, voit les choses sous un autre angle et tente de rabaisser Mantle autant que possible, en ironisant sur l'inévitabilité de sa disparition. Pas simple d'admettre l'influence du travail de son concurrent.

Si Mantle 1.0 n'a plus réellement de raison d'être, excepté pour les jeux déjà en développement et qui vont arriver sous peu, le concept de Mantle est loin d'être mort. AMD explique ainsi qu'il y a d'autres demandes des développeurs au niveau de l'évolution des API et que ses équipes sont prêtes à essayer d'y apporter des réponses. Il ne faut pas insister beaucoup pour que Mantle 2.0 soit prononcé, et bien que nous n'avons pas pu savoir ce qu'AMD avait en tête, il nous a semblé évident que quelque chose est déjà en préparation. AMD s'est contenté de nous dire que sa stratégie reste d'expérimenter en vue d'apporter une solution concrète à un problème donné avec pour objectif d'ouvrir à tous le résultat de ce travail, pour peut-être influencer à nouveau la formation des futures API.

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.