Cette domination de Direct3D est donc un gros problème pour tous les développeurs souhaitant réaliser des jeux multiplateformes. Il est quasiment indispensable d’utiliser Direct3D pour la version Windows et Xbox, car les pilotes OpenGL sont souvent à la traine niveau performances, et OpenGL pour toutes les autres plateformes, sur lesquelles Direct3D n’est pas nativement disponible.
Pour simplifier cette opération, certains ont recours à un empilement d’API. Ainsi, plutôt que d’utiliser directement Direct3D dans le code de leur jeu, ils vont passer par une API 3D intermédiaire (comme celle fournie par exemple par le moteur Unity), cette API se chargeant ensuite de « traduire » ses propres fonctions en appels à des fonctions de la principale API 3D disponible sur le système. S’il est pratique pour le développement, cet empilement n’est pas bon pour les performances, cette couche de traduction imposant forcément du temps de calcul en plus.
Une autre approche, toujours par empilement d’API, peut consister à utiliser Direct3D dans le jeu, et à intercaler sur les autres plateformes une API intermédiaire exposant les mêmes fonctions que l’API Direct3D, mais en les implémentant via des fonctions OpenGL. Moins performante et souvent plus sujette aux bugs, cette approche est généralement réservée aux jeux dont la décision de portage intervient tardivement dans le cycle de développement. La société TransGaming s’est par exemple spécialisée dans ce type de portages, en s’appuyant sur le projet Wine, une implémentation open-source sous Unix des principales API Windows, y compris Direct3D.
Pour éviter ces empilements d’API, il faudrait privilégier des API indépendantes du système, comme OpenGL, mais à condition que leur implémentation dans les drivers Windows soit efficace. Et justement, Khronos, le groupe de travail à l’origine d’OpenGL a peut-être l’occasion de prendre sa revanche contre Microsoft et de refaire son retard dans les années à venir, grâce à un nouveau mouvement initié par AMD il y a trois ans avec l’API Mantle : le retour à des API 3D plus « bas niveau », et limitant autant que possible le travail réalisé par le CPU, pour le décharger au maximum vers le GPU. Avec les API 3D classiques, le GPU est en effet souvent limité par le CPU, et c’est d’autant plus vrai lorsque plusieurs couches d’API sont empilées, toutes les couches intermédiaires étant gérées exclusivement par le CPU. Khronos a largement repris les travaux d’AMD pour mettre au point sa propre API 3D bas niveau, qui a été publiée en version 1.0 il y a quelques jours : Vulkan.
Si Microsoft a bien entendu lui aussi pris le train en marche et repris des concepts de Mantle dans son Direct3D 12, Vulkan pourrait prendre l’avantage grâce à son support matériel bien plus large et à son caractère multiplateforme, avantage de poids dans un marché du jeu vidéo qui n’est plus aussi centré sur Windows qu’il y a dix ou vingt ans. En effet, alors que Direct3D 12 est réservé à des cartes graphiques relativement récentes et à des PC sous Windows 10, Vulkan est rétro compatible avec tous les GPU OpenGL 4 et OpenGL ES 3.1 et est d’ores et déjà disponible sous Android, Linux et Windows. Concrètement, ces prérequis correspondent à des GPU dont certains sont sortis il y a près de 10 ans, comme par exemple les GeForce de la série 8000 ou encore les toutes premières Radeon HD (pour l’instant le support par les drivers est toutefois limité chez la plupart des constructeurs aux GPU de moins de quatre ans, ce qui réduit quelque peu la portée de cette rétrocompatibilité).
Il s’agit donc là d’une occasion en or pour Khronos d’inverser la tendance, et de faire de Vulkan la nouvelle API de référence pour la 3D, avec une solution performante et compatible avec tous les OS. Mais Microsoft ne va probablement pas se laisser faire, d’autant qu’il a encore quelques atouts dans sa manche, dont le fait que Direct3D est un composant d’une API bien plus large (DirectX), très utilisée et couvrant aussi d’autres domaines (le son, la gestion des manettes de jeu, etc…), alors que les autres API de Khronos Group sont plus minoritaires, seul OpenGL et OpenCL ayant tiré leur épingle du jeu. Il sera donc intéressant de garder un œil sur ces deux acteurs dans les prochains temps, pour voir si Khronos parviendra à détrôner Microsoft, et en espérant que cette concurrence relancée profite à tout le monde et qu’elle se fasse loyalement et sans coup bas (Microsoft a un certain passif en la matière, notamment avec une forte baisse des performances OpenGL sous Windows lors du passage de XP à Vista…). Khronos a d’ores et déjà obtenu une première victoire, en remportant l’adhésion de Valve, qui voit en Vulkan une bonne occasion de pousser SteamOS auprès des joueurs.