Les contenus liés aux tags GDC et GDC 2015

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.

Nvidia a profité du lancement de sa console Shield pour confirmer que le service de cloud gaming GRID passerait bien, comme prévu, de la phase beta à la phase commerciale d'ici quelques mois. Il restera gratuit en 720p jusqu'à la fin du mois de juin pour les possesseurs d'une Shield (tablette ou console), mais un abonnement dont le tarif reste encore à définir sera nécessaire au-delà.

Deux niveaux d'abonnements seront proposés, l'un basique en 720p et l'autre premium en 1080p, toujours en 60 Hz. Une connexion 30 Mbps sera alors nécessaire pour profiter du streaming haute qualité dans de bonnes conditions.

Ces abonnements donneront un accès illimité à un catalogue de jeu qui s'enrichi chaque semaine, mais qui n'intègre pas réellement les dernières nouveautés. Elles seront commercialisées à travers GRID d'une autre manière. Ainsi, les joueurs pourront acheter les jeux AAA récents sur GRID comme ils le font sur d'autres plateformes telles que Steam, à un tarif similaire. Suivant les conditions négociées par Nvidia avec les éditeurs de jeux vidéo, un achat de ce type sur GRID pourra dans certains cas donner l'accès à une version téléchargeable du jeu, en plus du streaming.

Pour profiter de GRID dans les meilleures conditions, passer par une connexion ethernet au niveau de la Shield (via adaptateur pour la tablette) est préférable. La qualité de jeu est alors plutôt bonne, avec une latence réduite à +/- 150ms et laisse entrevoir un large potentiel pour le cloud gaming, même si le jeu PC conserve l'avantage en termes de latence et de qualité graphique.

Nvidia organisait cette année l'une des plus grosses conférences de la GDC, intitulée Made to Game, à travers laquelle le spécialiste du GPU a lancé une nouvelle console Shield, équipée en Tegra X1 et destinée à prendre place à côté de votre TV.

Après la console portable Shield et la tablette Shield, Nvidia prépare un nouveau produit fini grand public dans cette famille : la console Shield pour TV. C'est un projet qui trotte dans la tête de Nvidia depuis quelques temps déjà et l'expérience acquise sur les précédents produits Shield, la mise en production imminente des serveurs GRID, l'arrivée du Tegra X1 et surtout de l'écosystème Android TV ont fait que tous les éléments étaient en place pour une première tentative de percer ce marché.

La Shield (à ne pas confondre avec les autres Shield!), est une set top box Android TV orientée gaming. Elle repose bien évidemment sur le dernier SoC Nvidia, le Tegra X1, dont le GPU correspond pour rappel grosso modo à une demi GeForce GTX 750 sur PC. Niveau connectique, il y a 3 ports USB (dont un micro-USB), un connecteur gigabit ethernet, un port microSD (pour étendre les 16 Go internes) et une sortie HDMI 2.0, ainsi que du wifi 802.11ac 2x2 et du Bluetooth 4.1.


La box, plutôt bien finie, est livrée avec un contrôleur Shield, le même que celui proposé avec la tablette Shield. Une télécommande ainsi qu'un support pour le positionnement vertical seront vendus séparément.

Sur la partie vidéo-ludique, la Shield peut être utilisée pour profiter des jeux PC à travers le streaming et les serveurs GRID, ou directement des jeux Android, dont certains commencent à afficher une qualité graphique semblable à ce qui se faisait sur PC il n'y a pas si longtemps de cela. Lors de la conférence de Nvidia, Crytek a d'ailleurs fait une démonstration du portage de Crysis 3 plutôt convaincante, même si quelques compromis ont probablement été faits au niveau de la qualité graphique par rapport à la version PC.

La Shield est également une box prévue pour la 4K, avec la prise en charge du décodage des vidéos jusqu'en 60 Hz 30-bit. C'est un argument important pour Nvidia puisque l'arrivée du contenu 4K sur les plateformes de streaming demandera un équipement adapté et pourrait donc pousser les premiers utilisateurs vers la Shield.

Elle sera introduite fin mai aux Etats-Unis au tarif de 199$, et devrait arriver quelques temps après dans les autres régions, dont l'Europe et principalement les pays dans lesquels des serveurs GRID sont déjà implantés, ce qui est le cas de la France.

AMD profite de la GDC pour rejoindre le mouvement d'engouement actuel autour de la réalité virtuelle (VR), en annonçant un SDK dédié : LiquidVR.

Proposer un rendu satisfaisant à travers les casques de réalité virtuelle représente un challenge, mais également une opportunité de se démarquer et potentiellement de nouveaux marchés pour les fabricants de processeurs graphiques tant la puissance demandée peut être élevée. Si elle est insuffisante, le résultat est rapidement catastrophique. Nvidia a annoncé travailler dans ce sens il y a quelques mois et c'est aujourd'hui au tour d'AMD de présenter son initiative.


L'objectif à très long terme est qualifié de "Full Presence" et correspond en quelque sorte aux réalités virtuelles les plus avancées que vous avez pu apercevoir dans les films de science-fiction. AMD estime qu'il faudra multiplier par un million les capacités actuelles pour y parvenir, ce n'est pas encore pour aujourd'hui.

A plus court terme, AMD a voulu essayer d'identifier les challenges actuels auxquels il était possible d'apporter une réponse dès aujourd'hui de manière à améliorer le confort, la compatibilité et le contenu. Grossièrement, cela revient à optimiser le time warping, à assurer un pilotage direct des casques de réalité virtuelle et à proposer un mode multi-GPU dédié.


