Comment Valve porte les jeux DirectX sous OpenGL

Les trois auteurs

I. Introduction

Durant cette conférence des Steam Dev Days, Rich Geldreich, Dan Ginsburg et Jason Mitchell, tous trois employés chez Valve, ont expliqué pourquoi il était intéressant de porter un jeu vidéo vers OpenGL.

II. OpenGL

Vous allez utiliser OpenGL, que ce soit pour cibler les PC (Mac, Linux et Windows), les mobiles (OpenGL ES, certes, mais OpenGL arrive) et les navigateurs (WebGL).

Il faut savoir que la Chine possède de très nombreux utilisateurs utilisant encore Windows XP et que OpenGL peut ainsi permettre d'apporter les dernières technologies sur ce système d'exploitation, là où DirectX 11 ne sera jamais supporté.

Le moteur de Valve, Source 2, tourne autour de Direct3D. OpenGL est implémenté comme un moteur de rendu au même niveau que Direct3D, sauf que ce sont des shaders en HLSL qui sont traduits en GLSL. Valve aimerait bien se débarrasser de Direct3D et tout miser sur OpenGL. Pour cela, l'entreprise travaille en coopération avec les constructeurs de cartes graphiques.

Pour y arriver, Valve mise sur les outils :

  • pour valider les shaders et leur compilation ;
  • pour le débogage des graphismes (NSIGHT s'améliore dans ce domaine) ;
  • pour enregistrer et rejouer une scène (apitrace et vogl).

III. Shaders

III-A. Traduction

Dans la première version du moteur (Source 1), la méthode utilisée traduisait l'assembleur DirectX 9 en GLSL. Toutefois, ce n'était pas une solution idéale, le débogage était dur, des informations étaient perdues et ce n'était pas extensible.

Pour la nouvelle version du moteur, la traduction est effectuée directement au niveau du code source. Il est ainsi plus facile à déboguer, plus facile d'utiliser les nouvelles fonctionnalités d'OpenGL et cela devenait vraiment nécessaire sachant que le bytecode de DirectX 10/11 n'est pas aussi bien documenté que la précédente version. Pour cela, des outils existaient déjà mais ne convenaient pas à leurs besoins :

  • hlsl2glslfork → incompatible avec DirectX 10/11 ;
  • MojoShader → supporte seulement le Shader Model 3.0 ;
  • HLSLCrossCompiler, fxdis-d3d1x → gère l'assembleur DirectX 10/11.

Pour leur traducteur, Valve a décidé d'écrire des macros pour gérer les différences entre GLSL et HLSL. Toutefois, ils se limitent à écrire des shaders qui seront compatibles avec le GLSL et donc, de ne pas utiliser des fonctionnalités trop avancées du HLSL. Finalement, ils utilisent un petit analyseur pour traduire les sémantiques du HLSL. Leur objectif était de n'avoir aucun besoin de chercher les identifiants des variables du GLSL, comme cela est fait en HLSL.

III-B. Validation

Chaque pilote OpenGL possède un compilateur différent. La compilation est donc liée au matériel et à la carte graphique d'une machine. Une solution serait de faire la compilation sur une série de machines de tests, mais cela est trop complexe à mettre en place. L'outil de NVIDIA cgc est quant à lui en fin de vie. Le projet Mesa propose aussi une solution, mais des fonctionnalités importantes manquent.

Finalement, Valve a pensé que ce n'était pas leur souci, mais celui du consortium autour d'OpenGL, qui se devait d'avoir un compilateur de référence. Ainsi, ils ont discuté avec les différents contributeurs et la solution choisie par Khronos est : glslang.

glslang est un outil open source possédant une bibliothèque C et C++, un outil en ligne de commandes et est compatible avec Linux et Windows. Valve a participé à ce projet afin d'y rajouter le support du GLSL v4.20, des Shader Model 4/5 et d'extensions.

III-C. Empaquetage

Généralement, lorsque vous vouliez intégrer des shaders GLSL, vous enregistriez le source dans vos binaires. Vous pouvez aussi les pré-compiler avec l'extension ARG_get_program_binary.

Le fait d'utiliser le code source du shader est lent, mais si la carte graphique a un cache pour les shaders, les compilations d'un même shader seront optimisées. De plus, avec cette solution, le source est accessible en hackant le binaire.

Les binaires étant très dépendants du matériel et du pilote, ils ne sont pas réellement réutilisables.

La solution se situe dans une représentation intermédiaire du shader. Cela permet d'accélérer le temps de compilation, de protéger le source et d'utiliser un seul compilateur de référence. Cette solution existe dans OpenCL SPIR 1.2 mais n'est pas encore disponible dans OpenGL.

IV. Outils

Il faut un nouveau débogueur pour OpenGL. La situation est certes devenue meilleure au fil du temps, mais il reste compliqué de déboguer une application graphique.

Valve propose VOGL :

  • open source ;
  • intégré à Steam ;
  • indépendant des constructeurs de cartes graphiques ;
  • il n'est pas nécessaire de recompiler l'application ;
  • capable de capturer les images ou une vidéo ;
  • possède un lecteur de capture optimisé ;
  • permet de valider l'utilisation d'OpenGL ;
  • permet le test de régression et l'étude des performances ;
  • support OpenGL 3/4.x et les différents contextes ;
  • possède une interface utilisateur pour éditer les captures, inspecter les états, faire des différences entre les captures, contrôler la trace.

V. Vidéo


Cliquez pour lire la vidéo


VI. Commenter

Vous pouvez commenter et donner vos avis dans la discussion associée sur le forum.

En complément sur Developpez.com

  

Copyright © 2014 Équipe rubrique 2D/3D/Jeux. Aucune reproduction, même partielle, ne peut être faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu'à trois ans de prison et jusqu'à 300 000 € de dommages et intérêts.