Les solutions de streaming : Streaming local Steam et Nvidia GameStream en test

Publié le 26/07/2016 par
Imprimer

Mesures de latence

Afin de mesurer la latence des différentes solutions, nous avons mis au point un protocole de test assez particulier dans le but d'obtenir les mesures les plus réalistes possibles. Notre but étant d'obtenir des mesures exactes entre le moment où l'on appuie sur un bouton, et le moment où l'écran réagit.

Pour cela, nous avons choisi d'utiliser un Steam Controller que nous avons démonté afin d'y récupérer de manière électrique l'information de l'impulsion sur l'un des boutons du pad. Le câble qui récupère l'information est branché dans un oscilloscope.

Une seconde entrée de l'oscilloscope est reliée à une photodiode qui permet de mesurer l'intensité lumineuse. Celle-ci est placée sur un écran Iiyama ProLite E2283HS, un écran 22 pouces 1080p disposant d'un taux de rafraîchissement de 60 Hz. Il est équipé d'une dalle TN et dispose d'une entrée HDMI. Cet écran est annoncé par son constructeur avec un temps de réponse de 2 millisecondes.

Nous avons enfin développé une application en C++ utilisant l'API DirectX 11 de Microsoft (et DXGI/DirectInput) qui est lancée sur notre PC principal (celui qui stream vers les diverses solutions). Son fonctionnement est simple : elle affiche un carré blanc à l'écran. Lorsque l'on appuie sur le bouton du Steam Controller, l'API DirectInput avertit le programme qui change la couleur du carré en noir. Lorsque le bouton est relâché, le carré redevient blanc. En parallèle, l'application pilote également l'oscilloscope USB qui enregistre de manière indépendante les informations du contrôleur et de la photodiode sur toute la période du test, et ce toutes les 0.1 millisecondes. Les données sont enregistrées et analysées par la suite.

Nous mesurons via les données collectées par l'oscilloscope le temps exact (à 0.1ms près) qui s'est écoulé entre le début de la pression sur le bouton (indiqué par une baisse de tension via le câble soudé sur le contrôleur) et le moment ou la photodiode voit l'écran commencer sa transition du blanc au noir (comme expliqué précédemment dans notre article). Nous mesurons également en sens inverse le moment ou le bouton est relâché, et le moment ou l'écran entame sa transition du noir au blanc.

Etant donné que l'écran ne se rafraîchit que toutes les 16,67 millisecondes (en 60 Hz), et que nos pressions sur le bouton sont aléatoires, nous effectuons pour chaque test une moyenne sur 500 mesures, afin de lisser au maximum la variabilité.

Pour être parfaitement complet, indiquons que le Steam Controller est branché directement sur le PC principal. Nous avons dû faire cette concession du fait que le Steam Controller n'est pas supporté directement par la console Nvidia Shield TV. S'il existe des solutions alternatives (fonctionnelles) comme par exemple Virtual Here USB Server , nous avons été confronté à un autre bug de GameStream, qui ne permet pas d'afficher l'overlay Steam (accessible par les touches Shift+Tab), nécessaire pour configurer correctement le Steam Controller.

Cette concession n'est pas très grave : nous avons mesuré en pratique une différence d'environ 1 milliseconde entre un branchement sur le PC principal, et un branchement sur le boîtier Steam Link pour vous donner une idée.

Notez également que pour vous donner un ordre de grandeur le plus réaliste possible, nous utilisons le Steam Controller en mode sans fil. Ce dernier peut être utilisé au choix en mode USB filaire, ou en mode WiFi Direct via un dongle fourni. Il s'agit d'une connexion WiFi point à point entre le contrôleur et son dongle, ne nécessitant pas de routeur (le pad Xbox One utilise également le WiFi Direct). Nous avons mesuré à moins de 2 millisecondes le coût de cette implémentation sans fil, soit quelque chose de très négligeable lorsque l'on la compare au confort qu'elle apporte, c'est pour cela que nous l'avons utilisé.