Pour cela, le SDK LiquidVR 1.0, propose 4 fonctionnalités, dont les deux premières sont liées au time warping. Cette technique consiste pour rappel à réduire la latence en prenant en compte les informations des capteurs de mouvements après avoir débuté, voire terminé, le calcul de l'image. Ces informations plus récentes sont exploitées pour déformer la dernière image calculée de manière à émuler ce que nous aurions vu si l'image pouvait être calculée instantanément juste avant l'affichage.

Ces deux fonctionnalités proposées par AMD à ce niveau sont dénommées Latest Data Latch et Asynchronous Shaders. La première fait en sorte que le GPU puisse avoir un accès facilité aux dernières données de position, mise à jour constamment en parallèle par le CPU.


La seconde exploite une caractéristique des GPU de la génération GCN : les ACE pour Asynchronous Compute Engines. Il s'agit de processeurs de commandes secondaires qui peuvent lancer des tâches de type compute sur le GPU de manière transparente, en même temps que celui-ci est en train de traiter des commandes graphiques. Ce traitement en parallèle permet de réduire la latence en lançant l'opération de time warping avant que l'image finale ne soit totalement terminée mais également de débuter l'affichage de l'image avant que le time warping ne soit terminé sur toute l'image.

De quoi économiser quelques ms au niveau de la latence et surtout de quoi éviter toute saccade si le time warping et le calcul de l'image dépassent le délai imposé par le rafraichissement. Si le calcul de la nouvelle image prend trop de temps, le time warping, qui est traité en parallèle via les ACE, pourra appliquer de façon transparente les dernières données de position sur l'image précédente. Cela reste préférable de disposer de la dernière image et des dernières informations de positions bien entendu, et les Asynchronous Shaders permettent d'ailleurs de faire en sorte que ce soit plus souvent le cas, mais quand ce n'est pas possible, éviter un ralentissement est primordial.


Ensuite, le mode Affinity Multi-GPU permet de profiter de plusieurs GPU sans augmenter la latence et en réduisant le coût CPU globale. Le mode AFR classique est inadapté parce qu'il introduit trop de latence supplémentaire, raison pour laquelle le multi-GPU classique a rapidement été mis de côté, malgré les besoins de puissance de calcul qui dépassent bien souvent ce dont est capable un seul GPU. En mode Affinity, chaque GPU peut être assigné à un œil, mais sans calculer des images successives. Ils vont calculer la même image en même temps, simplement d'un point de vue différent. C'est assez logique en fait, mais encore fallait-il qu'AMD l'implémente.

Enfin, le Direct-to-Display permet aux pilotes AMD de directement gérer l'affichage sur tous les casques de réalité virtuelle, sans passer par un SDK tiers tels que celui d'Oculus. Les pilotes Catalyst vont reconnaître les casques, les considérer comme des écrans secondaires spécifiques et adapter le mode d'affichage à cet effet. De quoi simplifier nettement la configuration et améliorer la stabilité, tout du moins si les pilotes proposés par AMD s'avèrent ne pas souffrir de bug. A noter qu'Oculus, présent à la session d'AMD, a précisé avoir collaboré au développement de Direct-to-Display.

AMD proposait évidemment une démonstration de LiquidVR, basées sur un Oculus Rift Crescent Bay et l'animation Showdown, avec un excellent résultat. Difficile cependant sans comparer d'autres solutions côte-à-côte d'affirmer que LiquidVR apporte un avantage significatif. Lorsque nous avions testé cette même démo lors d'un évènement Nvidia en septembre dernier, le résultat était également très bon.

A noter que le système utilisé par AMD ne faisait pas appel au multi-GPU mais bien à une carte graphique basé sur un nouveau GPU. En d'autres termes, il s'agissait d'une Radeon R9 390X et du GPU Fiji.

Le SDK LiquidVR 1.0 et ses spécifications sont actuellement distribués par AMD au cas par cas aux différents acteurs engagés dans le développement de la réalité virtuelle.

Parallèlement à l'annonce de Vulkan, le groupe Khronos fait évoluer légèrement OpenCL avec l'annonce des spécifications provisoires de la version 2.1 de cette API dédiée au GPU computing. La principale nouveauté est l'ajout d'un nouveau langage pour les kernels : à côté d'OpenCL C prendra désormais place OpenCL C++.

Ce langage correspond à un subset de C++14, amputé de quelques fonctionnalités, et permettra de faciliter le travail des développeurs, en leur permettant d'ignorer certains détails de bas niveau, tout en gardant une efficacité suffisamment élevée.

Alors que compiler vers un langage intermédiaire, SPIR, était possible optionnellement depuis quelques temps avec OpenCL 2.0, le langage intermédiaire SPIR-V, partagé avec Vulkan, rentre dans les spécifications "core" d'OpenCL 2.1. OpenCL C++ est d'ailleurs prévu pour passer exclusivement par SPIR-V.

De petites fonctionnalités font également leur apparition ou rentrent dans les spécifications "core", c'est par exemple le cas des requêtes concernant les "subgroups", qui exposent l'organisation matérielle du threading (warps chez Nvidia, wavefronts chez AMD etc.) et permettent des optimisations plus fines.

A noter que si Intel et AMD louent les avantages d'OpenCL 2.1 dans la communication officielle, Nvidia reste aux abonnés absents et tient donc le cap sur sa stratégie qui consiste à se concentrer sur son écosystème propriétaire CUDA.