Les contenus liés au tag GDC

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.

Il y a 6 mois, à travers l'initiative Next Generation OpenGL, le groupe Khronos annonçait l'intention de faire évoluer son API phare pour répondre aux récentes API graphiques de plus bas niveau proposées par AMD, Microsoft ou encore Apple. Des travaux qui ont bien avancés et la GDC est l'occasion d'annoncer formellement Vulkan.

OpenGL est une API qui a été régulièrement critiquée pour son évolution trop lente et pour sa complexité trop élevée. Définie par un consortium qui regroupe tous les fabricants de GPU, des fabricants de SoC, des fabricants de périphériques mobiles, des spécialistes du moteur graphique, etc., cette API souffre de la difficulté de mettre tout le monde d'accord sur les directions principales des évolutions, et encore plus sur les points de détails. Toutes ces sociétés n'ont pas les mêmes intérêts, ce qui entraîne une bonne dose de politique et de lobbying, suivis d'un long processus de négociations. Par ailleurs, l'aspect rétrocompatibilité et le long historique de 22 ans ont fini par devenir des boulets que doit trainer OpenGL.

Dans le monde mobile, Khronos a tenté de gagner en agilité à travers une API dédiée et quelque peu simplifiée, OpenGL ES. Cela a plutôt bien fonctionné jusqu'ici, même si les 2 API partagent certaines limitations. Avec l'arrivée des API de plus bas niveau, initiée par AMD et Mantle, suivie par Microsoft et Direct3D 12 ainsi que par Apple et Metal, il y avait une vraie pression sur Khronos pour revoir en profondeur son API graphique. Une opportunité en fait puisqu'une pression suffisante était nécessaire pour parvenir à mettre d'accord, relativement rapidement, tous ses membres.

Pour se donner un maximum de liberté et probablement pour pouvoir contenter les membres qui tirent un avantage compétitif de la complexité actuelle d'OpenGL, ou de son long historique, un compromis s'est rapidement avéré nécessaire. OpenGL Next ne serait pas un OpenGL mais une nouvelle API, bien distincte. De quoi permettre à Khronos d'avancer les mains libres. OpenGL et OpenGL ES vont continuer à évoluer de leur côté, en restant des API de plus hauts niveaux, bien que certains accès de plus bas niveaux y soient déjà disponibles depuis quelques temps, tout du moins pour les développeurs expérimentés qui parviennent à les dénicher sous les différentes couches de complexité.

Parallèlement à ces API "historiques", la nouveauté que Khronos va proposer se nomme Vulkan, son interprétation de l'API graphique de plus bas niveau. A noter que lorsqu'on parle d'une API graphique de bas niveau, il ne s'agit pas d'attaquer les GPU en langage machine barbare. Un certain niveau d'abstraction est conservé, et représente un compromis entre le contrôle donné aux développeurs et la compatibilité avec une large gamme de processeurs graphiques et de plateformes. Du supercalculateur, au smartphone, en passant par le PC, Vulkan pourra trouver sa place.


Comme les autres API de bas niveau, Vulkan offre un accès plus adapté aux GPU modernes, réduit le surcoût CPU des pilotes et permet l'implémentation d'un multi-threading efficace. Une API de plus bas niveau, qui rend le comportement du pilote GPU plus prédictible, facilite également la portabilité d'une plateforme à l'autre tout en conservant de bonnes performances, un point crucial pour tous les développeurs de moteurs de jeux et de middlewares.

Khronos indique d'ailleurs avoir construit à l'intérieur de Vulkan des mécanismes dédiés spécifiquement à faciliter la portabilité, notamment au niveau du débogage. Des outils multiplateformes performants devraient ainsi pouvoir être proposés. Des développements dans ce sens son déjà bien avancés chez Valve, LunarG ou encore Codeplay.

Pour permettre à Vulkan de voir le jour, une autre évolution majeure était indispensable. Avec OpenGL, les programmes (shaders) qui sont exécutés par le GPU sont écrits dans un langage de haut niveau spécifique, GLSL, et compilés à l'exécution par les pilotes en langage machine exécutable par le GPU. Cela a plusieurs inconvénients, il faut intégrer aux pilotes un compilateur complexe, les temps de compilation peuvent être importants, le débogage est plus complexe, le code source des shaders n'est pas protégé…

Pour éviter tout cela, Khronos introduit SPIR-V, un langage intermédiaire entre le code source et le code machine. Il s'agit d'une évolution du SPIR déjà disponible en OpenCL et qui sera d'ailleurs partagée par Vulkan ainsi que par le futur OpenCL 2.1. Les développeurs pourront précompiler leur code GLSL vers SPIR-V, et les meilleurs d'entre eux ainsi que les fournisseurs de moteurs graphiques pourront optimiser directement ce code SPIR-V.


Khronos envisage de faire passer en open source le compilateur GLSL vers SPIR-V pour faciliter l'arrivée d'un riche écosystème, avec par exemple une variante HLSL vers SPIR-V. D'autres langages pourront également être traduits à l'avenir vers SPIR-V et Khronos a prévu que la conversion de et vers LLVM soit possible. Ces outils en sont toujours dans les premières phases de leur développement.

La semaine passée, nous avons pu nous entretenir brièvement avec Neil Trevett, Président de Khronos et Vice Président de l'écosystème mobile chez Nvidia, au sujet de Vulkan. Ce dernier nous a tout d'abord indiqué que de nombreux détails sont toujours en train d'être définis telles que l'implémentation exacte au niveau des pilotes et des OS.

Pour Neil Trevett, qui aborde la question sans détour, l'arrivée de Vulkan ne représente pas une menace dans le monde professionnel pour une société telle que Nvidia qui bénéficie actuellement d'un avantage compétitif énorme à travers son implémentation logicielle robuste d'OpenGL. D'une part Vulkan sera utile pour certaines applications trop limitées par le CPU pour pouvoir profiter des GPU haut de gamme récents de Nvidia et d'autre part l'importance d'OpenGL est loin de s'effacer dans un monde qui a tendance à bouger lentement.

Du côté grand public, tout GPU capable de supporter OpenGL ES 3.1, et donc les Compute Shaders, devrait être capable de faire tourner Vulkan, si bien entendu des pilotes sont développés en ce sens. Du côté PC, tous les GPU qui supportent D3D12 devraient ainsi également supporter Vulkan. Pour les SoC, c'est un petit peu plus compliqué en général, mais du côté de Nvidia, les Tegra K1 et X1 devraient bien entendu en profiter.

Neil Trevett nous a ensuite indiqué, qu'au niveau des OS, Vulkan devrait être rendu disponible partout là où OpenGL et OpenGL ES sont actuellement proposés. En d'autres termes le support devrait être très large et inclura sans problème d'anciennes versions de Windows telles que Windows 7. L'implémentation exacte n'est par contre pas précisée et il restera à voir si les fabricants de GPU développeront bel et bien de tels pilotes.

La possibilité est cependant prévue, et ce n'est pas anodin. Le point fort de Vulkan du côté grand public face aux API concurrentes sera son très large support, des plateformes Windows aux plateformes mobiles, en passant par Steam OS. De quoi redévelopper une présence de Khronos dans le monde du jeu vidéo PC ? Peut-être mais pas tout de suite, les spécifications initiales sont attendues pour cette année et les premières applications ne le sont pas avant 2016.

Vous pourrez retrouver la présentation complète ci-dessous :