Rencontre avec Chuck Walbourn

Nous avons récemment pris contact avec Chuck Walbourn (Microsoft) pour lui poser quelques questions au sujet des jeux 64 bits afin de voir comment la situation avait évolué depuis ses deux interventions au Gamefest. Signalons à tous ceux qui n’ont pas peur de l’anglais que l’article qu’il a écrit chez Gamasutra sur le jeu, la mémoire et l’informatique 64 bits a été un précieux préambule à nos échanges. Chuck Walbourn est ingénieur en conception logicielle au sein de la XNA Developer Connection, équipe qui travaille avec les développeurs de jeux Windows et Xbox 360 à travers le monde.

Tom's Hardware : Nous n’avons constaté que très peu d’écart de performances en passant d’une plateforme 32 bits à 64 bits lors des tests pour cet article, comment peut-on l’expliquer ?

Chuck Walbourn : On en vient au problème fondamental de la technologie x64 64 bits : elle ne permet pas vraiment « d’aller plus vite » mais rend possible de nouvelles utilisations sans sacrifier les performances avec des applications 32 bits. C’est un problème clé dans la transition. En fait on abandonne la possibilité d’exécuter du code 16 bits natif lorsque le processeur fonctionne en 64 bits (c’est le cas avec Windows x64), mais c’est uniquement une contrepartie liée au matériel pour limiter la compatibilité avec l’ancien code qui remonte à l’époque de Windows 3.1.

Qu’est-ce qui peut donc me pousser à rajouter de la mémoire dans ma configuration si je suis développeur ?

L’argument le plus évident en faveur des OS x64 est leur capacité à gérer plus de mémoire. Comme je l’ai mentionné dans l’article chez Gamasutra, si l’on a 4 Go ou plus de RAM, on gâche des ressources matérielles à travailleur sur autre chose qu’un OS x64. On peut le voir d’une certaine manière dans des scénarios très courants : une mémoire virtuelle étendue et une capacité à gérer plus de processus en même temps (ce qui est particulièrement important avec des machines quad-core/octo-core musclées). On a vu bon nombre de développeurs adopter assez rapidement le x64 pour cette seule raison et ce, même s’ils n’utilisent aucune application 64 bits native. Une configuration octo-core avec 16 ou 32 Go de DRAM tournant sous Windows Vista x64 peut gérer du code comme rien d’autre dans un environnement multitâche. DICE, Epic, Valve, Crytek, Starbreeze et d’autres développeurs uniformisent tous leur parc informatique en x64 pour utiliser de grandes quantités de mémoire dans les processus de développement, d’autant plus que les prix de la RAM baissent extrêmement vite pour ce genre de configurations.

Les choses deviennent vraiment intéressantes une fois que la capacité 64 bits est là.

Une de vos trois recommandations était de pousser les développeurs à au moins activer le /LAA. Peut-on dire de façon simple qui en a tenu compte et agi en ce sens ?

Le "Large Address Aware" existe depuis des années mais son utilisation a toujours été limitée à des scénarios techniques extrêmes parce que le fait de démarrer un OS 32 bits de façon à en profiter n’est pas si simple que ça. Là où je voulais en venir au Gamefest 2007, c’est que Windows x64 rend l’utilisation du "Large Address Aware" potentiellement indolore. Après, le LAA nécessite la vigilance des développeurs, en particulier avec les librairies tierce partie et le code source, et permet seulement à l’application de bénéficier de 4 Go d’espace adressable et non pas 8 To. Ca reste une technologie de jonction qui permet aux applications 32 bits d’aller au-delà des 2 Go, à ceux qui ont des plateformes Windows x64 de bénéficier de textures plus détaillées, de caches de données continues plus importants ou encore de tout ce qui aurait excédé les limites d’une application 32 bits standard.

