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

 
 

Vos réactions

Top articles