DirectX 10 et GPUs

DirectX 10 a déjà fait beaucoup parler de lui, ne serait-ce que par son nom qui a changé un nombre incalculable de fois en passant par WGF, WGF 2.0, DirectX Next pour enfin revenir au logique DirectX 10 bien que la principale évolution qui nous concerne ici soit Direct3D 10, c’est à dire la partie qui concerne le rendu graphique. DirectX 10 a également fait couler beaucoup d’encre au sujet de son support ou non en dehors de Windows Vista ainsi qu’au sujet d’une architecture unifiée qui serait obligatoire. Il ne s’agissait cependant là que d’un remplissage éditorial sans intérêt de certains puisque Microsoft a toujours indiqué que DirectX 10 aurait besoin de Windows Vista et n’a aucun contrôle sur l’implémentation hardware de son API qui reste entièrement à la discrétion des fabricants de GPUs. La multiplication des documents distribués par Microsoft est l’occasion pour nous de jeter un coup d’œil aux spécifications de cette nouvelle API ainsi que d’exposer quelques réflexions sur les premiers GPU qui la supporteront.

Une API plus légère mais plus riche

Direct 3D 10 est pour Microsoft l’occasion de repartir de zéro ou presque, c’est-à-dire de laisser aux oubliettes les vestiges des fonctions fixes héritées des précédents DirectX. Cette simplification de l’API, qui fait que seuls les GPU D3D10 seront pris en charge par D3D 10, devrait la rendre plus légère et donc aider à ce qu’elle soit moins gourmande en ressources, notamment au niveau du pilotage du GPU qui consomme actuellement beaucoup de temps processeur pour l’envoi des commandes, des données et les diverses vérifications. Globalement Microsoft a travaillé énormément dans cette direction : réduire le temps processeur utilisé dans l’API.


Chiffres à l’appui, Microsoft indique que sa nouvelle API consommera globalement moins de cycles CPU par commande, de quoi en augmenter le nombre et donc la complexité de la scène.

En dehors de ces évolutions intrinsèques à l’API, 2 nouvelles capacités font leur apparition.


Un nouveau type de shaders, les geometry shaders, travaillera sur des primitives (points, lignes ou triangles) et pourra en créer de nouvelles. Les geometry shader agiront sur des données fournies par les vertex shader, et la première utilité que l’on pourrait leur trouver serait de servir d’unité de tesselation pour augmenter les détails géométriques (TruForm, Displacement Mapping etc.). Cependant, il ne s’agit là que d’une petite partie de leur utilité qui, qui plus est, ne devrait pas être utilisée au départ par manque de performances comme Microsoft le précise à plusieurs reprises de manière à ce que les développeurs n’avancent pas dans une mauvaise direction.


La tesselation avec les geometry shaders permettra de faire du displacement mapping, mais il s’agira plutôt de démos technologiques que d’utilisations généralisée en pratique.

On parle plutôt d’amélioration des systèmes de particules (avec la possibilité évidente d’ajouter des particules), d’effets de type fourrure, d’optimisations des rendus dans un cubemap et de calcul de données par primitive qui vont aider le pixel shader à gagner en efficacité. En bref il est probable que la première utilisation de ces geometry shader soit plus abstraite que concrète comme l’est la tesselation. Prenons le cas des cubemaps qui sont utilisés par exemple pour afficher des réflexions sur une voiture. Un cubemap est constitué de 6 faces, comme son nom l’indique, et chacune d’entre elles représente l’environnement autour de la voiture et est rendue une après l’autre. A chaque fois il faut retraiter les vertices et recalculer une image avec un point de vue différent. Avec les geometry shader il sera possible de sextupler chaque triangle (si nécessaire) de manière à pouvoir le rendre dans chaque face où il est visible dans la même passe et donc à pouvoir calculer toutes les faces d’un cubemap en une seule passe ce qui améliorera les performances.



Autre nouveauté : le stream output qui prend place après les geometry shaders. Il permet d’écrire en mémoire les données issues du calcul des vertices après les vertex shaders et les geometry shaders. Avec les GPUs actuels, seuls les pixels peuvent être écrits en mémoire.