Les développeurs de jeux sont déjà plafonnés dans leurs contenus par cette limite de 2 Go. Pour Crysis, Crytek a du créer un éditeur x64 natif pour être à même de créer des niveaux qui, après optimisation complète, remplissent les 2 Go disponibles pour les applications standard sans pour autant être capable de faire tourner la version éditable en tant qu’application 32 bits standard. Flagship Studios s’est largement appuyé sur des programmes serveur x64 natifs, ce qui rend les processus plus résistants à la fragmentation de l'espace mémoire. Le Visual Studio linker est une application du LAA depuis des années, et son utilisation sur des systèmes Windows x64 permet aux développeurs de lier d’énormes exécutables de jeu avec plus d’optimisations actives. On a vu que le couple LAA - Windows x64 sert aussi à d’autres jeux d’outils et un nombre considérable de ces équipes migrent maintenant vers des versions x64 natives. Il y a déjà un intérêt non négligeable à faire migrer les studios en x64 : les outils qui dépendent du LAA et les « content pipelines » (ndlr : gestion facilitée des ressources), ainsi que la poussée considérable des applications de création de contenus numériques comme 3DS Max, Maya et SoftImage pour les outils x64 natifs rendent l’adoption de cette technologie urgentissime, quand bien même les jeux se destinent à des plateformes existantes comme les PC 32 bits, la Xbox 360 etc.

Pour parler du LAA, beaucoup de jeux le permettent. En cherchant un peu, on voit plein de passionnés qui modifient les fichiers de configuration pour activer le LAA dans les jeux actuels pour les rendre plus stables lorsqu’ils tournent avec des mods conséquents. On peut aussi voir dans les forums officiels de certains jeux des appels voilés à jouer sur Windows x64 pour résoudre les problèmes de stabilité après des longues parties, des niveaux complexes etc. La limitation à 2 Go des systèmes 32 bits est une tare pour l’industrie du jeu vidéo depuis plusieurs années, il existe de nombreuses voix en faveur du changement qui ne se sont pas fait entendre. Le LAA sur Windows x64 donne un peu d’air et plus important encore, il pousse les joueurs à adopter la technologie afin que les jeux x64 natifs ne soient monnaie courante.

Qu’en est-il du bénéfice pour les joueurs ?

Au niveau des consommateurs, 4, 6 voir 8 Go de RAM sont assez accessibles maintenant et sans Windows x64, il faut vraiment se restreindre à environ 3 Go de RAM au total. Bien que les jeux en x64 natifs soient encore rares, la croissance de Windows 64 sur le marché est plus intéressante à suivre sur le long terme, parce que liée à ces contraintes de mémoire. Les jeux qui supportent le LAA sont généralement plus stables sur Windows x64 parce qu’ils permettent d’aller au-delà des 2 Go adressables qui limitent les grosses productions récentes. D’autre part, les développeurs peuvent aussi faire le choix d’ajouter librement plus de contenu s’il y a assez de clients avec des configurations qui le permettent.

Les chiffres récents montrent une vraie poussée de Windows x64 et les développeurs veulent passer outre cette limitation de 2 Go depuis un bon moment. A l’heure actuelle, faire un jeu exclusivement x64 natif est un choix difficile, tandis qu’un titre en version 32 bits et x64 natif représente plus de travail et de risques que beaucoup de studios ont envie d’assumer dans l’immédiat. Les jeux étant de plus en plus détaillés chaque année, il faut être dans le haut du panier si l’on veut se démarquer. D’autre part, l’industrie du jeu a utilisé des intergiciels tierce partie de façon croissante pour ses propres productions, ce qui explique la difficulté à obtenir de tous ces acteurs un engagement en faveur du x64 natif. Là aussi on constate une évolution accélérée qui devrait éviter à terme aux développeurs de faire un choix entre créer leurs propres technologies qui supportent nativement le x64 et commercialiser les jeux à temps.

A quel horizon pourra-t-on voir un passage significatif aux jeux 64 bits natifs ? En quoi seront-ils différents des versions 32 bits que l’on voit aujourd’hui ?

Pour le moment, il y a très peu de titres 64 bits natifs et la plupart d’entre eux sont des vitrines technologiques. D’après ce qu’on nous a rapporté, bon nombre de studios utilisent des versions 64 bits natives en interne pour le développement, mais les éditeurs ne veulent pas assumer le surcoût en tests et support technique pour le moment. Une fois que les développeurs et les éditeurs se concentreront sur les versions 64 bits natives, on pourra bénéficier de meilleures performances grâce à des registres plus nombreux, une meilleure utilisation du SSE2 SIMD, une exploitation plus agressive des E/S liées à la mémoire et des ressources plus importantes. Dans l’immédiat, la priorité est de dépasser le plafonnement à 2 Go avant de voir les performances accrues à nouveau grâce aux optimisations logicielles.

Un grand merci à Chuck pour ces éclairages sur cette problématique qui influera très probablement sur le développement des jeux au cours des prochaines années.