Pour terminer, notre PC principal est relié aux différentes solutions de streaming en Gigabit Ethernet via un switch. Nous n'utilisons pas le WiFi, ce dernier n'ayant qu'un impact mesuré sur la latence (vous pouvez vous en rendre compte en pingant votre routeur). Le problème principal du WiFi tient au débit et sa stabilité dans le temps en fonction des interférences éventuelles, nous l'évoquerons un peu plus tard dans l'article.

Configuration

Notre PC principal est équipé comme suit : - Intel Core i7 6700K - Asus Z170-A - GeForce GTX 970/Radeon R290X - Windows 10

Nos solutions de streaming sont pour rappel : - Boitier Steam Link - PC Asus VivoPC VM42  (Intel Celeron 2957U) + Steam sous Windows 10 - Nvidia Android Shield TV

On notera que l'utilisation de Windows 10 est particulièrement contraignante sur le mini PC équipé d'un Celeron. Windows 10 démarre en effet un certain nombre de tâches à sa convenance, et il nous est impossible de les débrayer, nous obligeant a réaliser plusieurs fois les tests tant les ralentissements constatés sur un petit CPU sont importants.

 
 

Qu'il s'agisse de l'anti-malware (qui même désactivé temporairement exécute tout de même un processus pouvant saturer un core), le .NET optimizer ou les vérifications périodiques de mises à jour, ces multiples processus sont une plaie qu'il faudra prendre en compte si vous optez pour cette solution, tant l'impact est visible à l'oeil nu lorsqu'il s'agit de streaming !

Passons enfin aux mesures !

Latences mesurées

Nous avons mesuré la latence avec et sans V-Sync avec les différentes solutions et les différents encodeurs supportés. Pour le cas de l'Android Shield TV, l'encodage est réalisé par la GeForce sans possibilité de réglages. Pour les solutions Steam, on a le choix entre les encodeurs H.264 suivants :

  • CPU (libx264)
  • AMD AMF
  • Intel Quicksync
  • Nvidia NVENC
  • Nvidia NVENC + NVFBC

Nous ajoutons également une mesure sur le PC en local, sans streaming. Avant toute chose, notons qu'il existe une incompatibilité entre l'encodeur H.264 AMD (AMF) et le décodage QuickSync. Ce dernier est inutilisable dans nos tests sur notre machine, un bug qui n'apparaît qu'avec cette combinaison qu'on évitera. L'encodage AMF, décodé par le petit SoC Marvell du Steam Link ne pose aucun problème ce qui laisse penser que le problème est lié a QuickSync.

Nous commençons avec la synchronisation verticale désactivée :


Commençons par la mesure locale, cette dernière est particulièrement basse. On le doit en grande partie au fait que notre application de test, sans V-Sync, tourne à près de 5000 FPS sur notre machine. Conformément à ce que l'on expliquait précédemment, on compare donc ici le meilleur cas possible localement en matière de latence, ce qui nous donne une bonne idée du coût réel du streaming.

Le cout dépend de deux facteurs, tout d'abord les plateformes. Indépendamment des encodeurs utilisés, on voit une tendance nette : l'Android Shield TV reste la plus lente, suivie de notre mini PC sous Windows 10, et enfin de Steam Link. Ce petit boîtier est significativement plus rapide que les autres solutions.

Ensuite il faut prendre en compte les encodeurs. La encore on note des différences a peu près communes entre les plateformes. Quicksync est en général la solution la plus lente, suivie d'AMD AMF puis du mode CPU qui reste très rapide au final sur notre véloce Core i7 6700K. Ce sont les solutions d'encodage Nvidia qui disposent de la latence la plus faible, et plus particulièrement du mode NVFBC. Nous reviendrons rapidement sur ce qui le différencie, mais regardons avant ce qui se passe lorsque l'on active la synchronisation verticale :


Le streaming plus rapide que le rendu local ? Oui, et pas qu'un peu, on retrouve jusque 30 millisecondes d'écart avec une machine Steam Link et l'encodeur Nvidia par rapport au rendu sur l'écran.

C'est là que nos explications sur le rendu rentrent en compte. On pourrait croire que les solutions de streaming capturent l'image qui va être affichée à l'écran (le front buffer), l'encodent, et l'envoient vers le réseau. Cela ne marche pas ainsi !

