Actualités cartes graphiques

GDC: AMD mise sur la VR, annonce LiquidVR

Tags : AMD; GDC; GDC 2015; VR;
Publié le 04/03/2015 à 01:43 par
Imprimer

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 Fidji.

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.

 
 

GDC: Khronos annonce OpenCL 2.1

Publié le 03/03/2015 à 09:01 par
Imprimer

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.

 
 

GDC: Vulkan, l'API bas niveau de Khronos

Publié le 03/03/2015 à 09:00 par
Imprimer

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 :

 
 

GDC: Direct3D12: premiers conseils aux devs

Publié le 03/03/2015 à 02:23 par
Imprimer

Durant la journée des tutoriaux, la session dédiée à Direct3D 12 à laquelle nous avons assisté était destinée à donner quelques conseils aux développeurs intéressés par cette API. Une poignée de spécialistes des moteurs graphiques ont fait partie de la phase d'essai de D3D12 et ont travaillé sur des portages betas, souvent en collaboration avec AMD et Nvidia. Des premières expériences qui ont permis de façonner les détails de l'API et de partager certains conseils.


Durant cette présentation, Evan Hart, Principal Engineer chez Nvidia, et Dave Oldcorn, D3D12 Technical Lead chez AMD, ont rappelé que "de grands pouvoirs impliquent de grandes responsabilités". Entendez par là que le niveau de contrôle plus élevé donné aux développeurs leur permet de faire plus de choses et plus efficacement, mais uniquement s'ils exploitent correctement l'API. Une implémentation hasardeuse peut causer plus de problèmes qu'elle ne tente d'en résoudre.

Une expérience des développeurs sur console, même si elle n'est bien entendu pas obligatoire, est clairement en avantage puisqu'il y a des similitudes entre leurs API propriétaires et les nouvelles API de plus bas niveau. Il est d'ailleurs utile de rappeler qu'un certain niveau d'abstraction reste présent et que les développeurs doivent s'attendre à ce que les pilotes gardent en partie la main sur certains points.

Un portage d'API bête et direct vers D3D12 n'a pas réellement de sens. Pour réellement profiter de l'API, une réflexion en amont sur ses possibilités et ce qu'il est possible d'en faire en pratique est nécessaire. Il faut ainsi par exemple prévoir un bon multithreading, D3D12 ne s'en charge pas tout seul par magie. Il revient aux développeurs de bien segmenter et organiser toutes les tâches liées au rendu, et de préciser dans certains cas explicitement quand elles ne peuvent pas être traitées en parallèle. Par sécurité D3D11 présume qu'il y a d'office une dépendance entre certaines tâches, ce qui empêche leur exécution en parallèle et freine les performances. Tout cela disparaît avec D3D12, mais le développeur doit alors indiquer quand il y a une réelle dépendance, sans quoi il y aura bien entendu des problèmes.

Parmi les autres premiers retours abordés, citons ceux-ci :

- Le mieux est l'ennemi du bien et il peut être nécessaire de rechercher un compromis entre réduction maximale du surcoût CPU, via exécution groupées de nombreuses listes de commandes, et latence globale.

- Attention au budget mémoire. Si le développeur alloue trop de mémoire résidente (soit spécifiée en mémoire vidéo), un plantage peut arriver très vite. C'est particulièrement le cas en mode fenêtré dans lequel l'OS reprend la main sur une partie de la mémoire vidéo. En cas de possibilité de passer du plein écran au fenêtré il faut prévoir d'agir très vite sur la quantité de mémoire utilisée, par exemple en supprimant directement les plus hauts niveaux des mipmaps.

- Faire attention aux bus ! Vu qu'une API telle que D3D12 permet d'envoyer beaucoup plus d'objets, des nouveaux goulets d'étranglement peuvent apparaître, c'est par exemple le cas du bus PCI Express qui peut être saturé.

Vous pourrez l'intégralité de cette partie de la présentation ci-dessous :

 
 

GDC: GDC 2015: D3D12, streaming et VR à l'honneur

Publié le 02/03/2015 à 21:30 par
Imprimer

La Game Developers Conference (GDC) de San Francisco vient d'ouvrir ses portes et nous sommes sur place pour couvrir l'évènement, tout du moins la partie qui nous intéresse, celui-ci étant particulièrement vaste.


Cette année, ce sont le streaming, la réalité virtuelle et Direct3D 12 qui sont particulièrement mis à l'honneur avec de nombreuses conférences, démonstrations et autres tutoriaux. Cette première journée est d'ailleurs tournée entièrement vers ce dernier point avec des Bootcamp divers et variés en parallèle desquels sont organisés toute une série de tutoriaux sur Direc3D 11 et 12.

Ces tutoriaux sont présentés mains dans la main par AMD et Nvidia, accompagnés de quelques développeurs qui font partie des premiers à avoir expérimenté Direct3D 12. AMD et Nvidia tiennent d'ailleurs à insister sur le fait d'avoir été agréablement surpris d'être totalement sur la même longueur d'onde concernant les réflexions partagées sur cette API, alors qu'il y avait traditionnellement plus de désaccords plus ou moins stratégiques.

Si vous n'avez pas suivi les premiers développements concernant Direct3D 12, voici un bref rappel de ses caractéristiques :

 
 

A noter que Direc3D 12 ne sera pas la seule API de plus bas niveau discutée à la GDC, puisque Khronos sera également de la partie et dévoilera officiellement "OpenGL Next", dont nous vous parlerons demain matin à la levée de l'embargo le concernant.


Top articles