En pratique, les solutions de streaming vont récupérer les images dans les back buffers, plus précisément dans le buffer "complet" le plus en bas de la swap chain. Si l'on reprend notre schéma :

L'image sera récupérée dans le dernier back buffer (le 3), une fois que la copie à été réalisée par le GPU, ce qui permet de gagner un temps significatif par rapport au moment ou l'image doit être affichée à l'écran ! Ce temps est utilisé pour encoder, transférer, puis décoder l'image et l'afficher immédiatement sur la machine distante, ce qui peut être plus rapide en pratique en fonction de la longueur de la swap chain utilisée par l'application.

L'idée est plutôt bonne et il faut savoir que et Steam, et Nvidia utilisent ce principe.

Steam a cependant une autre optimisation. Si vous comparez les valeurs entre V-Sync activé et désactivé, vous noterez que les valeurs sont sensiblement identiques pour les solutions Steam. C'est l'autre astuce de Steam, ils désactivent la synchronisation verticale sur le PC source. Encore une fois si l'on se réfère à ce que nous expliquions page précédente, on comprends l'idée : en désactivant la synchronisation verticale on limite au maximum la latence du moteur ce qui laisse plus de marge pour l'encodage.

Qui plus est, l'encodeur ne transmettra jamais plus de 60 images en pratique à la destination. Ce qui fait que V-Sync actif ou pas, en pratique on se retrouvera avec seulement 60 images par secondes transférées... et une absence de tearing. Là encore c'est un choix effectué par Nvidia et Steam : ils ne capturent et n'encodent que des images qui ont été rendues dans leur intégralité. En quelque sorte, l'esprit du V-Sync est présent, qu'il soit actif ou non dans les jeux, il est simplement déporté de DXGI vers la solution de streaming. L'idée est plutôt astucieuse et si l'on pourra toujours pinailler sur cette optimisation non débrayable, en pratique nous avons du mal à voir un point négatif.

Cette optimisation est effectuée au niveau des routines de capture de Steam, on peut s'en apercevoir en regardant le cas particulier des NVFBC qui payent très cher l'activation du V-Sync. Derrière cet acronyme (NV Frame Buffer Capture), on retrouve une méthode alternative de capture des buffers de l'écran, réalisée directement au niveau de la carte graphique sans devoir repasser par la mémoire centrale. L'intérêt est qu'il est possible via les API de Nvidia d'envoyer directement le buffer capturé vers l'encodeur ce qui permet à la solution d'avoir une latence très serrée, on le voit lorsque la synchronisation verticale est désactivée.

Cependant attention, la capture n'est pas la même ! Ainsi, dans les jeux, Steam va privilégier la capture de la swap chain du jeu, tandis que le mode NVFBC effectue la capture dans la swap chain de Windows. Cela permet d'avoir (joie !) une capture des notifications. Théoriquement, il y a un petit avantage à capturer directement le frame buffer de l'application, et non celui de Windows. En pratique, s'il existe, il est minime et les gains apportés par le fait d'effectuer les opérations directement sur la carte graphique sont largement supérieurs.

Et le mode "Bande passante illimité" ?

Dans la présentation de Steam, nous vous indiquions que choisir le mode de bande passante illimité augmente la latence, d'après l'interface. Dans nos tests, ce n'est pas le cas, nous n'avons pas noté de différence entre le mode de bande passante automatique et l'illimité, et ce indépendamment de l'encodeur utilisé, entre deux machines Steam.

En résumé...

Pour résumer tout cela, la latence reste globalement particulièrement bonne en streaming avec les diverses solutions, à condition de privilégier la désactivation de la synchronisation verticale. Dans le pire des cas, on se retrouve avec une latence proche de celle d'un jeu ou la synchronisation verticale est activée, et parfois bien en dessous. Si le mode de capture alternatif de Nvidia a clairement l'avantage, reste à voir comment tout ce la se traduit sur la question de la qualité d'images, au moins aussi importante que celle de la latence !

Vos réactions

Top articles